Seemingly random provider support for Ubuntu (maybe other) images??

[skyscooby]

Why does every version released not support all the providers that you support?

https://portal.cloud.hashicorp.com/vagrant/discover/bento/ubuntu-24.04/versions
For instance someone using virtualbox or KVM is stuck using the old version..

https://portal.cloud.hashicorp.com/vagrant/discover/bento/ubuntu-22.04/versions
Or someone using vmware-desktop (workstation).. is stuck using a 2 year old image...

It's annoying because you have to explicitly pin a version in your Vagrant file otherwise developers start getting issues when new released versions are kicked out as the 'latest' version no longer supports a provider that the previous version did. It would seem fine to add new providers in later versions but randomly dropping and adding them in seemingly arbitrarily is strange.. can't you get a green CI build for all images before you push to Hashi cloud?

==> box: Loading metadata for box 'bento/ubuntu-22.04'
box: URL: https://vagrantcloud.com/api/v2/vagrant/bento/ubuntu-22.04
This box can work with multiple providers! The providers that it
can work with are listed below. Please review the list and choose
the provider you will be working with.

1. parallels
2. virtualbox

[Stromweld]

I'm Managing 26 OS versions X 5 virtual providers X 2 cpu architectures. With OS updates, provider updates etc... getting them all to be green is constantly a work in progress. I'm also currently the only active maintainer doing this on the side. I don't have the time to fix all OS issues for each provider. I strive to get at least the big 3, virtualbox, paralleles, and vmware-player/fusion. According to our readme those are the primary providers we support. There have been times for certain boxes if I didn't skip a provider there would then be no updated release for a long time.

Ubuntu 22.04 link shows vmware-desktop's last build 202401.31.0 which is only 1 year old.

[Stromweld]

I'm currently working on new a new release of all the boxes and have images for the big 3 providers for almost all boxes. just fighting RHEL 8 variants and issues with Parallels and VMware builds as well as Both Freebsd versions and Fedora 40 along with all 3 for Fedora 41 and CentOS-Stream 10.

I'm happy to accept any PR's if you have fixes for scripts, packer templates, etc...

[skyscooby]

Thanks for all your work @Stromweld. I suppose given this is a corporate thing the only people who could offer to help you reside in your organisation? I suspect it requires a lot of hardware / infrastructure to be able to accomplish this diversity..

Ubuntu 22.04 link shows vmware-desktop's last build 202401.31.0 which is only 1 year old.

The issue is not really with the age as it with the user experience.. not entirely your fault.. Vagrant could improve itself by recognising there is an older tag for these images for a given provider and make 'latest' track each provider individually.. but I doubt they will change that.. I suppose you could name your images like ubuntu-vmware ubuntu-libvirt to allow you to only release the images that work any given run. I guess we will just have to treat the image as a software dependency and pin it.. it's good practice I suppose anyway...

[skyscooby]

It also may be worth looking at any metrics you may have on usage and dropping support for any less popular providers or OS's unless there is a mandate to do one for every OS.

[skyscooby]

Also @Stromweld u suggested 202401.31.0 but it is missing KVM/libvirt which is the best choice for local linux development since it's already present in the kernel... If I go back to 202309.08.0 I get all the providers available but this build is only x86_64 which leaves my MacOS silicon users using CPU emulation or a different Vagrantfile.

[Stromweld]

Ah I see the pain point now. It never did that before when it was vagrant cloud. Latest version would grab the the most recent version of a box based on the provider and box not just latest version. That let you upgrade any provider with a new version or bug fix without having to update all others. I haven't done a release since it was migrated to hcp packer cloud. It may be just a weird issue with the migration of the boxes from vagrant cloud to hcp. I'm working on a big release and have almost all the boxes working for the bug 3. No libvert or hyper-v though. I should be releasing that next week. I'll play with some boxes on my personal hcp cloud account and see if it was just the migration or if that's the new behavior of hcp. May be worth bringing up in hashi's vagrant repo. If you do let me know as I'd like to follow that issue then. I'll also try to keep that in mind for future updates and releases.

[skyscooby]

@Stromweld why no for libvirt? is that broken? the most recent 202309.08.0 image adds an extra 3-4 minutes of wait time updating packages for each up/destroy/up cycle.

Is there an easy way your know to take this image, update it, then re-publish it with a newer date to reduce that wasted time?

[skyscooby]

Basically resorting to doing this..

  config.vm.provider "libvirt" do |pv, override|
    override.vm.box_version = "202309.08.0"
  end
  config.vm.provider "virtualbox" do |pv, override|
    override.vm.box_version = "202407.23.0"
  end
  config.vm.provider "vmware_desktop" do |pv, override|
    override.vm.box_version = "202401.31.1"
  end

[tomjn]

Noting I've come across this while trying to figure out a parallels problem, it looks like all the -arm64 boxes disappeared from vagrant cloud and got rolled into the main ones. I've had to change the box name for ubuntu 20 and add a check for arm64:

  config.vm.provider :parallels do |_v, override|
    override.vm.box = 'bento/ubuntu-20.04'

    # Pin the arm64 version of the box to a specific version we know has an arm build.
    if Etc.uname[:version].include? 'ARM64'
      config.vm.box_version = "202404.23.0"
    end
  end