-
Notifications
You must be signed in to change notification settings - Fork 8k
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
[Fleet]: Able to upgrade by adding lower version than agent version under Upgrade agent flyout. #180791
Comments
Pinging @elastic/fleet (Team:Fleet) |
@amolnater-qasource Kindly review |
Secondary review for this ticket is Done |
The upgrade is failing when using a lower version, right? It seems only the UI validation is missing to prevent entering a lower version manually. |
Yes, it triggers the upgrade with lower version, however the upgrade gets failed. |
I wouldn't want to widely allow downgrades until the discussions in #172745 are resolved. We definitely don't test all the possible combinations of downgrades (e.g. 8.13.2 -> 7.17.x) the way we do for upgrades. |
Safest thing thing to do is to forbid them from the UI but still allow them from the Fleet API if that is possible. |
I'm sure that is possible. Will take a look. |
@juliaElastic @kpollich I would like to get your thoughts on the approach in #182530 before I spend more time on it. We have good checks for upgradability when only a single agent is selected for upgrade. And if that agent is not upgradable, we return a detailed message about why. We don't apply the same for multiple agents, and I don't think we can if the list is by kuery, but the changes in that PR apply the same checks and messages for a discrete selection of agents. Do you think this approach might be too heavy handed? For example, if 20 agent are selected and only 1 of the 20 is not upgradable, this PR disables submitting the upgrade entirely and returns the first error message found from the list of agents: I can almost see the original behavior as a feature in which we allow users to attempt upgrading any number of agents and let any failures surface as they may, rather than attempting to foresee failures in the UI. WDYT? |
Yes, I think we don't want to be too restrictive with bulk upgrade, as the upgrade will fail anyway for agents that don't support it. We could do a similar approach to |
Yes this is the intended behavior. Failed upgrade are surfaced via agent activity, but we don't "overvalidate" the list of selected agents to determine their compatibility with the desired upgrade configuration. We used to perform more validation when selecting agents, but it was the cause of many bugs and broken states in the agent table, so pushing the validation to the backend and allowing errors to be reported async in the agent activity flyout is the desired approach as of now. |
Just to double check on this, these errors include validation that would be done by Kibana itself? Agent today doesn't refuse downgrades, so if you dispatch a "downgrade" action the agent will do it. |
Yes, the Kibana Fleet API validates a few things, including downgrade, that is not allowed. |
So it looks like we shouldn't take any action for this bug as far as validating the version input for bulk upgrade on the frontend, since restricting downgrades is already happening at the API level. Thanks folks.
@juliaElastic Could you tell me more about this? Do you mean that currently |
|
Thanks @juliaElastic, so you mean that we could show a count of eligible agents after a version is selected, i.e. X out Y agents who have a lower version than the one selected. That makes sense to me. @kpollich WDYT about doing that as a separate enhancement and closing this bug? IMO there is no bug here, the permissive selection and surfacing downgrade errors later on is by design. |
+1 from me - a new feature to display the count of eligible agents for the action dynamically makes sense. Do you mind filing an issue for that? I'll close this bug in the meantime. |
I created #182899. |
Kibana Build details:
Host OS: All
Preconditions:
Steps to reproduce:
Expected Result:
User should not be able to upgrade by adding lower version than agent version under Upgrade agent flyout.
Screen Recording:
Agents.-.Fleet.-.Elastic.Mozilla.Firefox.2024-04-15.16-50-38.mp4
The text was updated successfully, but these errors were encountered: