[openstack-dev] [ci][infra][tripleo] Multi-staged check pipelines for Zuul v3 proposal
whayutin at redhat.com
Tue May 15 20:52:26 UTC 2018
On Tue, May 15, 2018 at 11:42 AM Jeremy Stanley <fungi at yuggoth.org> wrote:
> On 2018-05-15 17:31:07 +0200 (+0200), Bogdan Dobrelya wrote:
> > * upload into a swift container, with an automatic expiration set, the
> > de-duplicated and compressed tarball created with something like:
> > # docker save $(docker images -q) | gzip -1 > all.tar.xz
> > (I expect it will be something like a 2G file)
> > * something similar for DLRN repos prolly, I'm not an expert for this
> > Then those stored artifacts to be picked up by the next step in the
> > deploying undercloud and overcloud in the single step, like:
> > * fetch the swift containers with repos and container images
> I do worry a little about network fragility here, as well as
> extremely variable performance. Randomly-selected job nodes could be
> shuffling those files halfway across the globe so either upload or
> download (or both) will experience high round-trip latency as well
> as potentially constrained throughput, packet loss,
> disconnects/interruptions and so on... all the things we deal with
> when trying to rely on the Internet, except magnified by the
> quantity of data being transferred about.
> Ultimately still worth trying, I think, but just keep in mind it may
> introduce more issues than it solves.
> Jeremy Stanley
Question... If we were to build or update the containers that need an
update and I'm assuming the overcloud images here as well as a parent job.
The content would then sync to a swift file server on a central point for
ALL the openstack providers or it would be sync'd to each cloud?
Not to throw too much cold water on the idea, but...
I wonder if the time to upload and download the containers and images would
significantly reduce any advantage this process has.
Although centralizing the container updates and images on a per check job
basis sounds attractive, I get the sense we need to be very careful and
fully vett the idea. At the moment it's also an optimization ( maybe ) so
I don't see this as a very high priority atm.
Let's bring the discussion the tripleo meeting next week. Thanks all!
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev