I originally sent this to TripleO but perhaps [infra] would have been a better choice.
The short version is I'd like to run a lightweight (unofficial) mirror for Fedora in infra: https://review.openstack.org/#/c/90875/ And then in the TripleO CI racks we can run local Squid caches using something like this: https://review.openstack.org/#/c/91161/ We have to do something because we see quite a bit of job failures related to unstable mirrors. If using local Squid caches doesn't work out then perhaps we will have to run local mirrors in each TripleO CI rack but I would like to avoid that if possible as it is more resource heavy. Especially because we'll need to do the same things in each rack for Fedora and Ubuntu (both of which run in each TripleO CI test rack). Dan ----- Forwarded Message ----- From: "Dan Prince" <dpri...@redhat.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Sent: Tuesday, April 29, 2014 4:10:30 PM Subject: [openstack-dev] [TripleO] elements vs. openstack-infra puppet for CI "infra" nodes A bit of background TripleO CI background: At this point we've got two public CI overcloud which we can use to run TripleO check jobs for CI. Things are evolving nicely and we've recently been putting some effort into making things run faster by adding local distro and Pypi mirrors. Etc. This is good in that it should help us improve both the stability of test results and runtimes. ---- This brings up the question of how we are going to manage our TripleO overcloud CI resources for things like: distro mirrors, caches, test environment brokers, etc 1) Do we use and or create openstack-infra/config modules for everything we need and manage it via the normal OpenStack infrastructure way using Puppet etc.? 2) Or, do we take the TripleO oriented approach and use image elements and Heat templates to manage things? Which of these two options do we prefer given that we eventually want TripleO to be gating? And who is responsible for maintaining them (TripleO CD Admins or OpenStack Infra)? ---- If it helps to narrow the focus of this thread I do want to stress I'm only really talking about the public CI (overcloud) resources. What happens underneath this layer is already managed via TripleO tooling itself. Regardless of what we use I'd like to be able to maintain feature parity with regards to setting up these CI cloud resources across providers (HP and Red Hat at this point). As is I fear we've got a growing list of CI infrastructure that isn't easily reproducible across the racks. Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
