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
Fixes #35947 - Consume install_all param when finding hosts #10416
Conversation
7ab0a51
to
667db98
Compare
667db98
to
674bf03
Compare
I'm not reproducing the issue because, with this particular workflow, Katello keeps using katello-agent even though I selected to use remote execution by default. What else did you do to get it to use remote execution? I'm assuming that the issue only occurs when remote execution is in use. I'm not reproducing the error with katello-agent. |
You shouldn't have to, but you could try disabling katello-agent via the installer with |
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 found a general issue with this workflow -- install_all
will try installing errata on hosts that do not have that errata marked as applicable. To reproduce the issue, try having two hosts, but only one has an erratum that is applicable. The remote execution job will be run for both hosts instead of just the one applicable host.
Finally got this set up, but I'm not seeing the issue. My REX job is scoped correctly to |
@jeremylenz do you have a host that has no content facet? I have one host with a content facet and one without, that's the only difference I could potentially see with my setup ... |
So strange, it really is applying it to all of my hosts. |
Edit: it looks like this method is being called multiple times, and one of the calls is wrong somehow. |
In the remote execution controller in Katello, my In my params I see this: It really doesn't make sense, but it seems the install_all param is failing to be passed along from the UI. |
I reproduced the issue I found on a separate Katello development environment that is also on a different computer. I'm using Firefox (but I saw the same in Chrome). Screencast.from.02-06-2023.05.28.56.PM.webm |
From debugging: [8] pry(#<Katello::Api::V2::HostsBulkActionsController>)> params[:install_all]
22:39:47 rails.1 | => nil
[9] pry(#<Katello::Api::V2::HostsBulkActionsController>)> bulk_params[:included][:ids]
22:40:02 rails.1 | => []
[10] pry(#<Katello::Api::V2::HostsBulkActionsController>)> bulk_params[:included][:search]
22:40:17 rails.1 | => "( applicable_errata = \"RHEA-2012:0055\" )" |
What's weird is, I don't have install_all, but I do see a param called just "all":
This Edit: In my debugging, when I don't have |
Hmm.. 🤔 Does a manual host search for |
That returns only the correct host. |
674bf03
to
a053311
Compare
@ianballou Updated; give it another whirl ♻️ |
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.
Looks good to me! I tested with page size of 1 so we know that it works across pages. I also tested some of the bulk errata workflows to ensure nothing there was broken.
Looks like an angular test is failing |
a053311
to
4ac5ef5
Compare
What are the changes introduced in this pull request?
When selecting all hosts on the Errata page, Bastion was sending an
install_all
param but the backend was ignoring it. This resulted in an error "No hosts have been specified."In addition, after fixing that I discovered that Bastion was only sending the
ids
param and not thesearch
param, resulting in the "all hosts" selection meaning "ALL hosts, not just those with this errata applicable." That should be fixed now too.Considerations taken when implementing this change?
The bulk errata controller seems to be the only Angular page that sends the
install_all
param. The name is a bit misleading because it's sent when selecting hosts, not errata.What are the testing steps for this pull request?
Before this patch: You'd get an error that no hosts have been specified.
After this patch: You'll be taken to the remote execution job.