feat(epp): Add plugin lifecycle and stability levels proposal#2684
feat(epp): Add plugin lifecycle and stability levels proposal#2684hexfusion wants to merge 1 commit intokubernetes-sigs:mainfrom
Conversation
k8s-ci-robot
added
kind/feature
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: hexfusion The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @hexfusion. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
k8s-ci-robot
added
size/L
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
hexfusion
force-pushed
the
plugin-lifecycle-proposal
branch
from
e2e8491 to
d1e132c
Compare
| func Register(pluginType string, factory FactoryFunc) { | ||
| Registry[pluginType] = RegistryEntry{ | ||
| Factory: factory, | ||
| Stability: Unknown, |
There was a problem hiding this comment.
will it reject out of tree plugin until the migration?
There was a problem hiding this comment.
tbh, I would update Register function (instead of adding a different one) and out of tree plugins should be able to adopt it very easily, using Unknown on their end.
I would prefer to make it a must rather than keep Unknown stability which as far as I can see here - its behavior is not well defined.
does it require feature gate or not? should we allow it? why would out of tree plugins move from Unknown, what is their motivation?
| pluginType, entry.Stability)) | ||
| } | ||
| if entry.Stability == Alpha && entry.FeatureGate == "" { | ||
| panic(fmt.Sprintf( |
There was a problem hiding this comment.
don't panic. skip register and return an error.
There was a problem hiding this comment.
panic is scary will remove but we should consider Must in this context
| Unknown StabilityLevel = "Unknown" | ||
| Alpha StabilityLevel = "Alpha" | ||
| Beta StabilityLevel = "Beta" | ||
| Stable StabilityLevel = "Stable" |
There was a problem hiding this comment.
what about Deprecated?
Deprecated must come with Deprecation message.
| // error with migration guidance instead of the generic "not | ||
| // registered" error from instantiatePlugins. Tombstones are | ||
| // permanent and small. | ||
| var removedPlugins = map[string]string{ |
There was a problem hiding this comment.
not all plugins can be mapped 1:1 from old plugins to new.
for example - we might have an old plugin that we decide to split into two sub-plugins.
| 2. Should graduation criteria be GIE-specific, or adopt Gateway | ||
| API's requirements? | ||
| 3. Where does the stability policy live, `docs/plugin-lifecycle.md`, | ||
| `CONTRIBUTING.md`, or a dedicated proposal? |
There was a problem hiding this comment.
graduation criteria is a difficult question. if you ask 10 different people who know GIE well about 10 different plugins - you might hear different opinions about how graduated a plugin is.
I would document it the plugins doc in the website as well as in docs.
CONTRIBUTING.md is a general guide for contributions, not specific to plugins or anything related to their lifecycle.
| @@ -0,0 +1,322 @@ | |||
| # Plugin Lifecycle and Stability Levels | |||
3 participants
/kind feature
/kind documentation
What this PR does / why we need it:
Proposes a plugin lifecycle model for EPP plugins. Today a plugin either exists in the registry or it doesn't -- there is no way to communicate maturity to operators. This proposal adds three stability tiers (Alpha, Beta, Stable) with defined support contracts, feature gate integration for alpha plugins, and validation tombstones for removed plugins.
Which issue(s) this PR fixes:
Fixes #2653
Does this PR introduce a user-facing change?: