-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloud images should be usable also after a new release #126
Comments
@kbsingh Please modify/add more information as you see fit. We have discussed it more thoroughly on #centos-devel. @lpancescu FYI |
From the description, it looks like the known limitation in vagrant-vbguest. It's possible to install the VirtualBox Guest Additions across point updates with the current CentOS repo structure, as I've done in cloud-instance-starter-kit, but not how vagrant-vbguest tries to do it. The VirtualBox Guest Additions are not necessary for our Vagrant images and they bring a number of problems:
Networking works as it is, and NFS or vagrant-sshfs can be used for file sharing. But if @kbsingh and the core team want to do the necessary changes to the CentOS repos to accomodate vagrant-vbguest, it's fine with me. |
I understand that my specific scenario is with vagrant-vbguest. However I can phrase it differently so it doesn't include vagrant-vbguest: When I use a ready made image, I do not expect the first operation on it to be an update and a reboot. I understand that it is recommended, but it must not be necessary. |
I seem to have just been bitten by this issue. Any progress on this? |
No, and there's nothing I can do about this on the image side. When a new point release appears, the previous ones are no longer supported and will be moved to vault. We can try to speed up producing the Vagrant images after a point release, but images you already have will always have this problem when creating a new instance. I don't really think the CentOS core team would be willing to change how the archive is working just to appease a bug in vagrant-vbguest, which its authors could probably change to try vault if they don't find the package in the normal archive. I think your best chances are either to convince vagrant-vbguest to enhance their implementation, use my starter kit linked above, or just don't use the VirtualBox Guest Additions, which aren't necessary (I've never used them, they just slow down kernel updates with no practical benefit). |
Understood. It's truly unfortunate the core team have taken that stance with how the vault/archiving process works. More and more as issues like this crop up I get feedback from teammates and others that tell me other distributions (such as Ubuntu or even Fedora) are more reliable so these things are doing real harm to the CentOS "brand". Ironically, it feels like this has been getting worse since RedHat increased involvement/funding in the product. That said, which is the appropriate project to raise this issue under? |
@yeroc said:
I'm not a part of the core team, but I think moving old packages into vault makes sense: there is no support for older point releases, neither assistance on the mailing lists or IRC (you'll be told to upgrade first), nor, most importantly, security updates. Having vulnerable packages in the main archive is not what anybody wants, because someone might end up installing them. vagrant-vbguest is in the best position to make this work, I would try contacting its authors if I were you. As a matter of policy, I will not engage in any discussion regarding the merits of different Linux distributions. If you think something else serves your needs better, that's your personal choice and I respect that. Besides, this is an issue tracker, not a forum for such discussions. |
When using cloud images (specifically Vagrant/VirtualBox images), older image releases will lack packages in remote repositories, rendering those images useless for some.
A concrete example is image version 1803.01 on the day of writing this ticket. The image ships with kernel-3.10.0-693.11.6, yet kernel-* packages with the corresponding versions are nowhere to be found (like kernel-devel-3.10.0-693.11.6). Those packages are also not in the vault repositories.
An update+reboot can solve the problem, however part of the idea of having a cloud image is to not have to update+reboot it as the first operation.
The text was updated successfully, but these errors were encountered: