Add feature flag for Observability entity-centric service views

[smith]

(while this may look very similar to #182678, it is a follow-up to that issue)

We want to enable entity-centric service views only for Elastic internal users in Serverless.

In #182862 we added an advanced setting called observability:apmEnableMultiSignal. Instead of using the advanced setting, we will use the Observability entity-centric service views (observability.entity-centric-service-views) feature flag in LaunchDarkly.

We'll enable the Cloud Experiments service in APM and set up the new flag in the FEATURE_FLAGS_NAMES enum.

✅ Acceptance criteria

• The Observability entity-centric service views (observability.entity-centric-service-views) feature flag exists in LaunchDarkly in all environments.
• The observability.entity-centric-service-views feature flag is added to kibana
• The changes in [APM][Multi-signal service inventory] Introduce a feature flag to enable/disable the multi-signal inventory #182678 are reverted.
• In local, Staging, and Production environments users do not see the new service views.
• In QA, Elastic employees do see the new view.
• In local environments, when xpack.cloud_integrations.experiments.enabled: true; xpack.cloud_integrations.experiments.flag_overrides: { "observability.entity-centric-service-views": true } is set in kibana.dev.yml, the new view is enabled.

[elasticmachine]

Pinging @elastic/obs-ux-infra_services-team (Team:obs-ux-infra_services)

[andrewvc]

I'd love to use launch darkly, let's hang for a minute before merging, I want to check with @sophiec20 that we're OK to proceed here.

[kpatticha]

Should we consider moving it back to refining, or mark it as blocked until we receive confirmation that it's okay to proceed?

[smith]

I've marked it as blocked. Platform is proceeding with a plan and I'll keep us updated here.

[afharo]

• In local, Staging, and Production environments users do not see the new service views.
• In QA, Elastic employees do see the new view.

👆 If I'm reading correctly, the requirement is we want this feature enabled only on QA.

If that's correct, have you considered that our MKI tests run against QA? Also, our Quality Gates may pass on QA as Kibana's behavior is different and there may be a hidden uncaught production bug.

Would it be enough to enable it via project overrides for specific manual tests? 😇

[smith]

👆 If I'm reading correctly, the requirement is we want this feature enabled only on QA.

@afharo. No. That's just a starting point. We require the capability to flexibly target customer segments in all environments.

[afharo]

@smith, gotcha! Thanks for confirming!

[roshan-elastic]

Hey @smith - just making sure I understand what this will provide and how it will work. Could you check my understanding below?

What do we have now?

• Ability to add a feature flag in our 'settings' which users can use to turn on/off something in Kibana...we're using this to turn on/off the views

What will this do?

• We can now control exactly which users will see the signal-agnostic UI
• We'll set this to 'on' for all internal users in serverless (QA only)

Note : We'll revert the feature flag settings to enable/disable the signal-agnostic UI and this will supersede it

Questions
If I understand correctly, I have a few questions:

• Will this affect stateful too? If so, when would changes take affect (presumably it'll still be per usual release cycle)?
• Will there be a feature flag anywhere for users to turn the signal-agnostic UI on/off?
• Should we think about how the browser-specific enablement solution (localStorage) might work with this (or shall we wait until we've done the first milestone to consider this)?

[smith]

Will this affect stateful too? If so, when would changes take affect (presumably it'll still be per usual release cycle)?

The Cloud Experiments plugin currently is only enabled in cloud environments, so self-managed users would get shown whatever the code has as the default in that release. Cloud ESS works the same as Serverless, but the user needs to update to the latest release.

Will there be a feature flag anywhere for users to turn the signal-agnostic UI on/off?

No. Users don't control feature flags. We can use the feature flags to control which features are enabled.

Should we think about how the browser-specific enablement solution (localStorage) might work with this (or shall we wait until we've done the first milestone to consider this)?

We're currently not able to use Cloud Experiments so we should consider this functionality out of scope for the current milestones.