Open Stack

Excerpts from Dan Prince's message of 2014-05-05 05:51:52 -0700:
> 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" <dprince at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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)?
> 

The way I see things going, infra has a job to do _today_ and they should
choose the tools they want for doing that job.

TripleO is trying to make OpenStack deploy itself, and hopefully in
so doing, also make managing workloads easier on OpenStack. If we are
operating any workload, it would make a lot of sense for us to use the
same tools we are suggesting OpenStack operators consider using.

So it really comes down to who is operating the mirrors. If we're doing
it, we should be doing it with the tools we've built for that specific
purpose. If we expect infra to do it, then they should decide what works
best for them.

Either way, I completely agree that we shouldn't be doing anymore one-off
cowboy mirrors, which is what we've been doing.