Mike, others, I believe Jesse was proposing an upgrade that downloads all the files separately on the Fuel Master itself. This is a move that we've gone away from since Fuel 2.0 because of intermittent issues with 3rd party mirrors. It's often better to consume 1 large file that has everything and can be verified than to try to pull hundreds of separate bits that can't be verified, plus trying to track down errors when something small doesn't work. Locking down to a single install base really contributed to Fuel's success early on, so I don't think moving back to separate file downloads is a good idea.
However, clearly we should do our best to compress the upgrade package file as best as possible so it is less expensive to transfer and also consume. On Fri, Aug 22, 2014 at 1:43 PM, Mike Scherbakov <mscherba...@mirantis.com> wrote: >> I think 15 minutes is not too bad. Additionally, it will reduce download >> time and price for bandwidth. > +1 > > But let's see if we can find some other solution still in 5.1 (hardlinks, > whatever else), and we obviously need to seriously address it in next > release. > >> Perhaps for 6 an option can be made to allow the Fuel master to use >> package repositories instead of an upgrade file - and the option can be used >> for development and production? > Jessee, could please clarify this? Do you mean to use remote repository with > packages, instead of tarballing everything into single bundle? > > > > On Fri, Aug 22, 2014 at 12:39 PM, Matthew Mosesohn <mmoses...@mirantis.com> > wrote: >> >> Dmitry, we already use lrzuntar in deploying Docker containers. Use a >> lower compression ratio and it will decompress faster on virtual envs and it >> takes under two mins on my virtual env. >> >> Compress: >> https://github.com/stackforge/fuel-main/blob/master/docker/module.mk#L27 >> >> Decompress: >> https://github.com/stackforge/fuel-main/blob/master/iso/bootstrap_admin_node.docker.sh#L63 >> >> On Aug 21, 2014 5:54 PM, "Dmitry Pyzhov" <dpyz...@mirantis.com> wrote: >>> >>> Fuelers, >>> >>> Our upgrade tarball for 5.1 is more than 4.5Gb. We can reduce it size by >>> 2Gb with lrzip tool (ticket, change in build system, change in docs), but it >>> will dramatically increase unpacking time. I've run unpack on my virtualbox >>> environment and got this result: >>> [root@fuel var]# lrzuntar fuel-5.1-upgrade.tar.lrz >>> Decompressing... >>> 100% 7637.48 / 7637.48 MB >>> Average DeCompression Speed: 8.014MB/s >>> [OK] - 8008478720 bytes >>> Total time: 00:15:52.93 >>> >>> My suggestion is to reject this change, release 5.1 with big tarball and >>> find another solution in next release. Any objections? >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Mike Scherbakov > #mihgen > > > _______________________________________________ > 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