Hide Forgot
Description of problem: The deltarpm package is not installed in the appliance, which means it cannot be efficiently (bandwidth-wise) be updated. Version-Release number of selected component (if applicable): master
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
The appliance uses a default CentOS/RHEL installation. If deltarpm is not installed by default, then the question is: Shouldn't vdsm require or host-deploy install deltarpm, to ensure that pure CentOS/RHEL hosts will also benefit from this?
(In reply to Fabian Deutsch from comment #5) > The appliance uses a default CentOS/RHEL installation. > > If deltarpm is not installed by default, then the question is: Shouldn't > vdsm require or host-deploy install deltarpm, to ensure that pure > CentOS/RHEL hosts will also benefit from this? Something should - but I'm concerned about the order of installation. Delta RPM has to be available before downloading the appliance. At least in RHVH, the best place would be in the base image (I have no idea why it's not part of base RHEL!).
Having deltarpm outside of the image - thus on the host where the appliance is received - will not have any effect for the appliance download. The reason is that the appliance image is to large for deltarpm. It will only have a benefit if we install it inside the appliance, in that case package updates which are performed inside the appliance will benefit. However, deltarpm is not distributed with RHEL, thus we can only include it in upstream.
(In reply to Fabian Deutsch from comment #7) > Having deltarpm outside of the image - thus on the host where the appliance > is received - will not have any effect for the appliance download. The > reason is that the appliance image is to large for deltarpm. I thought the max size is configurable. > > It will only have a benefit if we install it inside the appliance, in that > case package updates which are performed inside the appliance will benefit. > > However, deltarpm is not distributed with RHEL, thus we can only include it > in upstream.
Internall deltarpm uses bsdiff, which has some pretty high requirements: "bsdiff uses memory equal to 17 times the size of ⟨oldfile⟩, and requires an absolute minimum working set size of 8 times the size of oldfile." These can often not be met for the appliance image which is roughly 1GB in size. In my attempts bsdiff always failed to create a diff between two images. Further more: I'm pretty sure that a diff will not yield any valuable results, as we are performing a diff on compressed files, and compressed files - even with close-to-the-same-content - can significantly differ when looking at the compressed data. If we wanted to get a valuable diff then we'd need to ship a tarball with a sorted list of files the rpm. As even a raw fs image would not help, because block allocation(during the creation and population of the image) is dynamic and can lead to completely different layouts in multiple runs. But then - even with an image which only changes little between two builds - the size limitation of bsdiff still stands.
Closing based on comment 9 .