Hi All,
We have a chicken and egg problem, the tests require mirrormanager to point at the right content, and we do not want to sync the content unless we are sure it is okay for users and will work as expected. So the thought I was was to setup in the qa network a mirrormanager instance that will be able to point the tests at the just built composes and content. it would like need its own dns view so that the expected urls work in the expected ways, but point the the QA test specific instances.
I wanted to get a conversation started on what it would take to implement
Dennis
On 13 July 2016 at 03:58, Dennis Gilmore dennis@ausil.us wrote:
Hi All,
We have a chicken and egg problem, the tests require mirrormanager to point at the right content, and we do not want to sync the content unless we are sure it is okay for users and will work as expected. So the thought I was was to setup in the qa network a mirrormanager instance that will be able to point the tests at the just built composes and content. it would like need its own dns view so that the expected urls work in the expected ways, but point the the QA test specific instances.
I don't think that would work easily.
1) There are systems on the QA network which aren't QA which would be affected by this (the CentOS master mirror server and some others).
2) You will need to set up more than a split DNS. You will need to set up a separate proxy and database and other items. If you going that far, it might be be easier to stick these systems on a different network
I wanted to get a conversation started on what it would take to implement
Dennis _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedoraproje...
On Wednesday, July 13, 2016 10:07:22 AM CDT Stephen John Smoogen wrote:
On 13 July 2016 at 03:58, Dennis Gilmore dennis@ausil.us wrote:
Hi All,
We have a chicken and egg problem, the tests require mirrormanager to point at the right content, and we do not want to sync the content unless we are sure it is okay for users and will work as expected. So the thought I was was to setup in the qa network a mirrormanager instance that will be able to point the tests at the just built composes and content. it would like need its own dns view so that the expected urls work in the expected ways, but point the the QA test specific instances.
I don't think that would work easily.
- There are systems on the QA network which aren't QA which would be
affected by this (the CentOS master mirror server and some others).
- You will need to set up more than a split DNS. You will need to set
up a separate proxy and database and other items. If you going that far, it might be be easier to stick these systems on a different network
I wanted to get a conversation started on what it would take to implement
Dennis _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/infrastructure@lists.fedorapro ject.org
There will need to somewhat of an investment in resources to make it work right. but I think it is important that we do to be able to do full end to end testing of unreleased content inthe exact same way as users will do so.
Dennis
On Wed, 13 Jul 2016 17:04:41 -0500 Dennis Gilmore dennis@ausil.us wrote:
There will need to somewhat of an investment in resources to make it work right. but I think it is important that we do to be able to do full end to end testing of unreleased content inthe exact same way as users will do so.
I've been pondering and I wonder if instead of another full mirrormanager we just create a small app or even just a apache config that:
* If it gets a request for a rawhide / branched metalink, it just serves up one from the current compose area ( /mnt/koji/composes/whatever ). It would only need 1 mirror in the list (kojipkgs) pointing to the right path. It could create the checksums on the fly even.
* If it gets request for anything else it just passes it on to the real mirrors.fedoraproject.org
Then we set this up in dns to give the small app/apache as mirrors.fedoraproject.org in qa. Other machines there shouldn't be bothered because we pass on non rawhide/branched requests.
Would that work?
kevin
On Monday, July 18, 2016 1:45:27 PM CDT Kevin Fenzi wrote:
On Wed, 13 Jul 2016 17:04:41 -0500
Dennis Gilmore dennis@ausil.us wrote:
There will need to somewhat of an investment in resources to make it work right. but I think it is important that we do to be able to do full end to end testing of unreleased content inthe exact same way as users will do so.
I've been pondering and I wonder if instead of another full mirrormanager we just create a small app or even just a apache config that:
If it gets a request for a rawhide / branched metalink, it just serves up one from the current compose area ( /mnt/koji/composes/whatever ). It would only need 1 mirror in the list (kojipkgs) pointing to the right path. It could create the checksums on the fly even.
If it gets request for anything else it just passes it on to the real mirrors.fedoraproject.org
Then we set this up in dns to give the small app/apache as mirrors.fedoraproject.org in qa. Other machines there shouldn't be bothered because we pass on non rawhide/branched requests.
Would that work?
kevin
probably, we need a way to test things end to end, if it works exactly like mm does i guess it does not matter, there is a chance it will have bugs and do things different that will not be detected until mm is in use.
Dennis
infrastructure@lists.fedoraproject.org