The discussion started here: Switch to 'network' directive instead of ifcfg by ShimShtein · Pull Request #9961 · theforeman/foreman · GitHub.
The main argument is that oVirt is not too healthy, and RHV is deprecated.
The advantage of this step is to simplify our code base and shrink our maintenance burden.
Thanks for bringing this up.
What is the scope of the proposal? In the PR the initial idea was only to drop the kickstart template.
In my point of view oVirt itself seems still to be maintained although RHV is deprecated. The latest release was made GA on the 1st of December 2023 with 46 contributors working on it. Additionally Oracle Linux Virtualization Manager is still a downstream product of oVirt.
Indeed, the original idea was to get rid just of the template, but it looks like we will just remove a specific feature from oVirt support.
I think that if we have decided that we don’t want to support oVirt, we should remove the support across the board and not to remove it feature-by-feature until it becomes unusable.
The latest release was made GA on the 1st of December 2023 with 46 contributors working on it. Additionally Oracle Linux Virtualization Manager is still a downstream product of oVirt.
This is a good argument to continue support for oVirt at least for a while, although I know @ekohl already experienced some problems with installing it. I’ll let him to explain this further.
Well, I guess continuing the support of ovirt is just a matter of “who will do the actual work in foreman / fog-ovirt”
My initial reaction was on the kickstart. Diving deeper into that, I now see that procedure to install using Satellite is documented on for RHV: Chapter 6. Installing Hosts for Red Hat Virtualization Red Hat Virtualization 4.4 | Red Hat Customer Portal
I did see issues installing the oVirt SDK on my Fedora with a newer Ruby version. So it may show up as a blocker when we want to update to Ruby 3.2 or newer. The last release was in 2021 (ovirt-engine-sdk | RubyGems.org | your community gem host) and I see the last commit would fix the issue I see:
replace rb_cData with rb_cObject, making it compatible with ruby 3.1 … · oVirt/ovirt-engine-sdk-ruby@97df88c · GitHub
An issue to create a new release has been open for about a year:
I’ve left a comment there. If there’s no release, we need to drop support once we upgrade to Ruby 3.1. Timing wise that may be Foreman 3.10 or 3.11. Technically Ruby 2.7 is already EOL since March 2023 and Ruby 3.0 is EOL in March 2024.
So unless there will be a new release, we won’t be able to have oVirt support once we switch to Ruby 3.2, which will be Foreman 3.12 at most IIUC.
It would be a good thing to warn the users at least one version in advance that the support will end, but I understand that if a new version would be released, we will have much more time to support the project.
Should we put some sort of a cut off date, where we decide that we need to add the deprecation warning?
As @ekohl said in 4.4.2 release? · Issue #4 · oVirt/ovirt-engine-sdk-ruby · GitHub, they need to update to new ruby and then we are good to go again. No pressure to drop ovirt - especially because foreman need to update to newer ruby first 
@Bernhard_Suttner Debian 12 has Ruby 3.1. You’re right that we need to support Ruby 3.1 and that implies updating to Rails 7, but we’re considering that for Foreman 3.11.
Then the question becomes: do we ship oVirt only on EL8, EL9 and Ubuntu 22.04 or bite the bullet and remove it altogether? For consistency I’m tempted to be consistent and drop it everywhere. If such a fix has been in a code base for a year without a release, that’s sign it’s unmaintained. I have fond memories of RHEV and later (after it was open sourced) oVirt but it’s also good to be realistic.
If we’re looking at a timeline of dropping it in 3.11 then we need to deprecate it in 3.10. That branches in about a month. So I’d like to reach a conclusion on this.
From the survey in 2020, there were 12/128 respondents who mentioned they provision on oVirt, which is less than 10%. 4 years later, I would think the percentage would be even lower. Given the resources and size of our project, I’d prefer to reduce the codebase and focus the reduction on things, that are used by only small portion of our userbase. oVirt seems to fall in this category. Also in this case, people can still treat oVirt VMs like baremetal (like many do with VMware). So 
on dropping.
I can’t say, how big overhead it would be to extract the code to the plugin, so we can revive it in case dependencies get fixed. If it is not significantly more work, perhaps that’s an option too. We had plugins which didn’t work for few releases but were updater later.
We are currently discussing internally, how we want to step in regarding oVirt maintainance. Especially because oVirt is the base for RHEV and Oracle Linux Virtualization Manager - which is still used by some.
While we have some customers using oVirt/RHEV/OLVM, all of them are Monitoring customers and no Foreman users. So no objection on my side to drop it if required.
RHV has an EOL date in August 2024, but the extended date is August 2026:
The extended date is still quite far in the future, so I’ve raised it internally with the RHV folks to see what we should do with this.
For the orcharhino use case we’d be ok when oVirt would be shipped only on EL8 and EL9 or if the functionality is moved to a new plugin. We’d be glad to help maintaining the new plugin if that’s the decision.
@hlawatschek the problem is that the whole SDK it’s built around doesn’t install on Ruby 3.1 or newer, until a release is made. We are going to deploy on Ruby 3.1+ eventually and if it’s dead, then you’re probably signing up to maintain the SDK (either directly upstream or in a fork). Moving it into a plugin isn’t worth the effort IMHO: we already have a mechanism to disable the support and if the SDK isn’t maintained I’d worry about the whole project.
The answer I’m getting is that everyone who used to maintain the Ruby SDK has moved on (they were part of the ManageIQ team). I’ve raised it (per recommendation) on the upstream devel list:
https://lists.ovirt.org/archives/list/devel@ovirt.org/thread/ESA4LFSQ5JPQWUGXTA7K7GAJJQUUEHXP/
But I have a feeling we should proceed with the deprecation and removal plan.
As a long-term user of both Foreman and oVirt I do understand that deprecating oVirt looks like the obvious choice. However, oVirt is not dead yet and it’s not a trivial task to replace such an environment. Keeping oVirt support alive for this (Ruby) release cycle would be extremely helpful. 
AFAICT, the bugfix was already merged and only a new release of ovirt-engine-sdk-ruby is required.
TBH, I would not know which other Compute Resource to use with Foreman, as almost all the remaining ones are either closed source or public clouds. 
If you think there is something I should/could do to help with this issue, please let me know.
(FWIW, the nightly snapshot seems to contain the bugfix, judging from the commit ID: Index of /results/ovirt/ovirt-master-snapshot/centos-stream-9-x86_64/04863120-rubygem-ovirt-engine-sdk4/)
Well it looks like the removal of oVirt is quite inevitable, whether we decide to do it soon or we postpone the decision to a later date.
In order to prepare to this, what would y’all say about extracting oVirt to a plugin as the first step? This should make the removal step much easier later on, but in the meantime it will already clean up the core code base.
Plugin is always nice. All compute resources should be a plugin.
Maybe we should think about a “foreman_opentofu” which is using opentofu (open source of terraform) to speak to a lot of different compute resources.
This is an interesting idea. I have heard a lot of people using Terraform, maybe we can get them onboard Foreman too.
This would be an interesting discussion to have at FOSDEM 