-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Index management] Server-side NP ready #56829
Conversation
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
There was a problem hiding this 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:
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( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Thanks for the review @jloleysens !
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 will look if I changed something in the response. Do you remember what you changed to get that error? |
Per the picture, I just added |
This is usually a good way to start breaking things 😄 |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* 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) ...
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
How to test
.kibana-1
index! 😄 )And for follower indices a badge should appear in the table
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 thisAs 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
.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