Update Ratify CRDs to 1.0
What would you like to be added?
Currently the Ratify CRD is in beta, as we release GA, what are the considerations for bumping version to GA.
Anything else you would like to add?
No response
Are you willing to submit PRs to contribute to this feature?
- [ ] Yes, I am willing to implement it.
Hi @sozercan , we would like to consistent with CRD patterns that gatekeeper follows. Our questions:
- We currently have some CRD in alpha and beta , Once we are ready to GA ratify, does all CRD gets rebased to 1.0?
- IF we are to introduce new CRDs, should the new CRD start with alpha version?
Maybe if the CRD is tied into a Experiental feature it could be in alpha /beta, but if its a stable feature, it should be the same version as the released version. What pattern does gatekeeper follow?
@susanshi I would recommend graduting the ones you are think stable to v1 (for example, core resources). You can keep alpha CRDs for experimental feature and introduce new ones as alpha first. Also make sure to keep backwards compability: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/
We are still investigating below items, we don't think we will be able to complete the following during v1 milestone. @FeynmanZhou , are we ok pushing this to 1.1?
- add namespace to certStore ( if no namespace, assume default namespace), this impact both CertStore and verifier code path.
- clean up store ( beta -> 1.0 ) , clean up cache related setting
- Policy crd related item , https://github.com/deislabs/ratify/issues/1067
Potentially we are updating Verifier to namespace scope instead of cluster scope , we are currently not ready for CRD1.0, moving this out to "future" milestone