[Fleet] Add "Label" column + filter to Agent list table

[kpollich]

Summary

Resolves #130713
Resolves #130717

Finalized implementation blocked by elastic/fleet-server#1350

Adds a baseline implementation for listing tags stored in .fleet-agents documents in the Agent listing UI and filtering based on tags.

Generating Test Data

You'll need to create a user with the system indices superuser role, then you can add some sample tags to your agents via Kibana dev tools, e.g.

# Search for your agents and grab their `_id` values to use below
GET .fleet-agents/_search

POST .fleet-agents/_update/{agent_id}
{
  "doc": {
    # Add whatever tags you want here to test
    "tags": ["fleet-server", "docker", "test"]
  }
}

Screenshots

Example values:

Tooltip when hovering truncated list of tags:

KQL autocompletion support:

Screen recording demonstrating filtering behavior:

Screen.Recording.2022-05-09.at.8.54.44.AM.mov

[kpollich]

@elasticmachine merge upstream

[ph]

@nimarezainia @narph What is the correct naming to use here, I see label in the UI and tags in the Elastic Agent side?

[kpollich]

What is the correct naming to use here, I see label in the UI and tags in the Elastic Agent side?

Figma designs call for Label, but I agree that there is a need for consistency here. Especially if this data is eventually exposed via Fleet's APIs.

[kpollich]

I did some setup preparing for filtering by tags in c43d60c. This is blocked by the Fleet Server work though, since we can't filter on tags until the field is defined in the .fleet-agents index's mappings.

I've also elected to rename Labels to Tags in the UI for consistency, based on @ph 's comment above.

[narph]

@nimarezainia @narph What is the correct naming to use here, I see label in the UI and tags in the Elastic Agent side?

I think we should keep some consistency on both sides , as decided in elastic/elastic-agent#149 (comment) which is tags.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

looks great! some unit tests would be nice.
have you tested that the filtering works well with pagination?

[kpollich]

looks great! some unit tests would be nice. have you tested that the filtering works well with pagination?

Adding UI tests for the entire table seems like it might be a difficult undertaking to include along with this PR, but I did add some basic tests for the <Tags /> component to assert on the truncation/tooltip logic.

Here's the filtering working with pagination:

Screen.Recording.2022-05-09.at.10.03.42.AM.mov

[nchaulet]

Tested locally and it looks good to me 🚀

[juliaElastic]

🚀

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 8b39f69
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
fleet	619	620	+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	702.4KB	704.1KB	+1.7KB

Unknown metric groups

API count

id	before	after	diff
fleet	1393	1394	+1

History

• 💛 Build #41166 was flaky c43d60c
• 💚 Build #40947 succeeded f9745fc
• 💚 Build #40902 succeeded d26a6fc

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

cc @kpollich