Closed harshitgupta-qasource closed 1 week ago
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. Thanks
I wouldn't want to widely allow downgrades until the discussions in https://github.com/elastic/kibana/issues/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.
How should we move forward on this bug for now @cmacknz @kpollich? Shall we add validation to prevent lower versions?
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.
(My first time working in this area of the code, so just documenting some discoveries.)
It appears we do have validation for preventing downgrades but only when a single agent is selected:
I will look into having this kick in when multiple agents are selected, but similar to checks we do for other bulk agent actions, it probably won't be able to be done for agents by kuery, only for a discrete amount of agents.
@juliaElastic @kpollich I would like to get your thoughts on the approach in https://github.com/elastic/kibana/pull/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 Restart upgrade
for bulk selections, where the restart will only apply for agents which are stuck in updating.
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 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.
. Failed upgrade are surfaced via agent activity,
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.
We could do a similar approach to
Restart upgrade
for bulk selections, where the restart will only apply for agents which are stuck in updating.
@juliaElastic Could you tell me more about this? Do you mean that currently Restart upgrade
is only available for single agents, and we should allow Restart upgrade
as a bulk action too?
@juliaElastic Could you tell me more about this? Do you mean that currently
Restart upgrade
is only available for single agents, and we should allowRestart upgrade
as a bulk action too?
Restart upgrade
is also available as a bulk action. For single agent, Restart upgrade
is only enabled if the agent is in updating state, while for bulk selections, the action is always enabled, and when clicking on it, the modal window will show how many agents out of the selection are in updating state, and only those will be included in the action.
This was added here: https://github.com/elastic/kibana/pull/166154
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.
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.
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:
https://github.com/elastic/kibana/assets/101545338/034020f4-ecd0-49e8-8a6b-bf7486d717b2