-
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
Migrate logstash frontend to KP #63417
Migrate logstash frontend to KP #63417
Conversation
cabc774
to
ca6c71a
Compare
x-pack/plugins/logstash/public/services/license/logstash_license_service.js
Outdated
Show resolved
Hide resolved
...ck/legacy/plugins/logstash/public/lib/update_management_sections/update_logstash_sections.js
Show resolved
Hide resolved
// When monitoring is migrated this should be fetched from monitoring's plugin contract | ||
core.injectedMetadata.getInjectedVar('monitoringUiEnabled'), |
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.
Not sure how to make sure this doesn't get missed when #62908 is merged. I will coordinate with @igoristic to make sure this doesn't break.
Pinging @elastic/kibana-platform (Team:Platform) |
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.
Create pipeline
functionality is broken at the moment due to double basePath in the url. FTR does not define basePath
, so CI is wrongly green
order: 10, | ||
mount: async params => { | ||
const [coreStart] = await core.getStartServices(); | ||
const { renderApp } = await import('./sections'); |
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.
Should we unify the pattern of the mounter declaration? Place in a folder structure, name, etc? Not a blocker for the current work.
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.
We actually do have a folder convention for 1st class applications, though I wasn't sure if it should apply to management sections. It looks like other plugins are using this convention for sections as well, so I'll move everything to that for now.
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.
They do. However, we might want to separate the application
& management section
folders. Also, we could introduce a convention to place mounter functions in the *_mounter
file to unify the declarations.
@@ -32,16 +30,16 @@ export class MonitoringService { | |||
.then(cluster => { | |||
const url = `${this.basePath}/v1/clusters/${cluster.uuid}/logstash/pipeline_ids`; |
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.
this also should move to monitoring service maybe? it's not good that logstash calls monitoring plugin endpoint
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.
Opened an issue: #63931. Will be easier to fix after monitoring plugin has migrated.
x-pack/plugins/logstash/public/models/pipeline_list_item/pipeline_list_item.js
Outdated
Show resolved
Hide resolved
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.
Smoke tested this PR. Functionally LGTM. Thanks, @joshdover!
Base path issue fixed! |
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.
Some very minor nits. Feel free to ignore them if outside of the scope of the migration.
Seems like the jest test
failure is caused because
kibana/src/plugins/management/public/management_service.test.ts
Lines 32 to 35 in d6a500c
expect(service.getAllSections().length).toEqual(3); | |
expect(service.getSection('kibana')).not.toBeUndefined(); | |
expect(service.getSection('logstash')).not.toBeUndefined(); | |
expect(service.getSection('elasticsearch')).not.toBeUndefined(); |
needs to be adapted as the logstash
section is no longer registered from legacy.
x-pack/plugins/logstash/public/application/pipeline_edit_view.tsx
Outdated
Show resolved
Hide resolved
const close = useCallback(() => { | ||
history.push('/'); | ||
}, [history]); | ||
const open = useCallback( | ||
(newId: string) => { | ||
history.push(`/pipeline/${newId}/edit`); | ||
}, | ||
[history] | ||
); |
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.
NIT: useCallback
make sense for onRetry
(even if debatable), but it seems unnecessary here.
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.
Correct me if I'm wrong (I'm still new to hooks), but I thought the purpose of useCallback was to avoid creating a new function on each render, possibly triggering unnecessary re-renders of the child components. I'm basically just using this for memoization.
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.
Yea you are right. Sorry, I thought history
was also passed down to the child component (which would have made the useCallback usage useless) but it is not. All good :)
} | ||
|
||
get isSecurityEnabled() { | ||
return this.license.getFeature(`security`).isEnabled; |
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.
NIT: ` -> '
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.
Can't use arrow functions on get
properties (if that's what you meant).
* Rejects if the plugin is not available due to license. | ||
*/ | ||
checkValidity() { | ||
return new Promise((resolve, reject) => { |
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's one of the weirdest ways to check a boolean value I've ever seen. 😄
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.
Yeah maybe I'm err'ing too much on the side of "don't changing anything in this plugin that we don't have to"... Just worried about lack of unit test coverage.
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
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.
App Arch changes lgtm
const close = useCallback(() => { | ||
history.push('/'); | ||
}, [history]); | ||
const open = useCallback( | ||
(newId: string) => { | ||
history.push(`/pipeline/${newId}/edit`); | ||
}, | ||
[history] | ||
); |
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.
Yea you are right. Sorry, I thought history
was also passed down to the child component (which would have made the useCallback usage useless) but it is not. All good :)
Summary
Closes #60937
This completed the logstash plugin migration to the Kibana Platform:
TODO:
clone
andretry
query paramsChecklist
Delete any items that are not applicable to this PR.
For maintainers