-
Notifications
You must be signed in to change notification settings - Fork 1k
Fixes #38267 - rake ovirt:drop #10469
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@Lennonka text review please. This should also be documented in the upgrading workflow. The versions to chery-pick have not been decided yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stejskalleos want me to test this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without looking at the exact code I'd expect an RFC for such a user visible change as well as deprecation notices in the release notes.
The code removal will follow in the upcoming PR
This will also need packaging changes since we have a foreman-ovirt
subpackage.
Good point, I'll create an RFC. I was under the impression that the deprecation was announced, but looking at the documentation code, it seems like it was deprecated only for Satellite.
Yop. Packaging and installer PRs will be in the scope. |
@chris1984 QE's will be testing it before the merge, but if you have time, It will be good to have it tested by dev as well |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the rake task I'm wondering if we should somehow generalize it so it could be used for more compute resources. I have some vague recollection about users wanting to disassociate VMs from the UI, but I think that was also from before you could avoid deleting a VM when you deleted the Foreman host.
lib/tasks/ovirt.rake
Outdated
end | ||
|
||
def ask_user | ||
puts "!!! WARNING !!! This operation is irreversible." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically you can link them back up so I'm not sure it's really that irreversible. Just quite a bit of work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a couple of nitpicks. + I agree with Ewoud
@ColeHiggins2 for your visibility: this is something to keep track of for Foreman 3.14. |
@stejskalleos I think you also need to remove compute_attributes from the relevant compute profiles. |
31a6711
to
b0e3699
Compare
@ekohl @Lennonka Log messages fixed @ShimShtein Compute Attrs should be removed together with the compute resource, see https://github.com/theforeman/foreman/blob/develop/app/models/compute_resource.rb#L28 |
b0e3699
to
9230fd7
Compare
|
9230fd7
to
bb66d18
Compare
bb66d18
to
7e1818d
Compare
Not sure why the CI is failing but the PR is ready for re-review. cc @chris1984 @ekohl |
And it's all green! @nofaralfasi can you review please? |
To be explicit: you want this in 3.14? |
Why would a user want to remove all compute resources of a provider while keeping the hosts? Is that a valid use case? |
Depends on their migration plan. This way they don't need to migrate their hosts, but they can no longer do things like power management or delete the actual VM. IMHO that's valid. It may also be that they will bulk migrate them to some other platform and don't want to import them again. Instead, they can (if Foreman supports the compute resource) link them back up to the new CR.
I think that's dangerous. Deleting hosts will terrify any sysadmin. Worst case you wipe out an entire infrastructure. Hostgroups may also be mixed.
A noop mode is generally speaking a good idea, listing what would be affected. |
It would be nice to have it there, as it gives users more time for migration and preparation. But it's not a requirement.
I want to leave that up to the user. As @ekohl said, removing hosts and host groups might be terrifying.
I'll add it; that's a good idea. |
7e1818d
to
0ea0efd
Compare
Updated:
|
0ea0efd
to
f3989b4
Compare
And it's 🍏 |
@stejskalleos |
@nofaralfasi any comments, or can we merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another suggestion: You have multiple methods that print a message and exit. Why not refactor them into a single method that takes a message and an exit status as arguments?
Most of them have multi-line output, and storing that output in a variable and then passing it to the method is not very readable, IMO. So, in this case, I chose readability over DRY. |
f3989b4
to
5823f82
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left all my notes and let Leos decide which ones to address. Other than that, the code looks good to me, but I didn’t test it.
Rake task for removal of Ovirt compute resources and its data - Disassociate all hosts from the CR - Update host groups - Remove Compute resource & its profiles
5823f82
to
f74dc3b
Compare
@nofaralfasi Sorry, my bad, I accidentally missed the |
@stejskalleos |
Rake task for removal of Ovirt compute resources and its data
Note: