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

[EPM] handle unremovable packages #64096

Merged

Conversation

neptunian
Copy link
Contributor

@neptunian neptunian commented Apr 21, 2020

#63530

  • remove endpoint handles unremovable packages
  • adjust UI to disallow removing of unremovable packages

DELETE http://localhost:5603/ssg/api/ingest_manager/epm/packages/system-0.9.0
Screen Shot 2020-04-21 at 2 11 40 PM

Whether or not datasources are connected to an unremovable package:
Screen Shot 2020-04-21 at 2 09 17 PM

@neptunian neptunian requested a review from a team April 21, 2020 18:10
@neptunian neptunian self-assigned this Apr 21, 2020
@neptunian neptunian added v8.0.0 v7.8.0 release_note:skip Skip the PR/issue when compiling release notes labels Apr 21, 2020
const installedObjects = installation?.installed || [];
if (!installation) throw new Error('integration does not exist');
if (installation.removable === false)
throw new Error(`The ${pkgName} integration is installed by default and cannot be removed`);
Copy link
Member

Choose a reason for hiding this comment

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

Could we throw BadRequest error so we have a 400 it's a user error?

Copy link
Member

Choose a reason for hiding this comment

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

If someone tries to do this through the API, what response code does he get currently?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ruflin 500

Copy link
Member

Choose a reason for hiding this comment

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

@jfsiii Any thoughts on which error code we should return?

Overall, I would not block the PR on which error code we should return. Which API error codes we return where we should probably have a general look.

Copy link
Contributor Author

@neptunian neptunian Apr 22, 2020

Choose a reason for hiding this comment

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

@nchaulet Because NP http interface does not have native support for converting Boom exceptions into HTTP responses I am thinking we need some kind of helper for this. Otherwise we are having to check for each type of error? https://github.com/elastic/kibana/blob/master/x-pack/plugins/ingest_manager/server/routes/agent/handlers.ts#L57 . Perhaps we can always through Boom errors and always return custom errors that pass along Boom results?

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 a 4xx is appropriate because it's a client error vs a server error. At no time will the request succeed, so we should make sure the client knows the issue is on their end.

Any of 400, 403, or 405 are good, IMO.

How about 400 for now and I/we can come back to it during the API consistency ticket for Beta?

Copy link
Member

Choose a reason for hiding this comment

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

Yes it need some custom code in the handler I did it like this for some fleet APIs https://github.com/elastic/kibana/blob/master/x-pack/plugins/ingest_manager/server/routes/agent/handlers.ts#L122

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

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

@neptunian neptunian merged commit db642f0 into elastic:master Apr 22, 2020
neptunian added a commit to neptunian/kibana that referenced this pull request Apr 22, 2020
* remove endpoint handles unremovable packages

* adjust UI to disallow removing of unremovable packages
neptunian added a commit that referenced this pull request Apr 22, 2020
* remove endpoint handles unremovable packages

* adjust UI to disallow removing of unremovable packages

Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Copy link
Contributor

@jfsiii jfsiii left a comment

Choose a reason for hiding this comment

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

Sorry for the after the fact review. This was left pending since I wrote on my phone.

const installedObjects = installation?.installed || [];
if (!installation) throw new Error('integration does not exist');
if (installation.removable === false)
throw new Error(`The ${pkgName} integration is installed by default and cannot be removed`);
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 a 4xx is appropriate because it's a client error vs a server error. At no time will the request succeed, so we should make sure the client knows the issue is on their end.

Any of 400, 403, or 405 are good, IMO.

How about 400 for now and I/we can come back to it during the API consistency ticket for Beta?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release_note:skip Skip the PR/issue when compiling release notes v7.8.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants