[Fleet] Elastic Agent upgrade states UI

[jillguyonnet]

Summary

Closes https://github.com/elastic/ingest-dev/issues/1937

This PR implements the UI side of the new Elastic Agent upgrade states.

Note: the following changes will be present regardless of whether Elastic Agent has upgrade details:

• Wider Version column
• Upgrade available text is now a badge

Screenshots

Steps to reproduce

Note: the Elastic Agent changes are not ready yet, so the proposed testing steps aim to mock the upgrade states by editing the agent document(s) manually.

1. Run Kibana on this branch.
2. Enroll at least one agent (or more to test more quickly).
3. Create a "super duper user" in order to edit the agent document(s) (see below). Use this user to edit your agent document(s) and add upgrade details (see below for examples). ⚠️ These upgrade details won't stay for very long, so make sure to check the UI immediately.
4. In Fleet UI, check that the UI correctly reflects the upgrade state (badge and tooltip).
5. Check that an upgrading agent with no upgrade details correctly gets a tooltip informing that the upgrade details are not available. This can be mocked by editing the agent document again and setting upgrade_started_at to some timestamp and upgraded_at to null.

How to create a "super duper user"

In dev tools, run the following two commands:

PUT _security/role/super_duper_user
{
  "cluster" : [
    "all"
  ],
  "indices" : [
    {
      "names" : [
        "*"
      ],
      "privileges" : [
        "all"
      ],
      "field_security" : {
        "grant" : [
          "*"
        ],
        "except" : [ ]
      },
      "allow_restricted_indices" : true
    }
  ],
  "applications" : [ ],
  "run_as" : [ ],
  "metadata" : { },
  "transient_metadata" : {
    "enabled" : true
  }
}

PUT _security/user/strong_user
{

    "roles": [
      "super_duper_user",
      "superuser"
    ],
    "full_name": "Super Duper User",
    "email": "super@elastic.co",
    "password": "changeme",
    "metadata": {},
    "enabled": true
  
}

Adding upgrade details to an agent

Example commands:

POST .fleet-agents/_update/<agent_id>
{
  "doc": {
    "upgrade_details": {
      "target_version": "8.11",
      "action_id": "xxxxxxxx",
      "state": "UPG_SCHEDULED",
      "metadata": {
        "scheduled_at": "2023-10-04T16:34:12Z" // edit this to a better time to check that the number of hours in the tooltip message is correct
      }
    }
  }
}

POST .fleet-agents/_update/<agent_id>
{
  "doc": {
    "upgrade_details": {
      "target_version": "8.11",
      "action_id": "xxxxxxxx",
      "state": "UPG_DOWNLOADING",
      "metadata": {
        "download_percent": 16.4
      }
    }
  }
}

POST .fleet-agents/_update/<agent_id>
{
  "doc": {
    "upgrade_details": {
      "target_version": "8.11",
      "action_id": "xxxxxxxx",
      "state": "UPG_FAILED",
      "metadata": {
        "failed_state": "UPG_DOWNLOADING",
        "error_msg": "Something went BOOM"
      }
    }
  }
}

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This renders correctly on smaller devices using a responsive layout. (You can test this in your browser)
• This was checked for cross-browser compatibility

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• /oblt-deploy-serverless : Deploy a serverless Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

This is something I'm not sure of: we want to show this tooltip if the agent is upgrading but doesn't have upgrade details. Is this check a proper way to do this?

[jillguyonnet]

Changed the check to upgrade_started_at:* AND NOT upgraded_at:* (thanks @juliaElastic).
@ycombinator Could you confirm this is correct?

[ycombinator]

This predicate makes sense to me. And I think it's clever to show the tooltip in this scenario (agent is upgrading but we don't have upgrade details) as it encourages users to upgrade to 8.12.

My only feedback would be to somehow not hardcode the 8.12 if possible because we don't know yet when the entire implementation of the upgrade details (including the Agent side of things) will be done. I'm reasonably sure we're on track for 8.12 on the Agent side of things but if, for some odd reason, we don't make that, how can we remember to update this tooltip text? Or perhaps, to be safe, we could pull out just the code for this scenario into a separate PR that we merge at the very end, when we're absolutely sure of the version upgrade details will be available, end-to-end?

