-
Notifications
You must be signed in to change notification settings - Fork 40
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
Do not unset release if release target is defined #159
Conversation
Reviewers, please refer to the issue here for additional background and discussion. |
I think we would need to test the code but from just looking at it, I think it looks good |
When I get a moment later today, I will add an assertion to make sure that That or, if preferred, we can just add a boolean variable that defaults to true for the unset task. Or we could even do both. |
I think it makes sense to include a task to set it to the desired destination release for the version of RHEL upgraded to as well. |
@jeffmcutter do you mean having a separate |
That is what I was thinking. I'm not sure how common it would be, but with the right conditionals it would be harmless and potentially helpful. |
@djdanielsson @heatmiser How's this? |
Oh hold on, I forgot to add to README.md and add a changelog fragment. |
I believe this feature is going to be required for RHEL 8 High Availability cluster to RHEL 9. I will test using this PR. |
Thank you for testing, @jeffmcutter. I just resolved some merge conflicts as well. |
This is not the case specifically for the HA, I misread the docs on that. Still testing. |
Tested successfully. @swapdisk OK to merge? |
Fixed sanity checks. I had created the change fragment in browser, which created it with dos line-endings instead of unix. Should be good now. |
can you fix the conflict? |
@djdanielsson done |
@djdanielsson What do we need here? #174? I think it would be good to get this merged. |
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.
LGTM
This is a proposed fix for #134.
It doesn't have any changes to docs or anything like that for the moment, but the idea is that you can set the leapp_target_release variable to some release version, and that will add it to the leapp commands for analysis/upgrade as well as preventing it from being unset in the post-upgrade steps.
Perhaps a boolean true/false would be preferred for stopping the release from being unset?