-
Notifications
You must be signed in to change notification settings - Fork 21
Description
Over time, markers have evolved in at least two places, Kubernetes/Kubernetes, controller-tools (kubebuilder) and even within downstream projects.
As we move towards the upstream Kubernetes declarative validation project, I'm expecting that we will duplicate lots of the functionality of the kubebuilder markers (e.g. things like +kubebuilder:validation:MinLength).
In general, I believe that projects would like to be consistent, and, where they are using KAL, would likely want to enforce that certain markers are used over others.
We already have this today, there are three versions of optional (+k8s:optional, +kubebuilder:validation:Optional), and in would expect folks to prefer to have only one of these equivalent markers across their project.
So we should enable a configurable linter to allow folks to express that certain markers should be replaced with alternative, equivalent, preferred markers.
I could also see this being called DeprecatedMarkers or EquivalentMarkers, need some discussion on that.
I also think we should make sure that the configuration allows a potential future where we need to remap fields, so the config should be a structure that will allow this expansion in the future.
preferredmarkers:
markers:
- preferredIdentifier: some:marker
equivalentIdentifiers:
- some:old:marker
- another:old:marker
attrsMapping: # Future work if we find a need for it?
- identifier: some:old:marker
attrs:
- source: oldAttr
dest: newAttr