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

[NP migration] Shim ILM #56068

Merged
merged 18 commits into from
Feb 5, 2020
Merged

Conversation

cjcenizal
Copy link
Contributor

@cjcenizal cjcenizal commented Jan 27, 2020

Test plan

  • API calls
    • loadNodes
    • loadNodeDetails
    • loadIndexTemplates
    • loadPolicies
    • savePolicy
    • deletePolicy
    • addLifecyclePolicyToTemplate
  • Redirects
    • "Cancel" button on Edit/Create policy page goes back to list
  • UI metrics
    • UIM_APP_LOAD
    • UIM_POLICY_CREATE
    • UIM_POLICY_UPDATE
    • UIM_POLICY_DELETE
    • UIM_POLICY_ATTACH_INDEX_TEMPLATE
    • UIM_CONFIG_COLD_PHASE
    • UIM_CONFIG_WARM_PHASE
    • UIM_CONFIG_SET_PRIORITY
    • UIM_CONFIG_FREEZE_INDEX
    • UIM_EDIT_CLICK
  • Toasts and Fatal errors
  • "Learn more" links in editor
  • extend_index_management
    • retryLifecycleForIndex API call
    • removeLifecycleForIndex API call
    • addLifecyclePolicyToIndex API call
    • UIM_POLICY_ATTACH_INDEX UI metric
    • UIM_POLICY_DETACH_INDEX UI metric
    • UIM_INDEX_RETRY_STEP UI metric
  • Disabling UI with xpack.ilm.ui.enabled: false

Testing the Index Management extensions

  1. Create an index lifecycle policy with a Hot Phase that has enabled rollover and max age of a few nanoseconds.
  2. Create an index in Console and add the policy to it in Index Management. You should get a modal and then once you've confirmed, a toast.
  3. View the index's details to see
  4. Add a document to the index and wait a few seconds
  5. Refresh Index Management and you should see a warning callout about errors in the policy
  6. Retry the index lifecycle step for the index
  7. Remove the index lifecycle policy from the index. You should get a modal and then once you've confirmed, a toast.

Verification that dependencies still function

Toasts

image

Fatal error

image

Fetching index templates

image

Fetching nodes

image

Fetching node details

image

Index Management extension

image

@cjcenizal cjcenizal added chore Feature:ILM v8.0.0 Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more release_note:skip Skip the PR/issue when compiling release notes v7.7.0 labels Jan 27, 2020
@elasticmachine
Copy link
Contributor

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

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.

Good first step! Just a couple suggestions / tips.

Comment on lines 9 to 11
export interface CoreSetup {
server: Legacy.Server;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

You may want to use the LegacySetup pattern that was recently added to the Migration Guide.

The gist for this is, add a 3rd argument to your plugin lifecycle method that represents all the legacy dependencies, and use the real CoreSetup interface as the first argument. This makes it easier to identify which parts still need to be migrated away from Legacy APIs and which parts are using the real CoreSetup APIs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, Josh. I attempted to implement this pattern in f35f1b5, but I'm not entirely sure if this is correct.

import { PLUGIN_ID } from '../../../common/constants';
import { wrapCustomError } from '../error_wrappers';

export const licensePreRoutingFactory = once(server => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just an FYI, I just opened a PR for adding examples of how to migrate these pre-route handlers: #56080. Not relevant for this PR, but should be helpful for completing the server-side.

@cjcenizal
Copy link
Contributor Author

@joshdover Would you mind reviewing my latest commit, which shims the public directory?

@cjcenizal cjcenizal force-pushed the chore/ilm-to-np-shim branch 3 times, most recently from c21fa42 to 9eafd5e Compare February 1, 2020 15:37
Comment on lines 90 to 91
// NOTE: We depend upon Angular's $http service because it's decorated with interceptors,
// e.g. to check license status per request.
Copy link
Contributor

Choose a reason for hiding this comment

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

The core.http.* APIs have the same interceptors installed as well.

element: HTMLElement;
}

export const boot = (appDependencies: AppDependencies) => {
Copy link
Contributor

Choose a reason for hiding this comment

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

By convention this should be named renderApp.

Comment on lines +48 to +54
const esSection = management.getSection('elasticsearch');
esSection.register('index_lifecycle_policies', {
visible: true,
display: PLUGIN.TITLE,
order: 2,
url: `#${BASE_PATH}policies`,
});
Copy link
Contributor

Choose a reason for hiding this comment

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

FYI once you're app is de-coupled from Angular, you can leverage the new Management plugin in the NP. Can do this in the next PR though.

Comment on lines 73 to 83
application: {
...npSetup.core.application,
async register(app: App) {
const unmountApp = await app.mount({ ...npStart } as any, {
element,
appBasePath: '',
onAppLeave: () => undefined,
});
manageAngularLifecycle($scope, $route, unmountApp as any);
},
},
Copy link
Contributor

Choose a reason for hiding this comment

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

In the case of a management section app, you'll be using the management plugin's API instead of the Application service since this is not a top-level app. You can see the management API here: https://github.com/elastic/kibana/blob/master/src/plugins/management/public/types.ts#L25

kbnUrl.redirect(path);
});
},
fatalError,
Copy link
Contributor

