[UA] ES deprecation logs in its own page

[sebelga]

The deprecation logs coming from ES have some UX flaws. Many of the deprecation logs (some noted as “Critical”) that we expose in Observability are coming from Kibana itself and the user can’t act on them. There isn’t really anything that they can do to solve those deprecations. Those logs create noise and could be a barrier to the upgrade process.

We want to reduce the visibility of the “use of deprecated API” section in Upgrade assistant (step 4 of the wizard) as we can’t confidently rely on them to help the user fix possible use of deprecated ES APIs.

In this PR we have removed the ES deprecation logs UI from the UA overview and moved it to its own page.

TODO

• Cleanup current wizard and remove step 4 ([Upgrade Assistant] Move fix deprecation logs into the es_deprecation_logs page #118688)
• Embed into new page (Add new page for the deprecation logs #118722)
• Fix tests ([Upgrade Assistant] Fix cits, a11y and functional tests #118778)

Screenshots

[debadair]

Left a few suggestions.

[cjcenizal]

👍 👍 👍 I haven't looked at the code, only tested locally. This UX feels so much better to me! The logs are accessible but not presented as blockers. Great work @sebelga and @sabarasaba. Let's wait a bit to ensure stakeholders are onboard with this change before merging.

[cjcenizal]

@sebelga @sabarasaba We have approval to move forward with this change, so feel free to merge when ready.

[elasticmachine]

Pinging @elastic/kibana-stack-management (Team:Stack Management)

[sabarasaba]

code changes lgtm, tested locally 🚀

[sebelga]

Thanks for the review @sabarasaba ! Let's wait for @debadair input and then we'll merge it 👍

[debadair]

Updated the suggestion, but LGTM either way.

[sebelga]

Thanks for the review @debadair ! 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3808d0e
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
upgradeAssistant	143	145	+2

Async chunks

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

id	before	after	diff
upgradeAssistant	137.1KB	138.7KB	+1.5KB

Page load bundle

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

id	before	after	diff
core	308.2KB	308.2KB	+61.0B
upgradeAssistant	18.0KB	18.3KB	+311.0B
total			+372.0B

History

• 💔 Build #7766 failed fb171d4
• 💚 Build #7586 succeeded 6b40383
• 💚 Build #7411 succeeded 1121331
• 💔 Build #7314 failed cbce38b
• 💔 Build #7112 failed 384f5f2
• 💚 Build #7027 succeeded ff79e19

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

[cjcenizal]

@sebelga I think we'll need to backport this to the 8.0 branch too.

[sebelga]

I think we'll need to backport this to the 8.0 branch too.

Do we need to backport if UA is not enabled in 8.0?

[cjcenizal]

@sebelga The only reason I can imagine we will need it is if there’s a security flaw in a common dependency that will require making changes throughout all plugins. In a situation like that, a backport would be painful if plugins are inconsistent between branches. The chance of that seems low so we could probably get away with not backporting it. OTOH the effort of a backport seems low. Do you see a downside to backporting?

[sebelga]

#119134 was not a straightforward process so I was wondering why we'd need to backport on a branch where we'll only apply security patches or bug fixes. Security patches seem to be more likely to be done server side so would not affect the changes here on UA. The rest are tests and doc links.

[cjcenizal]

Ah, thanks for explaining Seb! I didn't know that you encountered a large number of merge conflicts when you forwardported the change to main. I'll leave it to you to decide what's right. At this point I'm more curious about the cause of those merge conflicts. My guess is we missed some forwardports while #114966 was in flight. For example, it looks like #112907 didn't get forwardported.

[sebelga]

With that said I did create the backport as indeed it is little effort and aligned branches are a very good thing to do for our future selves. 😊 (#119345)

The conflicts with the previous backport came mainly because of translation being updated for the 7.16 release. And I think translation go main > 7.16 while we go 7.16 > main. So a change of translation key while working on 7.16 creates conflicts.