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

New root namespace plugin reload API sys/plugins/reload/:type/:name #24878

Merged
merged 2 commits into from
Jan 17, 2024

Conversation

tomhjp
Copy link
Contributor

@tomhjp tomhjp commented Jan 16, 2024

CE changes for https://github.com/hashicorp/vault-enterprise/pull/5171.

Introduces a new API endpoint sys/plugins/reload/:type/:name to reload plugins (mirroring the style of the plugin catalog's plugin registration endpoint sys/plugins/catalog/:type/:name). Just like the plugin catalog, it's only available in the root namespace, and it affects all namespaces equally. This is to make it a good match for completing a plugin upgrade after a new plugin version has been registered in the catalog.

The endpoint reloads the named plugin across namespaces, and optionally across other nodes in the cluster too, taking advantage of the same mechanism as sys/plugins/reload/backend. The leader writes the reload request to a special path in storage, and when follower nodes see an update at that path, they deserialise the request and trigger the reload locally. Once completed, they write back into storage to report on any errors. This mechanism is left largely untouched, with just some minor refactoring to allow more flexible usage.

I decided not to repurpose the pre-existing sys/plugins/reload/backend because it is limited to the same namespace as the request, so users registering a new plugin version would have to enumerate all namespaces to complete a full plugin reload. However, broadening that existing API out to work across namespaces is undesirable both for backwards compatibility and policy reasons (users who already have permission to use the namespaced endpoint should not suddenly get their permissions expanded on upgrading Vault).

The PR also includes CLI, api, and docs updates. While that does make it quite a large PR, there was so much interaction between the requirements for each of those that it felt like it would be too incomplete as a PR to split it up into those smaller pieces. For example, this PR takes care to implement an API that can be adopted by the CLI without causing surprises about behaviour or backwards compatibility.

@tomhjp tomhjp added this to the 1.16.0-rc1 milestone Jan 16, 2024
@tomhjp tomhjp requested review from a team as code owners January 16, 2024 14:36
@github-actions github-actions bot added the hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed label Jan 16, 2024
@tomhjp tomhjp requested a review from swenson January 16, 2024 14:37
Copy link

Build Results:
All builds succeeded! ✅

Copy link

CI Results:
All Go tests succeeded! ✅

Copy link
Contributor

@fairclothjm fairclothjm left a comment

Choose a reason for hiding this comment

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

Do we also want to update https://developer.hashicorp.com/vault/docs/commands/plugin/reload as well?

Otherwise, LGTM! Thanks @tomhjp!

@tomhjp
Copy link
Contributor Author

tomhjp commented Jan 17, 2024

Do we also want to update https://developer.hashicorp.com/vault/docs/commands/plugin/reload as well?

Thanks, great call out - added in 6be5d09

@tomhjp tomhjp enabled auto-merge (squash) January 17, 2024 15:21
@tomhjp tomhjp merged commit 80f85a0 into main Jan 17, 2024
109 checks passed
@tomhjp tomhjp deleted the vault-21610/root-reload-plugin-api branch January 17, 2024 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hashicorp-contributed-pr If the PR is HashiCorp (i.e. not-community) contributed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants