Open kpollich opened 11 months ago
Pinging @elastic/fleet (Team:Fleet)
Fleet has some extensive logic around this derived is_agent_upgradeable flag here: https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/common/services/is_agent_upgradeable.ts
One of the conditions in this logic is:
if (!agent.local_metadata.elastic.agent.upgradeable) {
return false;
}
AFAIK the agent.local_metadata.elastic.agent.upgradeable
variable here is ultimately sourced from the boolean local_metadata.elastic.agent.upgradeable
field that Agent sends the to Fleet in check-in API requests. If so, we'll probably want to add a sibling field, e.g. local_metadata.elastic.agent.upgradeable_reason
or similar, to convey the reason why Agent is not upgradeable.
AFAIK the agent.local_metadata.elastic.agent.upgradeable variable here is ultimately sourced from the boolean local_metadata.elastic.agent.upgradeable field that Agent sends the to Fleet in check-in API requests. If so, we'll probably want to add a sibling field, e.g. local_metadata.elastic.agent.upgradeable_reason or similar, to convey the reason why Agent is not upgradeable.
Yes this is accurate. Fleet can do a best effort for some of the other derived values in that file above, but I'd expect most cases where this is disabled to be a result of that local_metadata
flag. Perhaps an enhancement to agent where a specific reason code is surfaced in this metadata that explains an agent is running under hypervisor, was installed via .deb
or .rpm
archive, etc etc that Fleet can eventually pass through to the UI would be good to track here as well.
I've added some implementation detail tasks here. We'll need contributions in both Fleet and Agent to make this happen.
cc @jen-huang @jlind23 for prioritization.
This might be related https://github.com/elastic/elastic-agent/issues/3906
Even a link to a doc laying out all possible reasons for an agent being "not upgradeable" can go a long way.
I have a PR where I'm doing something similar, I'm returning a message explaining the reason why the agent is not upgradeable.
I'm sure that this could be handled in a better way if we do further changes to the elastic agent, as for now when the agent returns "not_upgradeable" Fleet has no way to know why.
https://github.com/elastic/kibana/pull/173253 would be a good first step before doing all the changes from Elastic Agent to Fleet.
Tooltip and a warning message explaining why an agent is not upgradeable were merged in in 8.13. I think that we'll need some work on the elastic agent side to be able to implement the rest of the points outlined in the description. Do we know if that part was already implemented in elastic agent? If not, I think we'll need to move this ticket to blocked until it's done. cc @kpollich @jen-huang
Do we know if that part was already implemented in elastic agent? If not, I think we'll need to move this ticket to blocked until it's done.
AFAIK it is not done yet, maybe @pierrehilbert has a tracking issue that we can reference here.
This is not implemented in Elastic Agent yet. We don't have a dedicated issue (at least that I'm aware of) about this. The most related one is https://github.com/elastic/elastic-agent/issues/3906 that includes this work.
Currently, Fleet will disable the "Upgrade" action in the actions dropdown when an agent is determined to be non-upgradeable. We should try to surface why this is in a tooltip.
Fleet has some extensive logic around this derived
is_agent_upgradeable
flag here: https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/common/services/is_agent_upgradeable.tsWe should add a notion of "error codes" or some kind of status string that maps to a meaningful human readable message we can report in a tooltip when hovering over the disabled "Upgrade" action.