RFC: Extract oVirt Compute Resource to a plugin

fraenki · June 17, 2025, 8:50am

Moving oVirt support to a plugin is still an option.

lstejska · June 17, 2025, 8:53am

Yes, for sure, but the support is not going to be provided by the Foreman team, but by the maintainers of that plugin.

maximilian · June 23, 2025, 7:33am

Thank you for sharing your roadmap. We appreciate your effort working on oVirt and with the Foreman/Katello community. So far, ATIX has not made any decision to create and/or maintain a possible foreman_ovirt plugin. However, we are monitoring the situation, continously talking to Foreman + oVirt/RHV/OLVM users, and will report back.

fraenki · August 10, 2025, 9:56pm

We’ve created a plugin:

It’s based on Foreman 3.15.0 and mostly a 1:1 port of the old core code.

The plugin is functional. The most notable change is a new “oVirt” card on the host details page.

Some tasks are still pending, but we’ll try to complete them in-time for Foreman 3.16.0. If someone would be willing to provide a DNF/APT repository, this would be awesome.

Please give it a try. (It requires Foreman 3.16, so use the develop branch.)

Feedback, contributions, collaboration, etc. is always welcome. Please have a look at the open tasks:

This code ensures that the oVirt data is NOT removed from the Foreman database when upgrading to 3.16.0. I’m not sure if this is the best approach, so any feedback would be appreciated.

Dirk · August 11, 2025, 7:48am

No problem with packaging this in the normal repository, we have included also other plugins not in the Foreman namespace.

Dirk · August 11, 2025, 11:04am

Looking at rubygems I see a possible naming / ownership conflict you will need to solve.

fraenki · August 11, 2025, 12:35pm

Thanks! Should I submit an issue or pull-request for this? If so, where?

(FYI, I’ll try to resolve the rubygems.org name conflict.)

Dirk · August 11, 2025, 3:18pm

If you want to do the packaging yourself as a PR, you would need to do this at foreman-packaging. One for RPM, one for deb in the corresponding development branch, so it will end in nightly and then it could be cherry-picked to a release what would be required if 3.16 is already released before.
The repository does not allow issues, so if you need assistance or someone should take over and do the packaging you can ask here the packaging group (just add @ before the packaging).

Easiest for the naming conflict would be getting the old owner to give you access and then take over if he is still active. I see a Red Hat email address on Github, so perhaps someone here could assist via internal communication if there is no or slow reaction.

fraenki · August 12, 2025, 2:29pm

The naming conflict on rubygems was resolved.

I’ve submitted PRs for DEB/RPM packages:

evgeni · August 12, 2025, 2:53pm

We also need to “bring back” the RPM packages for fog-ovirt and the sdk: add fog-ovirt and ovirt-engine-sdk back to plugins by evgeni · Pull Request #12356 · theforeman/foreman-packaging · GitHub

evgeni · August 12, 2025, 3:19pm

foreman-plugins-nightly-rpm-pipeline #2288 - Jenkins passed, foreman_ovirt is on yum.theforeman.org

ekohl · August 12, 2025, 3:53pm

Does it also disable the migration that removes all resources?

github.com/theforeman/foreman

db/migrate/20250414121956_migrate_ovirt_resources.rb

develop

class MigrateOvirtResources < ActiveRecord::Migration[7.0]
  def up
    ComputeResourceCleaner.new(klass: 'Foreman::Model::Ovirt').run!
  end

  def down
    raise ActiveRecord::IrreversibleMigration, "Cannot restore migrated Ovirt data."
  end
end

evgeni · August 12, 2025, 4:10pm

There is foreman_ovirt/db/migrate/20250810212811_update_legacy_ovirt_compute_resource_type.rb at main · markt-de/foreman_ovirt · GitHub but it needs to be executed before the remove one runs

fraenki · August 12, 2025, 4:47pm

What is the proper way to disable the core migration?
I’ve added this hack, but there’s probably a better way to do this (but I just don’t know).

Dirk · August 13, 2025, 2:05pm

Just a note for all involved or looking for updating an environment with oVirt integration: We missed the branching window with this! So backporting it to 3.16 will be needed before oVirt users should upgrade!

@ogajduse is release owner of 3.16. So can you keep this in mind and add a warning to release candidates / releases if needed?

ogajduse · August 22, 2025, 9:44pm

Release notes for 3.16 in Foreman :: Manual mention the removal of RHV/oVirt Support in Foreman core. I’ll put it in the release notes in the foreman-documentation project too. Thanks for pointing that out.

Dirk · August 27, 2025, 7:03am

@fraenki and others involved: RC2 was released yesterday and GA is planned for 09.09. which is possibly a short timeframe if anything else except backporting the packages to 3.16 is required to drop/change the deprecation warning and allow for a smooth update for the oVirt users!

fraenki · August 27, 2025, 11:11am

AFAICT, backporting the oVirt packages to 3.16 would be the most important thing. Who would usually handle this?

Besides that there’s also a fix for Foreman in discussion, that would prevent the removal of oVirt data if the new plugin is installed:

And the release notes were also updated to advice users to install the new oVirt plugin.

Dirk · August 27, 2025, 11:28am

Backporting is just a simple git cherrypick -x from the development branches to the branches of the stable release. In this case you would need to cherrypick all commits related to ovirt. You can do it yourself or if assistance need let me know!

evgeni · August 27, 2025, 11:29am

@fraenki can you open PRs against rpm/3.16 and deb/3.16 that pull in all the changes we did in rpm/develop and deb/develop using git cherry-pick -x?

Edit: internet-high-five to Dirk!