[Fleet] Add tooltip when upgradeable = false and "Upgrade agent" action is disabled

[kpollich]

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.ts

We 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.

Tasks

Beta Give feedback

1. Add logic to Fleet UI to render a basic tooltip with the available upgradeable reason text
2. Update Fleet to pass along the upgradeable_reason value in the tooltip if agent provides it #192427
   Team:Fleet +1

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[ycombinator]

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.

[kpollich]

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.

[kpollich]

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.

[lucabelluccini]

This might be related elastic/elastic-agent#3906

[amitkanfer]

Even a link to a doc laying out all possible reasons for an agent being "not upgradeable" can go a long way.

[criamico]

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.

[jlind23]

#173253 would be a good first step before doing all the changes from Elastic Agent to Fleet.

[criamico]

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

[jlind23]

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.

[pierrehilbert]

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 elastic/elastic-agent#3906 that includes this work.