[Reporting] New Platform Migration

[tsullivan]

Describe the feature:
The Kibana Reporting plugin code needs to be migrated to the New Platform interface.

The Reporting plugin definition in NP will share a contract with other plugins that will allow them to pass a Kibana URL and some options to a function and receive an observable that resolves to a PNG payload of the screenshot. This was already possible in the legacy Reporting code, but the interface to the screenshot observable is cumbersome and undocumented.

Tasks:

• Define serverFacade and requestFacade objects that use bare-bones types of the legacy dependencies

  • @tsullivan PR: [Reporting] Define shims of legacy dependencies #54082

• Create the server/plugin.ts file to declare the plugin definition, which shims Reporting

  • Ultimately this allows us to expose a contract that lets other plugins consume a URL-to-screenshot observable.
  • @tsullivan PR: [Reporting/Migration] ReportingSetup, LegacySetup #54198

• Consume New Platform dependencies and pass them to the server shim

  • Logging
    • @tsullivan PR: [Reporting/New Platform] Use the logger service from core #55442
  • Security
    • @tsullivan PR: [Reporting/NP] Migration of Reporting Security dependency #56046
  • FieldFormats
    • @alexwizp PR: Expose NP FieldFormats service to server side #55419
  • Elasticsearch
    • @tsullivan PR: [Reporting] Use ES plugin from NP #56209
  • Config
    • @tsullivan PR: [Reporting] Use a shim for server config #62086 [Reporting] Switch Serverside Config Wrapper to NP #62500
  • UI Setting Client and Saved Objects
    • @tsullivan PR: [Reporting/New Platform] Provide async access to server-side dependencies #56824
  • Server Routes & Licensing
    • @joelgriffith [Reporting]: Move router + license checks to new platform #66331
  • Usage Collector
    • @tsullivan [Reporting] Migrate server-side usage collector #67233

• Migrate the UI to the New Platform

  • @joelgriffith PR 1: [Reporting] New Platform: moves most of our libs/constants and utils to np shims #55935
  • @joelgriffith PR 2: [Reporting] Wholesale moves client to newest-platform #58945

Concerns:

• server.fieldFormatServiceFactory is unavailable in Types
  • relevant code: https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/reporting/export_types/csv/server/execute_job.ts#L90
• We use config.set on the server side in some places to update to a configuration that will work with Reporting. We always log a warning and explain how to update the configuration and silence the warning. Will this be possible in the New Platform?
• BLOCKING: Management plugins need to be registered with a migrated Management App; Management App is not migrated yet
• Should we detect ES connection health to influence how we poll for pending jobs? [Reporting] Background poller runs regardless of ES health #18297 (blocked by Migrate status service and status page to New Platform #41983)
• Need access to Kibana config settings: server.port, server.host, etc. Issue: [New Platform] APIs needed for opening a connection to the Kibana server #56231

[elasticmachine]

Pinging @elastic/kibana-reporting-services (Team:Reporting Services)

[rudolf]

Should we detect ES connection health to influence how we poll for pending jobs? #18297

NP will expose status for it's sub-services like elasticsearch in a similar way to what Legacy did (using an observable instead of a event emitter) we're tracking the work here #41983 I've updated the issue description with this as a blocker.

[rudolf]

Test that spawns a Hapi server needs to be re-written

We've created #51150 for making it easier to test controllers by mocking their dependencies like what you're doing in these tests.

[tsullivan]

• It's unclear if we can preserve the routing middleware [Reporting] Define shims of legacy dependencies #54082 (comment)

We don't need middleware to do what we're currently doing with middleware. We can just as easily make a route handler wrapper that runs the auth checks needed for the custom Reporting authentication model. Resolved in #54082 (comment)

[tsullivan]

We use config.set on the server side in some places to update to a configuration that will work with Reporting. We always log a warning and explain how to update the configuration and silence the warning. Will this be possible in the New Platform?

We'll handle this by refactoring Reporting's usage of config. A createConfig$ function will invoke dynamic changes to the set configuration before it touches the application

[tsullivan]

New Platform license checking service provides an observable. Do all the parts of the Reporting code that depend on license status need to subscribe to that observable? It is unclear how this works in the legacy Reporting code

It looks like a few plugins in are now implementing license checks in the New Platform. I think we'll be able to find a solution based on example.

[tsullivan]

(updated description)

[mshustov]

Could you switch to elasticsearch client & licensing plugin API exposed from start contract when migrating the shim to the Kibana Platform? We are deprecating elasticsearch API exposed from setup contract. We are depreciating async lifecycles as well. It means runValidations should be moved to the setup and transformed into unblocking operations.