I've updated the spec: https://review.openstack.org/#/c/116874/
Major change in this spec: get rid of unpacked upgrade tarball. Use only
lrzipped archives. It will save disk space and network traffic, it will
make upgrade process longer, it will make our upgrade tests longer as well,
it will make
As an update, please check and review commit [1] to fuel-specs with
detailed feature description.
According to this feature, we are going to switch our CI system to lrzipped
tarballs.
[1] https://review.openstack.org/#/c/116874/
On Thu, Aug 21, 2014 at 5:50 PM, Dmitry Pyzhov
On 21 August 2014 18:47, Sergii Golovatiuk sgolovat...@mirantis.com wrote:
I think 15 minutes is not too bad. Additionally, it will reduce download
time and price for bandwidth. It's worth to leave lrzip for customers, as
upgrade is one time operation so user can wait for a while. For
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:
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
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
What are other possible solutions to this issue?
On Thu, Aug 21, 2014 at 5:50 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 https://bugs.launchpad.net/fuel/+bug/1356813,
change in
I see no other quick solutions in 5.1. We can find the difference in
packages between 5.0 and 5.0.2, put only updated packages in tarball and
get missed packages from existing repos on master node.
On Thu, Aug 21, 2014 at 5:55 PM, Mike Scherbakov mscherba...@mirantis.com
wrote:
What are other
Hi,
Hmm.. I think ~15 minutes isn't long enough to skip this approach in production.
What about using lrzip only for end-users, but keep regular tarball
for CI and internal usage?
Thanks,
Igor
On Thu, Aug 21, 2014 at 5:22 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote:
I see no other quick
Hi,
I think 15 minutes is not too bad. Additionally, it will reduce download
time and price for bandwidth. It's worth to leave lrzip for customers, as
upgrade is one time operation so user can wait for a while. For development
it would be nice to have the fastest solution to boost development
10 matches
Mail list logo
