-
Notifications
You must be signed in to change notification settings - Fork 1
Description
New feature or functionality
As per the Update constraints section of the resource plugin spec, it's not currently possible to modify a resource plugin, for example if a bug or security issue is discovered. You must first ensure no sandboxes are using the plugin, then delete the plugin and recreate it:
A ResourcePlugin may be not be updated. Moreover, a ResourcePlugin cannot be deleted unless there are no sandboxes which refer to it.
You can of course implement your own "versioning" simply by appending a version to the plugin name, eg my-plugin-v0.1, my-plugin-v0.2, etc. However, these plugins are not linked in any way in the system, they are just separate plugins that happen to have a common prefix.
It would be great if Signadot supported a notion of plugin versions. When you create a plugin, you can specify the version number (see additional considerations).
Then, when you reference a plugin in a sandbox resource, if you use the simple plugin: my-plugin syntax, you get the current latest version of the plugin. However, plugin could also accept an object, allowing you to specify the exact plugin version, eg:
spec:
resources:
- name: my-resource
plugin:
name: my-plugin
version: 0.0.1
params:
.
.
This would allow new versions of the named plugin to be created, then old versions gracefully retired when no sandboxes are still referencing it.
Additional considerations
For backwards compatibility with existing plugin specs, maybe if a version is not provided, a default one (of say 0.0.0) could be assigned.