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

Migrate logstash frontend to KP #63417

Merged
merged 8 commits into from
Apr 21, 2020

Conversation

joshdover
Copy link
Contributor

@joshdover joshdover commented Apr 13, 2020

Summary

Closes #60937

This completed the logstash plugin migration to the Kibana Platform:

  • Removes all Angular code
  • Uses KP dependencies in place of legacy ones
  • Moves UI code to KP plugin
  • Deletes legacy logstash plugin

TODO:

  • Cleanup react router code
    • Fix clone and retry query params
  • Fix breadcrumbs
  • Fix monitoring integration
  • Fix licensing error messages
  • Test license scenarios
  • Move to proper KP plugin
  • Confirm monitoring integration works

Checklist

Delete any items that are not applicable to this PR.

For maintainers

@joshdover joshdover force-pushed the logstash/migrate-ui-services branch from cabc774 to ca6c71a Compare April 14, 2020 22:34
Comment on lines 42 to 43
// When monitoring is migrated this should be fetched from monitoring's plugin contract
core.injectedMetadata.getInjectedVar('monitoringUiEnabled'),
Copy link
Contributor Author

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.

@joshdover joshdover added Feature:Logstash Pipelines Logstash Pipeline UI related Feature:NP Migration Team:Logstash Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.8.0 labels Apr 15, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)

@joshdover joshdover marked this pull request as ready for review April 15, 2020 13:56
@joshdover joshdover added the release_note:skip Skip the PR/issue when compiling release notes label Apr 15, 2020
Copy link
Contributor

@mshustov mshustov left a 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

x-pack/plugins/logstash/public/plugin.ts Outdated Show resolved Hide resolved
order: 10,
mount: async params => {
const [coreStart] = await core.getStartServices();
const { renderApp } = await import('./sections');
Copy link
Contributor

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.

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 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.

Copy link
Contributor

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.

x-pack/plugins/logstash/public/plugin.ts Outdated Show resolved Hide resolved
x-pack/plugins/logstash/public/plugin.ts Outdated Show resolved Hide resolved
@@ -32,16 +30,16 @@ export class MonitoringService {
.then(cluster => {
const url = `${this.basePath}/v1/clusters/${cluster.uuid}/logstash/pipeline_ids`;
Copy link
Contributor

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

Copy link
Contributor Author

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/sections/index.tsx Outdated Show resolved Hide resolved
Copy link
Contributor

@ycombinator ycombinator left a 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!

@joshdover joshdover requested a review from a team as a code owner April 19, 2020 19:41
@joshdover joshdover requested a review from mshustov April 19, 2020 19:41
@joshdover
Copy link
Contributor Author

Base path issue fixed!

@joshdover joshdover dismissed mshustov’s stale review April 19, 2020 19:41

base path problem fixed

Copy link
Contributor

@pgayvallet pgayvallet left a 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

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.

Comment on lines +108 to +116
const close = useCallback(() => {
history.push('/');
}, [history]);
const open = useCallback(
(newId: string) => {
history.push(`/pipeline/${newId}/edit`);
},
[history]
);
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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;
Copy link
Contributor

Choose a reason for hiding this comment

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

NIT: ` -> '

Copy link
Contributor Author

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) => {
Copy link
Contributor

@mshustov mshustov Apr 20, 2020

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. 😄

Copy link
Contributor Author

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.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

Copy link
Contributor

@mattkime mattkime left a 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

Comment on lines +108 to +116
const close = useCallback(() => {
history.push('/');
}, [history]);
const open = useCallback(
(newId: string) => {
history.push(`/pipeline/${newId}/edit`);
},
[history]
);
Copy link
Contributor

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 :)

@joshdover joshdover merged commit f43d555 into elastic:master Apr 21, 2020
@joshdover joshdover deleted the logstash/migrate-ui-services branch April 21, 2020 13:40
joshdover added a commit to joshdover/kibana that referenced this pull request Apr 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Logstash Pipelines Logstash Pipeline UI related Feature:NP Migration release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Logstash v7.8.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate Logstash plugin
7 participants