On Tue, May 15, 2018 at 11:42 AM Jeremy Stanley <fu...@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 > part. > > > > Then those stored artifacts to be picked up by the next step in the > graph, > > 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev