I’ve heard that for fixing GCE support, we’ll need to bump fog gem to >= 2.0. Also Azure support would need it. That will potentially have an impact on all compute resources. At the same time, I proposed to update fog-aws and I’ve seen fog-libvirt was recently updated. It seems like there’s a lot going on at the same time.
I think we should merge all the changes ASAP as it’s shortly after the branching. I also spoke with our QE and they volunteered to help us testing all compute resources on nightlies. In order to coordinate all of this, I’m starting this thread where I’d like to keep the list of related PRs and testing status.
If you have some related work to this, please update the main post or let me know to update it.
The suggested order that we’ll start with tomorrow (19.3.), me and @ekohl will be working on this:
release new foreman-docker for “remove only release”
get the Katello dependency removal merged or release 5.0.1 restoring the compatibility with Katello so they can be coinstalled
merge the new version of foreman-docker in foreman-packaging rpm PRdeb PR
merge the gce update on core PR
merge the vsphere update on core PR
rebase openstack PR and merge that
open a PR with fog-openstack bump (part of the big PR below)
merge foreman-packaging PRs for aws and gce and the fog-openstack as a single PR
merge the big packaging PR
We also ship rackware compute resource in core, no idea if it is working or not but the fog gem seems not very maintained - https://github.com/fog/fog-rackspace - so i think we need to either take it over and update it or extract it from core to a plugin.
regarding proxmox - @Bernhard_Suttner do you have contact with the author? we need their cooperation to move it to the foreman organization, as well as making sure a couple of other details are handled, iirc making sure there is packaging for it and giving theforeman user ownership on rubygems (@ekohl or @Gwmngilfen might recall if there are other requirements).
We’ll need @tristanrobert’s help to move the repo (which could be forked, but obviously better not to) and to have community access to the gem (which has no other workaround). If you’re interested @tristanrobert, then I can let you know what’s needed
Thanks, I’ve created the team, added you to it, and given it admin rights. You should basically be able to do anything you could before . Just need the gem authors now.
I am not sure if someone is still using Foreman with Compute Resource Opennebula, but our Managed Service team has switched to OpenStack, so will probably not test and fix it.
An update on current status: we bumped fog-aws in develop branch, which now requires fog-core 2.1.0. It turned out there are few compute resources which requires fog-core to be < 2.1.0. We’re now investigating if fog_azure_rm and fog-google could be update to work with fog-core 2.1.0. Details can be found at https://github.com/theforeman/foreman/pull/6475. The other option to revert fog-aws, though adding more compute resources using old version of fog seem as adding more work for future. Other affected compute resources are foreman_docker and foreman_kubevirt.
So we settled on fog-core 2.1.0. Here’s the first packaging update that should bring newer fog-aws while using versions compatible with upcoming fog-google and fog_azure_rm. These will be added as separate PRs.
I filed OpenStack fog upgrade, did some minor updates and I can confirm that 1.0.8 works fine against OpenStack v2 API. I have no access to v3 instance tho.
I’ve updated the first post with the order of things we plan to do tomorrow with @ekohl. There may be some nightly issues caused by this, but we’ll try to minimize it and fix asap. If there’s something you know we missed, please let us know, I plan to start tomorrow morning.
Upgrade is done. Thanks to @evgeni, @ekohl and @tbrisker we have now packaging up to date. As part of repoclosure testing we realized we need to remove foreman_one which does not seem to be used and hopefully just temporarily disable foreman_fog_proxmox which is not ready for fog-core 2.1.0.
The repoclosure is now green, meaning nightly repositories should have new versions soon. We’ll do a sanity check and confirm here once that happens. Then we can start testing provisioning on all affected compute resources.
