[Fleet] Rename ingestManager plugin ID fleet

[nchaulet]

Summary

Last PR on the effort of renaming ingestManager Fleet

Rename ingestManager plugin ID fleet

This change the app path from /app/ingestManager to /app/fleet

I changed the following plugins accordingly:

• endpoint
• index_managment
• observavilty

Also I renamed all the IngestManagerPlugin IngestManagerSetup, ..., to Fleet*

Release note breaking

The ingestManager plugin as been renamed fleet, this mean:

• The app url change from /app/ingestManager to /app/fleet
• Privileges feature_ingestManager.* is not valid anymore and should be replaced by feature_fleet.*

[cjcenizal]

ES UI code LGTM, didn't test locally.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[azasypkin]

question: @legrego IIRC changing feature ID is a breaking change (we changed the PLUGIN_ID) and we shouldn't make it in a minor upgrade, but I'm not sure what is our policy regarding features that belong to plugins that are in a beta?

[legrego]

Heya Fleet team:

tl;dr I think we can rename in this specific case, please take the time to read this entire comment to understand the implications.

IIRC changing feature ID is a breaking change (we changed the PLUGIN_ID) and we shouldn't make it in a minor upgrade

That's exactly right. Changing a feature id will change the associated privilege ids that are registered with Elasticsearch on startup. For example, prior to this change, a user may have been assigned a custom role which grants access to Ingest Manager. The role would look something like this:

{
  "name": "some-custom-role",
  "cluster": [],
  "index": [],
  "run_as": [],
  "applications": [
     {
       "application": "kibana-.kibana",
       "privileges": [
         "feature_ingestManager.all"
       ],
       "resources": [
         "space:default"
       ]
     }
   ]
}

The privilege that gets assigned to the role (feature_ingestManager.all) is derived in part from the feature id. Renaming your feature means that any role which previously granted access to your feature will no longer grant access, because Kibana doesn't have a feature called ingestManager anymore. The role should instead look like:

{
  "name": "some-custom-role",
  "cluster": [],
  "index": [],
  "run_as": [],
  "applications": [
     {
       "application": "kibana-.kibana",
       "privileges": [
         "feature_fleet.all"
       ],
       "resources": [
         "space:default"
       ]
     }
   ]
}

The problem is that Kibana can't just go and rewrite all of these role definitions. We don't have any sort of migration system in place yet (#68814)

I'm not sure what is our policy regarding features that belong to plugins that are in a beta?

This might be our saving grace. I think we can allow the rename in this specific case, but only because this is a beta feature, and we explicitly tell users not to run this in production yet.

However, this is something that you need to document in the release notes. We have to at least give administrators a fighting chance of restoring access to their users, and not surprise them.

[nchaulet]

I will add a release note 👍 ,
I do not think is so problematic here as an user is not able to use the Fleet plugin if he do not have the superuser role

[cjcenizal]

Sounds like y'all got all of the angles covered here, but I just wanted to mention that from various sources it looks like people are very positive about Fleet and Elastic Agent, and that Beta testers go out on a limb to try things out and give us early feedback. So as a general rule, I think it's important to have empathy for them and avoid introducing breaking changes that will essentially surprise and punish people who are trying to help us, if at all possible.

[nchaulet]

I added the release note

[skh]

I tested this locally and didn't manage to break it. 👍

[sorenlouv]

apm changes lgtm

[paul-tavares]

Looks good Nicolas. Thanks for the changes to the Security Solution code 👍

[paul-tavares]

Nice.
So this still show a left-nav (kibana) nav item, correct?
should there be a flag (in settings) to possibly remove it? (I'm thinking of non-existing fleet users that may download/install >= 7.11)

[nchaulet]

the navlink is hidden with

navLinkStatus: AppNavLinkStatus.hidden,

[nchaulet]

@elastic/siem I would love to have a review here :)

[stephmilovic]

LGTM on SIEM changes, thank you!

[nchaulet]

@elasticmachine merge upstream

[nchaulet]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 55bb17c

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
fleet	-	418	+418
ingestManager	418	-	-418
total			-0

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.1MB	⚠️ +1.1MB
indexManagement	1.5MB	1.5MB	-65.0B
ingestManager	1.1MB	-	-1.1MB
observability	160.8KB	160.7KB	-74.0B
securitySolution	7.9MB	7.9MB	-224.0B
total			-498.0B

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
fleet	-	373.0KB	⚠️ +373.0KB
indexManagement	114.1KB	114.1KB	-24.0B
ingestManager	372.4KB	-	-372.4KB
securitySolution	167.8KB	167.7KB	-32.0B
total			+636.0B

Unknown metric groups

async chunk count

id	before	after	diff
fleet	-	5	+5
ingestManager	5	-	-5
total			-0

History

• 💔 Build #88671 failed 9629109
• 💔 Build #88589 failed 6bc3af6
• 💚 Build #88541 succeeded 1d48d72
• 💚 Build #88400 succeeded cacc2df
• 💚 Build #87987 succeeded dcdc806

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