[jillguyonnet]

I agree hardcoding the version number is not ideal.

Perhaps a narrow way to be safe could be to define a minVersion variable, currently undefined, and only render the tooltip when its value is set. Then, when the changes are ready on Agent side, we would have to remember to open a PR to set the value to 8.12 or another.

@juliaElastic WDYT?

[juliaElastic]

Sounds good, we could create a small gh issue and put in this sprint so we don't forget to set the variable.

[jillguyonnet]

@ycombinator I've pushed this change and the other one (no download percent indication in the tooltip if 0) and opened a WIP followup PR to set the version: #168638 that could be merged after the Agent changes are ready.

Could you confirm whether we're ok to merge this PR and add a task to elastic/elastic-agent#3119 to ping Fleet team to merge #168638 when you are ready on your end?

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

Is download_percent going to be always populated? If not, maybe we should set 0 if not set.

[jillguyonnet]

It should exist and be populated if the state is UPG_DOWNLOADING, otherwise I don't think it's set.

[jillguyonnet]

In saying that, I think it's a really good idea to fall back to 0 in case for some reason the agent doesn't have a download percent. Thanks for the suggesting, will add!

[ycombinator]

May I suggest that if the download_percent field is not set OR if it's set to 0, we don't include it in the message? In other words, would it be possible to start including the download percent value in the message only when download_percent > 0? Otherwise we could end up showing a download percent of 0 to the user for the entire time we're in the UPG_DOWNLOADING state and then suddenly move to the next state, which might be a bit confusing.

[juliaElastic]

nit: the tooltip text could be verified for cases where there is a text with variables

[juliaElastic]

Looks great, some minor comments, otherwise 🚀

[criamico]

Adding this comment based on our offline discussion.
This mappings file is there for the only purpose of helping in the KQL validation. It's not adding any new field to the agent index mappings as those live in Elasticsearch repo. I think you'll need to open a separate PR there.

Also, this makes me think that the comment I had on this file is not super clear, so I'll open a small PR to better clarify what's the purpose of this file.

However this is a nice addition because it will enable the KQL searchbox to search on the newly defined fields.

[criamico]

I just checked the existing mappings and noticed that they were added already in this PR elastic/elasticsearch#98680. So you should be good there :)

[jillguyonnet]

Thank you for checking this @criamico! 👍

[criamico]

LGTM 🚢

[jillguyonnet]

@juliaElastic @criamico @zombieFox
The following changes have been pushed (updated screenshots in description):

• Improved tooltip message for scheduled state: the tooltip now reads "less than 15 minute/30 minutes/1 hour/2 hours..." (there are a comment and a unit test for the function).
• "Upgrade available" is no longer a warning icon and a text, but a white badge (no tooltip).
• Unit tests for tooltip messages.

Thanks all for your feedback! I have one remaining question: FF 8.11.0 was on Oct 3 - should I keep 8.11.0 as the version for this PR (that includes the label text for when the agent has no upgrade details) or should it be changed?

[kpollich]

FF 8.11.0 was on Oct 3 - should I keep 8.11.0 as the version for this PR (that includes the label text for when the agent has no upgrade details) or should it be changed?

I don't think this needs to land in 8.11.0 especially since we're still waiting on agent's implementation for this to really be "active" correct? Perhaps we should change this to target 8.12?

[jillguyonnet]

Thanks @kpollich - looking at elastic/elastic-agent#3119 this does seem to make sense.

Changing to 8.12.0 unless there are any objections.

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

@elasticmachine merge upstream

[jillguyonnet]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: d316025

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
fleet	940	941	+1

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
fleet	1084	1085	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
fleet	1.2MB	1.2MB	+4.8KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
fleet	42	43	+1

Unknown metric groups

API count

id	before	after	diff
fleet	1202	1203	+1

History

• 💔 Build #167050 failed 02ad0e7
• 💚 Build #166205 succeeded 8fa8b8d
• 💔 Build #165661 failed 24997fc
• 💛 Build #165330 was flaky ca8b9cb
• 💔 Build #164899 failed 2cb1843

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @jillguyonnet

[kpollich]

Merging as this is green + approved and Jill is on PTO 🙂