New root namespace plugin reload API sys/plugins/reload/:type/:name #24878
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 endpointsys/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.