structured-merge-diff

structured-merge-diff copied to clipboard

I'm told that 1.16 supports interpreting a CRD which has x-kubernetes-list-map-type and x-kubernetes-list-map-keys properties.

Please document somewhere an example of a CRD that uses these, so the syntax is clear.

Please also document what happens if I have an already-installed CRD with existing CR state, and I am already using SSA, and I update a property of my CRD from not having x-kubernetes-list-* annotations to having them. That is, what happens if an existing user adopts this nice new feature? Does it DTRT or explode?
For existing CRs that have been applied before. That haven't? For new CRs?

@apelisse we just discussed this.

I have done or plan on doing:

• [x] Split into multiple tasks and added to the umbrella issue
• [x] Documented in the KEP https://github.com/kubernetes/enhancements/pull/1320
• [x] Created a PR to add support in kubebuilder https://github.com/kubernetes-sigs/controller-tools/pull/347
• [x] Implement +mapType and +structType in kube-openapi (https://github.com/kubernetes/kube-openapi/blob/master/pkg/generators/extension.go#L38-L57): https://github.com/kubernetes/kube-openapi/pull/178
• [ ] Document how removing list/map items work for CRD and Built-in types with SSA: https://github.com/kubernetes/website/issues/16725
• [ ] Document difference between marker and tags in built-in types (see https://github.com/kubernetes/community/pull/4218#issuecomment-584724815)
• [ ] Update API Conventions https://github.com/kubernetes/community/issues/3752
• [ ] Created a new section in CRD docs for topology (no PR yet)
• [ ] Topology compatibility:
  • [x] Understand how changing the topology affects API compatibility
  • [ ] Document these guarantees/limitations
  • [x] Write tests to validate the guarantees
• [ ] Make sure that atomic is properly documented as recursive
• [ ] Make sure that sets and map keys are documented as scalar or atomic
• [x] +listType has both associative and map in different places: pick one and apply everywhere
• [ ] Document list keys have to be "scalar"
• [ ] Try to guess good keys if we find one on a list https://github.com/kubernetes/kubernetes/issues/87674

(as discussed on #wg-apply) /assign

I just found some documentation for this here: https://github.com/kubernetes/kube-openapi/blob/master/pkg/idl/doc.go

I have no memory of writing this, but sure. Also I don't think +mapTypeand +structType are implemented in this repo, so I'm adding an extra item to the plan.

https://github.com/kubernetes/kube-openapi/blob/master/pkg/generators/extension.go#L38-L57

This is probably doing most of the work, so updating this should be straightforward.

Thanks for the links @apelisse 👌 I'm starting with kube-openapi support and will move on to kubebuilder after (will update with issue refs shortly)

That sounds like a great plan! Thanks!

Support for +mapType and +structType in kube-openapi is covered (I think) with: https://github.com/kubernetes/kube-openapi/pull/178.

...and support for x-kubernetes-map-type in controller-tools: https://github.com/apelisse/controller-tools/pull/1 (which should land with kubernetes-sigs/controller-tools#347)

Thanks @mariantalla I'll update my comment

WIP PR to api-conventions: https://github.com/kubernetes/community/pull/4218

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

/lifecycle frozen