Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

apiextensions: validate list-type map+set uniqueness in CRs #84920

Merged

Conversation

sttts
Copy link
Contributor

@sttts sttts commented Nov 7, 2019

/kind api-change
/kind bug

Fixes #84724.

Fixed missing validation of uniqueness of list items in lists with `x-kubernetes-list-type: map` or x-kubernetes-list-type: set` in CustomResources.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API size/L Denotes a PR that changes 100-499 lines, ignoring generated files. kind/bug Categorizes issue or PR as related to a bug. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Nov 7, 2019
@sttts sttts added priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. and removed needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Nov 7, 2019
@k8s-ci-robot k8s-ci-robot added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Nov 7, 2019
@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch from 590c837 to 5cc374e Compare November 7, 2019 13:29
@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 7, 2019
@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch from 5cc374e to 7be2000 Compare November 7, 2019 17:22
@k8s-ci-robot k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 7, 2019
@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch from 7be2000 to 26b38de Compare November 7, 2019 20:39
@k8s-ci-robot k8s-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Nov 7, 2019
@sttts sttts changed the title WIP: apiextensions: validate list-type map+set uniqueness in CRs apiextensions: validate list-type map+set uniqueness in CRs Nov 7, 2019
@k8s-ci-robot k8s-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 7, 2019
@jennybuckley
Copy link

/assign

@fejta-bot
Copy link

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

@jtslear
Copy link

jtslear commented Feb 5, 2020

Hello @liggitt, @sttts
Bug Triage team here for the 1.18 release. This is a friendly reminder that code freeze is scheduled for 5 March. Is this PR appears to be blocking #84724, is this still intended for milestone 1.18?

@sttts
Copy link
Contributor Author

sttts commented Feb 19, 2020

@apelisse addressed your comments.

@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch from 0965aee to 5c82b80 Compare February 19, 2020 08:02
return nil, nil
}
if len(obj) == 2 {
if reflect.DeepEqual(obj[0], obj[1]) {
Copy link
Member

@liggitt liggitt Feb 24, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are there cases where this would return false for complex array or map objects, but json-marshalling and comparing would be identical?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

json.Marshal is the inverse of json.Unmarshal. If both values are the result of json.Unmarshal then this will not happen.

What do you have in mind? Our patch logic?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more issues like json-iterator/go#323, where json-iterator normalizes on marshal as opposed to encoding/json normalizing on both unmarshal/marshal

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ic. Suggestion? Marshal again?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is definitely simpler to reason about; that's what I would do to start

@apelisse
Copy link
Member

I have a couple of additional comments.

I'm really not convinced that we want listMapKeys fields to be anything but required. Having a "nil" item validate because both keys are missing and transforming this into a valid case really feels wrong. As far as I know, we have one such case in Kubernetes, that's the protocol in the list of ports of the podspec. We might find a way to fix that one specifically, but I'd rather not generalize this problem. Alternatively, we could allow these to be if they have a default value, and in this case consider the default as the key value. IOW, "required or has a default" (that would also work for the protocol problem).

Second, I was discussion ratcheting with Daniel, and forcing the created objects to pass this validation only works if we assume that no controller/system is currently creating invalid objects. This change would break such a controller?

@sttts
Copy link
Contributor Author

sttts commented Feb 25, 2020

I'm really not convinced that we want listMapKeys fields to be anything but required. Having a "nil" item validate because both keys are missing and transforming this into a valid case really feels wrong. As far as I know, we have one such case in Kubernetes, that's the protocol in the list of ports of the podspec. We might find a way to fix that one specifically, but I'd rather not generalize this problem. Alternatively, we could allow these to be if they have a default value, and in this case consider the default as the key value. IOW, "required or has a default" (that would also work for the protocol problem).

All this is done via ratcheting validation, i.e. we enforce required or a default. We forbid nullable: #88076. Please review.

@sttts
Copy link
Contributor Author

sttts commented Feb 25, 2020

Second, I was discussion ratcheting with Daniel, and forcing the created objects to pass this validation only works if we assume that no controller/system is currently creating invalid objects. This change would break such a controller?

This is what we always do in those cases, ratcheting validation. It is the very reason why this issue is marked urgent for months. The more we wait (1.18 is around the corner) the more controllers will exist. I bet the number is zero today.

@liggitt
Copy link
Member

liggitt commented Feb 25, 2020

Anyone defining a CRD that uses list-type: map/set must be able to rely on the documented semantics (we rely on them ourselves in server-side-apply). It is very important we not allow data that violates those semantics, and do so as soon as possible.

@liggitt
Copy link
Member

liggitt commented Feb 25, 2020

Alternatively, we could allow these to be if they have a default value, and in this case consider the default as the key value. IOW, "required or has a default" (that would also work for the protocol problem).

That's what we settled on. Disallowing nullable and making the key attributes either be required or defaulted gives this set validation reasonable inputs to work with, and allows evolution or recovery from underspecified key sets (e.g. an underspecified item schema for a port realizes in the future it needs a protocol field that should be added to the item key specification, and needs to provide a default for existing persisted data that lacked that field).

@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch 4 times, most recently from 66f5e8c to 99b4ec1 Compare February 25, 2020 14:31
@liggitt
Copy link
Member

liggitt commented Feb 25, 2020

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 25, 2020
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, sttts

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@sttts sttts force-pushed the sttts-cr-list-type-set-map-validation branch from 99b4ec1 to ea45da7 Compare February 25, 2020 17:35
@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 25, 2020
@k8s-ci-robot
Copy link
Contributor

New changes are detected. LGTM label has been removed.

@sttts sttts added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Feb 25, 2020
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

1 similar comment
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to fejta).

Review the full test history for this PR.

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/bug Categorizes issue or PR as related to a bug. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

list-type set and map lack CR validation
10 participants