Well, I guess, then we will create a plugin out of it as we still need it.
Another possibility is, to have a different approach than a separte Plugin.
We will discuss internally how to proceed.
@lstejska one more question - why did we decide to keep the hosts and hostgroups instead of deleting them?
Should we consider adding an option to the rake task to delete the hosts and hostgroups as well?
I understand this may not be something we can implement in a migration, but perhaps we could add it to the rake task to give users the flexibility to choose?
Are there any updates on the migration to the plugin?
I pushed PRs (most in WIP) for the upcoming removal in 3.16; I plan to have them ready and merged right after the 3.15 branching, which is according to the document intended for 2025-05-13.
We could just “disassociate” hosts from VMs and keep hosts as they are, right? That basically makes them being considered a baremetal machine running somewhere and we don’t know where.
When I was looking at @lstejska’s PR to add a rake task I wondered if we had anything existing already but I don’t think we do. It made made me wonder if we should create a generic disassociate feature in the API and UI for any compute resource. If we end up dropping another one (kubevirt comes to mind) we could reuse the code.
Maybe we don’t have the API for this, but in UI, you can do it. Navigate to Host edit form, on the top right you see “Disassociate host” button. I agree it’s not clear why it’s in edit form but it’s there.
That’s an unexpected place indeed. It’s also going to be quite tedious to do every host 1 by 1 so I was thinking about listing all hosts for a compute resource and then implement a bulk action to disassociate them. Either by a selection or all. Perhaps also implement a search filter.
Hello
Redhat has announced removing ovirt/rhv support in the last release : foreman 3.14 / satellite 6.17.
Does anyone has info regarding ATIX maybe creating a plugin ?
