-
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
[Fleet] Add support for "Edit Package Policy" extensions using latest version of a package #114914
Changes from 10 commits
86d59fc
6964c66
b88dc36
0e0c2b7
e4dba75
84dbe21
1afedd3
c4abf7d
61bea60
eb0c5bc
6c9a1f6
76840c7
1d4f414
859a333
db57f16
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -192,6 +192,7 @@ export class Plugin implements IPlugin<PluginSetup, PluginStart, SetupPlugins, S | |
registerExtension({ | ||
package: 'endpoint', | ||
view: 'package-policy-edit', | ||
useLatestPackageVersion: true, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure this is a requirement for the Endpoint package since Elastic Agent has the ability to dynamically run different versions of the endpoint binary. That said, I can't really think of any downsides here since the user is already going to be pushing out updates to all of their endpoints. Let me figure out the best person to talk to about this. |
||
Component: getLazyEndpointPolicyEditExtension(core, plugins), | ||
}); | ||
|
||
|
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.
@joshdover @jen-huang
My change to return a bad request in the case of general failures, and instead allowing only validation errors to be considered non-fatal errors in 61bea60 revealed an interesting issue:
This API request to
/upgrade
the package policy was always failing before, we just didn't return an error-coded HTTP response. We returned a 200 withsuccess: false
in the body. However, the actual "upgrade" process has been and remains successful to this date. Why is that?What we were actually doing here in the policy editor was:
/upgrade
endpoint, and receive an error because the policy has already been saved with the new package versionSo, the
/upgrade
endpoint in its non-dry-run context was essentially useless in this workflow. And it is largely useless overall because we don't support editing at the time of upgrade. A consumer would have to make their edits to the outdated package policy prior to upgrading, which doesn't make sense because it'd result in an invalid package policy. We'd be adding values for variables defined in the new version of the package, then validating them against the outdated version of the package.Instead, by removing this
/upgrade
call, we have a workflow that stops at #3 above. So our functionality is entirely the same as it was before, we've just done away with an erroneous call at the end of the process.It seems to me like maybe we should formalize this and re-do some of the ergonomics of our upgrade process. The only purpose of the non-dry-run upgrade endpoint, at this point, would to be to perform an upgrade with no edits, then allow the user to make edits to their policy after the upgrade is complete. It seems like this is not a realistic user experience based on our implementation in Fleet, so it doesn't make sense to me to even support it. Instead, we should focus on the path of "Generate proposed upgraded policy -> Allow for edits to proposed policy -> Persist proposed policy".
I know this is long but I would love to get some thoughts here. Happy to sync offline as well.
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.
The actual
upgrade
service method still serves a purpose in upgrading package policies automatically, to be clear. We want to attempt an upgrade and fail if there are any conflicts. I am just proposing that we do away with the API endpoint that serves that same purpose.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 makes sense to me. It seems this endpoint is only useful in the context of attempting to automate an upgrade without any user intervention. If that's the case, then I think we should remove the ability to specify any edits / input vars in the upgrade endpoint and instead only use it for attempting to upgrade a policy automatically without any edits.
It'd then make sense to move the logic for executing a dry run + getting the new proposed policy to a separate endpoint.
To make sure I'm understanding correctly, if we followed this logic, we'd end up with something like:
POST /package-policy/<id>/upgrade
for attempting automated upgrades without edits. Does not accept any inputs or request body at all. Will fail if there's a conflict.GET /package-policy/<id>/upgrade
for executing a dry run and getting the "proposed package policy"PUT /package-policy/<id>
for saving an existing policy, potentially with a higher version. Accepts all input fields. Will fail if validation fails for the given package version.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.
Yes that sounds like a great improvement for the layout of this particular API.
This is how the
POST /package-policy/<id>/upgrade
endpoint works today.This is the current functionality of the
POST /package-policy/<id>/upgrade { dryRun: true }
API callThis is existing functionality as well. So the only change here should be moving away from the
dryRun: true
request parameter, and creating a distinctGET /upgrade
endpoint wired up to that particular service method instead.I created #115570 to capture this piece of work. I tagged it as
technical debt
for now.