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

[Index management] Server-side NP ready #56829

Merged
merged 32 commits into from
Feb 11, 2020

Conversation

sebelga
Copy link
Contributor

@sebelga sebelga commented Feb 5, 2020

This is the first PR of 3 to migrate Index management to the new platform to make it easier to test and review.

This PR migrates the server-side code and update all the API routes to

  • Use the new platform router (with schema validation)
  • Use the "licensing" new platform plugin to guard our API route with license check

How to test

  • Navigate through the app and make sure that all requests are fulfilled correctly.
  • Open the flyout details and make sure all tabs display the correct data
  • Test all index drop-down actions from the list of indices (not on .kibana-1 index! 😄 )
  • Create / edit / delete an index template
  • Make sure the extension points from ILM, Rollup and CCR are correctly added. You can see it on the request reponse, each index should have the metadata added

Screen Shot 2020-02-05 at 14 42 41

And for follower indices a badge should appear in the table

Screen Shot 2020-02-05 at 14 42 05

Code structure proposal

I am making the proposal to put the logic inside the plugin setup() phase inside dedicated services. The end result should be something like this

Screen Shot 2020-02-05 at 14 47 23

As you can see both the route registering and the license are encapsulated inside their own classes. Which I think is cleaner than what we currently have with watcher.

Screen Shot 2020-02-05 at 14 48 50

Once the whole migration of Index management is done (moved to the "plugins" folder), I think it would be good to move the License.ts service out to our "es-ui-shared" folder and make it available to all our apps (through the np dependencies mechanism).

cc @cjcenizal @jloleysens @alisonelizabeth

@sebelga sebelga changed the title [Index management] NP migration [Index management] Server-side NP ready Feb 5, 2020
@sebelga sebelga added Feature:Index Management Index and index templates UI Feature:New Platform release_note:skip Skip the PR/issue when compiling release notes labels Feb 5, 2020
@sebelga sebelga added the Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more label Feb 5, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui (Team:Elasticsearch UI)

@sebelga sebelga requested a review from jloleysens February 5, 2020 09:33
@sebelga sebelga marked this pull request as ready for review February 5, 2020 09:34
Copy link
Contributor

@jloleysens jloleysens left a comment

Choose a reason for hiding this comment

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

Code

No major blockers identified here, the plugin looks quite ready for NP!

Left a comment regarding the new pattern you proposed. Perhaps we can move the conversation to a separate issue?

One thing that we can do to be absolutely sure we have weeded out all remaining NP dependencies is place the application inside an np_ready folder which will make ES lint check for illegal import paths too - next time perhaps!

UI/UX

I saw this error appear while editing the JSON settings of an index:

Screenshot 2020-02-06 at 12 11 31

I was just wondering whether more helpful information is not being returned from ES?

setup({ http }: CoreSetup, { licensing }: Dependencies): IndexMgmtSetup {
const router = http.createRouter();

this.license.setup(
Copy link
Contributor

Choose a reason for hiding this comment

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

Overall I like this idea.

It's nice to see how the different plugin phases can be tagged in services so we build on the established plugin pattern.

My question is; what benefits do we get from have instances of the services live on the plugin as opposed to constructing them at setup time and passing them into our other components? Is it mainly for naming or do we see these services often also having start phase concerns?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seemed more logical to me to instantiate them outside, no real benefit. But as you said, this patterns allows us to call .start() and .stop() if needed.

@sebelga
Copy link
Contributor Author

sebelga commented Feb 6, 2020

Thanks for the review @jloleysens !

One thing that we can do to be absolutely sure we have weeded out all remaining NP dependencies is place the application inside an np_ready folder which will make ES lint check for illegal import paths too - next time perhaps!

I had it there, but then decided to put it back at root level so all relative imports are correct (to "common" folder mainly) and ready to by copied as is in the "plugins" folder.
I guess that eslint will complain in the next PR when actually having the plugin inside the "plugins" folder right?

I saw this error appear while editing the JSON settings of an index

I will look if I changed something in the response. Do you remember what you changed to get that error?

@jloleysens
Copy link
Contributor

jloleysens commented Feb 6, 2020

Do you remember what you changed to get that error?

Per the picture, I just added "blah": 1 to the bottom of settings. 😆

@sebelga
Copy link
Contributor Author

sebelga commented Feb 7, 2020

Per the picture, I just added "blah": 1 to the bottom of settings.

This is usually a good way to start breaking things 😄

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

@sebelga sebelga merged commit 7e9d797 into elastic:master Feb 11, 2020
@sebelga sebelga deleted the np-migration/index-management branch February 11, 2020 06:06
gmmorris added a commit to gmmorris/kibana that referenced this pull request Feb 11, 2020
* master: (34 commits)
  [Index management] Server-side NP ready (elastic#56829)
  Webhook action - make user and password secrets optional (elastic#56823)
  [DOCS] Removes reference to IRC (elastic#57245)
  [Monitoring] NP migration: Local angular module (elastic#51823)
  [SIEM] Adds ECS link to help menu (elastic#57104)
  Ensure http interceptors are shares across lifecycle methods (elastic#57150)
  [Remote clusters] Migrate server code out of legacy (elastic#56781)
  fixes render bug in alert list (elastic#57152)
  siem 7.6 updates (elastic#57169)
  Make the update alert API key API work when AAD is out of sync (elastic#56640)
  fix(NA): MaxListenersExceededWarning on getLoggerStream (elastic#57133)
  [Metrics UI] Setup commonly used time ranges in timepicker (elastic#56701)
  [Maps] set filter.meta.key to geoFieldName so query passes filterMatchesIndex when ignoreFilterIfFieldNotInIndex is true (elastic#56692)
  Create plugin mock for event log plugin (elastic#57048)
  fix ts error on master (elastic#57236)
  Don't create API key for disabled alerts when calling create API (elastic#57041)
  Fix enable and disable API to still work when AAD is out of sync (elastic#56634)
  [DOCS] Canvas embed objects (elastic#57156)
  Delete autocomplete namespace (elastic#57187)
  Security - Inject logout url (elastic#57201)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Index Management Index and index templates UI Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more v7.7.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants