Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion. Example: registry to NP #37310

Closed
wants to merge 1 commit into from
Closed

Discussion. Example: registry to NP #37310

wants to merge 1 commit into from

Conversation

streamich
Copy link
Contributor

@streamich streamich commented May 29, 2019

Proposal: start using NP as soon as possible, move every single line we can to NP.

This example moves interpreter function registry into NP plugin. NP allows for a plugin with the same name, in this case interpreter, to exist as a legacy plugin as well as an NP plugin.

Following this pattern we can move everything line-by-line to the NP. This example moves just one of many registries.

We could proceed by:

  1. Moving more registries to NP.
  2. Moving uses of registries to NP.
  3. In general, moving everything that has no Angular (like Embeddables API).

Benefits of moving every single line of code we can to NP as soon as possible:

  • We know that already migrated code actually works in NP.
  • Migration is a continuous process. Instead if we move a whole plugin or a collection of plugins at once there can (and probably will) be surprises.
  • We know the NP functionality that migrated code uses works.
  • We can track our progress very precisely by LOC in src/plugins vs src/legacy folders.

Our migration metric could be LOC in src/plugins folder vs LOC in src/legacy folder.

find src/plugins -name '*.*' | xargs wc -l
     145 total

find src/legacy -name '*.*' | xargs wc -l
     104589 total

Currently we have 145 LOC in plugins and 104,589 LOC in legacy. So our migration progress is 0.14%.

@@ -74,7 +74,7 @@ export async function __newPlatformStart__(
}

export function getNewPlatform() {
if (runtimeContext.setup.core === null || runtimeContext.start.core === null) {
if (runtimeContext.setup.core === null /* || runtimeContext.start.core === null */) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding was that platform loading follows

NP setup -> NP start -> legacy platform

but for some reason when legacy runs runtimeContext.start.core is still null.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need to be resolved before merging?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to merge this PR, I should have made it as a Draft. I guess, this is just an example of moving one Interpreter registry, but I am looking into moving way bigger chunk of Interpreter, as it does not have many dependencies.

But in general this runtimeContext.start.core must be addressed somehow. For moving registries we don't need runtimeContext.start.core, but kibana-react will probably need runtimeContext.start.core in legacy world.

@elasticmachine
Copy link
Contributor

💔 Build Failed

@m-adams
Copy link

m-adams commented May 29, 2019

Does anybody know why I'm a reviewer on this??

@streamich
Copy link
Contributor Author

@m-adams sorry I was selecting the other Matt and apparently clicked on you, too.

@streamich streamich requested review from lukeelmers, epixa, joshdover, lizozom and lukasolson and removed request for m-adams May 29, 2019 08:30
@streamich streamich changed the title Example: registry to NP Discussion. Example: registry to NP May 29, 2019
@streamich streamich requested a review from stacey-gammon May 29, 2019 15:34
@lukeelmers
Copy link
Member

lukeelmers commented May 29, 2019

I love this idea and think it'll give us a concrete way to look at progress as we get further down the migration path, while simultaneously starting to test NP services. This basically answers the question of how we will deal with the last step in the migration process.

As long as we keep re-exporting the new platform contracts from the equivalent legacy plugins, then this can all happen behind the scenes without downstream plugins being aware of what's going on. Basically replicating the pattern we've been using in Phase I as we move legacy code into legacy plugins.

Then at the end of migration, we will end up with a bunch of "empty" legacy plugins that are simply re-exporting the new platform plugin contracts, at which point we can kill the legacy plugin and fully cut over to new platform.

With the introduction of this step, that means the new platform migration process for each plugin would look something like this:

Phase I

  • Consolidate legacy code into legacy plugins with new platform-style plugin definition shims & contracts
  • Metric: # of plugins & ui/public directories that have been moved to their new home

Phase II

  • De-Angularize & manage stateful dependencies from the top level of each plugin
  • Metric: # of plugins which have had dependencies updated & Angular removed

Phase III (pattern established by this PR)

  • Gradually move "leaf" node services to the new platform behind the scenes, re-exporting from their corresponding legacy plugins.
  • Metric: LOC moved to the NP plugins directory, as @streamich describes above

[Edit: Just because this step is Phase III doesn't mean it shouldn't start happening now, as long as a plugin has made it through the first two steps]

@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch

Copy link
Contributor

@joshdover joshdover left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a draft, but there are some things to know about the conventions we're adopting.


import { FunctionsRegistry } from './registries';

export const plugin = () => ({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good to know!
And then things can be imported statically from the top level of the plugin.

*/

import { Registry } from '@kbn/interpreter/common';
const { Fn } = require('@kbn/interpreter/common'); // eslint-disable-line
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does this line use require instead of an import statement?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because Fn does not appear in TypeScript .d.ts, I believe, in @kbn/interpreter/common, so it complains.

@streamich streamich requested a review from timroes June 6, 2019 20:13
@streamich streamich mentioned this pull request Jun 14, 2019
@streamich
Copy link
Contributor Author

Half of Interpreter has been moved to the NP, next half is to be followed shortly.

@streamich streamich closed this Jul 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants