🌱 Plugin resolution enhancement proposal #1942
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Adirio The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
|
||
| 1. [All commands but Init] Obtain the project version and plugin keys from the project configuration if available. | ||
| * If they are available, plugin keys will be fully qualified. | ||
| 2. [Init command only] Obtain the project version from `--project-version` flag. |
There was a problem hiding this comment.
One of the advantages implementation-wise of this new approach is that --project-version stops being a global variable for all commands that need to be special cased. It will just be a local variable of the Init command.
Signed-off-by: Adrian Orive <adrian.orive.oneca@gmail.com>
Adirio
force-pushed
the
plugin-resolution-design
branch
from
d882b9c
to
a6042c6
Compare
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
| 4. Qualify the unqualified keys from step 3. | ||
| * If we know the project version, use this info to filter the available plugins so that we can be more accurate. | ||
| 5. Resolve the plugins with the list of qualified keys above. | ||
| 6. [Init command only] Resolve the project version in case it wasn't provided and there is only one project version |
There was a problem hiding this comment.
What if two default plugins support the same project version? Which will be chosen?
There was a problem hiding this comment.
Actually this doesn't seem to be a problem if default plugins are forced to have a disjoint set of supported project versions.
There was a problem hiding this comment.
However, I may want to specify a plugin for a particular project version, not just the project versions it supports. These changes take my ability to do that away.
There was a problem hiding this comment.
What if two default plugins support the same project version? Which will be chosen?
This proposal takes into account that we will support plugin chains. Having multiple plugins set as default means that it is a default chain. This proposal removes the ability to provide different plugin/plugin-chains for each project version, but I guess we could try to keep this behavior.
| 1. [All commands but Init] Obtain the project version and plugin keys from the project configuration if available. | ||
| * If they are available, plugin keys will be fully qualified. | ||
| 2. [Init command only] Obtain the project version from `--project-version` flag. | ||
| * The flag is optional, we will try to resolve project version later in case it is not provided. |
There was a problem hiding this comment.
There will always be a default project version. If no default plugins support the default project version, then an error should be returned.
There was a problem hiding this comment.
The idea here is, in case they provide a project version, make decissions knowing it, but in case it wasn't provide, just make decissions as if it was unknown and try to resolve it later.
Imagine I have the following plugins resolved:
| Plugin | Supported project version |
|---|---|
| go/v2 | 2, 3 |
| go/v3 | 3 |
| declarative/v1 | 2, 3 |
If the user provides a --plugins=go/v3,declarative flag, we would resolve to the last two plugins, and the only supported project version by both of them is 3 so we can implicitly resolve the project version.
If the user provides a --plugins=go/v2,declarative flag, we would resolve to the first and last plugin, and two different project versions are supported. If any of those is the default project version configured for the CLI, that will be used.
So we will have 3 ways of resolving the project version:
- Explicitly by providing
--project-versionflag or having an already present config file (versionfield). - Implicitly by providing a set of plugins that only support a single common project version.
- Default in case all resolved plugins support the default project version defined in the CLI.
In case none of the three above cases applies, an error ambiguous-project-version will be returned.
Enhance the plugin resolution algorithm to simplify the user experience and allow plugins to be defined by command call.
Implementation: #2019