Choose a reason for hiding this comment

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

There is an NP API on CoreSetup.fatalErrors

@@ -211,7 +216,20 @@ export class IndexActionsContextMenu extends Component {
},
});
getActionExtensions().forEach(actionExtension => {
const actionExtensionDefinition = actionExtension(indices, reloadIndices);
const actionExtensionDefinition = actionExtension({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sebelga Just a head's up that a few files are changing in Index Management, which we'll need to reconcile.

If I merge this PR in before you finish migrating Index Management then you'll just need to reconcile the conflicts by accepting these changes but passing in the NP http service in lieu of getNewPlatformCompatibleHttpClient.

If you merge in the Index Management migration before I merge this PR then I'll be able to reconcile the conflicts myself, but I don't think that's the best way to proceed. It would create less work for you to wait for this PR to get merged first, because then you won't need to preserve the dependency upon Angular's $http service.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK no problem, thanks for the heads up @cjcenizal !

- Update Index Management to provide a NP-compatible adapater around Angular's $http service.
- Remove unused sendPut method from API service.
- Update http error handling to consume NP http service errors.

// We will be able to remove this after the NP migration is complete and we can just inject the
// NP fatalErrors service..
const getNewPlatformCompatibleFatalErrorService = () => ({
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sebelga Here's another example of a service adapter that will become unnecessary as part of your migration.

@cjcenizal
Copy link
Contributor Author

@joshdover Thanks for the review! I've made the changes you suggested. Could you please re-review?

@cjcenizal cjcenizal marked this pull request as ready for review February 3, 2020 22:33
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.

Shims LGTM

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.

@cjcenizal great work on this! 🎉

Code

Left a few comments and a question about when we should introduce IRouter. No other blockers.

UI/UX

  • UI looks good, didn't see any visual regressions!
  • I was not able to get step 5 of the Testing the Index Management extensions section in the PR description, everything else seemed to work!

registerLicenseChecker(server);

// Register routes.
registerIndexRoutes(server);
Copy link
Contributor

Choose a reason for hiding this comment

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

As part of this shimming, is it worth migrating the http routes to use the new platform IRouter? It should be available on CoreSetup which I see we are passing in from x-pack/legacy/plugins/index_lifecycle_management/index.ts. It does affect all of the routes so happy if this done later.

I think it is most useful that when we migrate the routes we don't pass the legacy server object in directly but rather create a RouteDependencies object that contains a __LEGACY entry. That way all of the legacy interfaces are clearly marked here and downstream.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 Agreed. Let's discuss later at the sync those conventions as I am also afraid of other places we might do things differently.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll migrate to the NP router in a subsequent PR. I agree that it would be great if we could align on a convention.

// The extend_index_management module that we support an injected httpClient here.

export async function loadNodes(httpClient) {
const response = await sendGet(`nodes/list`, httpClient);
Copy link
Contributor

Choose a reason for hiding this comment

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

Nit: unnecessary creation of response constant. Can just return send.... Same for other instances below. In some cases the await can also be omitted if just a one-liner.

import { i18n } from '@kbn/i18n';
export function checkLicense(xpackLicenseInfo) {

export function checkLicense(xpackLicenseInfo: any): any {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think there are typings available for this here: x-pack/legacy/plugins/xpack_main/server/lib/xpack_info.ts

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, I'll use them in the subsequent PR when I make more significant changes to the server.

@cjcenizal
Copy link
Contributor Author

Jenkins test this

@mistic
Copy link
Member

mistic commented Feb 5, 2020

@elasticmachine merge upstream

@brianseeders
Copy link
Contributor

@elasticmachine merge upstream

1 similar comment
@brianseeders
Copy link
Contributor

@elasticmachine merge upstream

@mistic
Copy link
Member

mistic commented Feb 5, 2020

@elasticmachine merge upstream

@cjcenizal
Copy link
Contributor Author

Jenkins test this

@cjcenizal
Copy link
Contributor Author

@elasticmachine merge upstream

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

History

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

@cjcenizal cjcenizal merged commit 51854c7 into elastic:master Feb 5, 2020
@cjcenizal cjcenizal deleted the chore/ilm-to-np-shim branch February 5, 2020 23:14
cjcenizal added a commit to cjcenizal/kibana that referenced this pull request Feb 6, 2020
- Move UI metric constants into public directory.
- Convert server-side code to TS, largely with use of any.
- Remove unused sendPut method from API service.
- Update http error handling to consume NP http service errors.
- Refactor DI pattern of Index Mangement extensions to require various NP service dependencies.
- Inject NP http service into Index Management extensions. Remove dependency upon Angular's $http.
cjcenizal added a commit that referenced this pull request Feb 6, 2020
- Move UI metric constants into public directory.
- Convert server-side code to TS, largely with use of any.
- Remove unused sendPut method from API service.
- Update http error handling to consume NP http service errors.
- Refactor DI pattern of Index Mangement extensions to require various NP service dependencies.
- Inject NP http service into Index Management extensions. Remove dependency upon Angular's $http.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
chore Feature:ILM 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.

8 participants