[META] Logs, Metrics, and Stack Monitoring 8.0 Plan

[jasonrhodes]

Summary

The upcoming major version release 8.0.0 requires us to decide if there are places where it would provide the best user experience to implement breaking changes. This list tracks the changes and associated deprecations required for the Logs, Metrics, and Stack Monitoring UIs.

Planned for 7.16

• [Logs UI] [Metrics UI] Register deprecations for field configurations #113166
• Monitoring deprecation needs a title #113191

Planned for 8.0

• Need ticket? We have to sort the mappings installations for .monitoring so that Standalone Metricbeat works in 8.0
• [Stack Monitoring] Adapt UI to processes metrics from kibana 8.0 #113149
• [Stack Monitoring] Make sure SM queries can handle both process and processes metrics across 7.x and 8.x indices #117614
• [Stack Monitoring] Adapt to removal of memory information from ES segments #106345
• [Metrics UI] Remove fields configuration from source configuration #113165
• [Logs UI] Remove fields configuration from source configuration #113163
• [Logs UI] Only support Kibana Index Patterns (aka Data Views) in Logs Source Configuration #113168
• [Metrics UI] Remove the usage of configurable fields from data fetching code #115257
• [Metrics UI] Remove the configurable fields from the metrics source configuration API #115259
• [Logs UI] Remove the timestamp and tiebreaker fields from log source configuration APIs #115254
• [Logs UI] [Metrics UI] Remove fields key from source configuration saved objects #115252
• [Logs UI] Replace mentions of KIPs with data views #100852

Not going to address

• Decide if we want to introduce ui.enabled -- Decision: not going to move forward with this for now, we can introduce these later if we want them but they need to be aligned with other groups and would be harder to remove than to introduce later.
• [Logs UI] [Metrics UI] Split "infra" into "logs" and "metrics" #113159
• [Logs UI] [Metrics UI] [Stack Monitoring UI] Remove legacy "#" URL support #113167

[elasticmachine]

Pinging @elastic/stack-monitoring (Team:Monitoring)

[matschaffer]

Looks like @cjcenizal just opened #113191 as an 8.0 requirement. Wondering if we should have a "bugs" heading under "definites"

[cjcenizal]

@matschaffer Thanks for re-broadcasting! At the risk of stating the obvious, I also want to mention that I've been mentally thinking of "8.0 requirements" as "7.16 requirements" since the 8.0 upgrade UX ships with 7.16. That's where users get notified of all the breaking changes and figure out how to address them before upgrading to 8.

[jasonrhodes]

I also want to mention that I've been mentally thinking of "8.0 requirements" as "7.16 requirements" since the 8.0 upgrade UX ships with 7.16. That's where users get notified of all the breaking changes and figure out how to address them before upgrading to 8.

@cjcenizal hmm, but if we are removing functionality, we can't do it until the 8.0.0 change, right? So the actual code that is breaking needs to go in for 8.0 and not for 7.16, right?

[cjcenizal]

@jasonrhodes Right. In 7.16 we need to warn users about 8.0 breaking changes and offer guidance on how to deal with them, and in 8.0 we need to implement the breaking changes themselves.

[smith]

Closing this since 8.0.0 is out.