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

BUG 1769004: Make Machine/MachineSets structural #552

Merged
merged 3 commits into from Apr 24, 2020

Conversation

JoelSpeed
Copy link
Contributor

This PR:

  • Upgrades CRDs to extensions/v1
  • Sets XPreserveUnknownFields: true on runtime.RawExtensions within Machine and MachineSet types
  • Sets preserveUnknownFields: false on CRDs
  • Adds roundtrip fuzzed tests of Machine/MachineSet to ensure no data is lost by these changes

The user facing effect of this is that the CRDs are now structural and oc explain will work as expected

Note: This PR won't pass tests until rebased onto #550

@openshift-ci-robot
Copy link
Contributor

@JoelSpeed: This pull request references Bugzilla bug 1769004, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target release (4.5.0) matches configured target release for branch (4.5.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

BUG 1769004: Make Machine/MachineSets structural

Instructions 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/test-infra repository.

@openshift-ci-robot openshift-ci-robot added the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Apr 6, 2020
kind: CustomResourceDefinition
metadata:
annotations:
exclude.release.openshift.io/internal-openshift-hosted: "true"
controller-gen.kubebuilder.io/version: (devel)
Copy link
Member

Choose a reason for hiding this comment

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

can we drop this?

@@ -32,136 +20,150 @@ spec:
singular: machinehealthcheck
scope: Namespaced
preserveUnknownFields: false
Copy link
Member

Choose a reason for hiding this comment

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

Can we drop preserveUnknownFields: false? it's default in apiextensions.k8s.io/v1. "This can either be true or undefined. False is forbidden." https://book.kubebuilder.io/reference/markers/crd-processing.html

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe that is for the values within the OpenAPIV3Schema block.

As I understand it, this value is required to enable upgrades to work smoothly

For CustomResourceDefinitions created in apiextensions.k8s.io/v1, structural OpenAPI v3 validation schemas are required and pruning is enabled and cannot be disabled (note that CRDs converted from apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1 might lack structural schemas, and spec.preserveUnknownFields might be true).

From: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#pruning-versus-preserving-unknown-fields

Because the definitions have been created using the extensions/v1beta1 API up until now and didn't have structural schemas, the spec.PreserveUnknownFields value has been set to true, even when stored as extensions/v1.
So we need to force the value to false to ensure the CRD starts being pruned and restores the behaviour to the default behaviour for v1

Copy link
Member

Choose a reason for hiding this comment

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

cc @sttts to confirm

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Posted a message to sig-api-machinery (https://kubernetes.slack.com/archives/C0EG7JC6T/p1586869328387600) and got a confirmation there that the behaviour is as I've described

Copy link

Choose a reason for hiding this comment

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

false is the default. If I see this correctly it only depends only on your apply mechanism. These CRDs are applied through CVO?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct, these are applied by CVO, do we not need the field then? It was my understanding that if the CRD was created as v1beta1, it would be stuck with preserveUnknownFields: true if read/updated as v1, unless explicitly overwritten, is that not the case?

Copy link

Choose a reason for hiding this comment

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

As I wrote: it depends on CVO's apply mechanism. If it reads your former v1beta1 CRD as v1, it won't know that it was originally a v1beta1 CRD. I assume it will compare the v1 in cluster to the v1 from your manifests. Read the CVO code to find out whether it takes preserveUnknownFields into consideration.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, having a look through, it seems that applying a CRD via CVO "stomps" the spec, and then sends an update rather than doing a merge as I had expected (like kubectl apply), so I think we can drop preserveUnknownFields, thanks @sttts

https://github.com/openshift/cluster-version-operator/blob/ee4cd7ea187de8f65eed1a57937254fbe8810308/lib/resourcemerge/apiext.go#L61-L65

https://github.com/openshift/cluster-version-operator/blob/ee4cd7ea187de8f65eed1a57937254fbe8810308/lib/resourceapply/apiext.go#L56-L63

hack/gen-crd.sh Outdated
@@ -37,4 +44,8 @@ annotate_crd $dir/src/github.com/openshift/machine-api-operator/config/crds/mach
annotate_crd $dir/src/github.com/openshift/machine-api-operator/config/crds/machine.openshift.io_machinesets.yaml install/0000_30_machine-api-operator_03_machineset.crd.yaml
annotate_crd $dir/src/github.com/openshift/machine-api-operator/config/crds/machine.openshift.io_machines.yaml install/0000_30_machine-api-operator_02_machine.crd.yaml

set_preserve_unknown_fields install/0000_30_machine-api-operator_03_machineset.crd.yaml
set_preserve_unknown_fields install/0000_30_machine-api-operator_02_machine.crd.yaml
Copy link
Member

Choose a reason for hiding this comment

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

@JoelSpeed JoelSpeed force-pushed the structural-machines branch 2 times, most recently from b3af466 to b13c082 Compare April 7, 2020 11:15
@JoelSpeed
Copy link
Contributor Author

/retest

properties:
annotations:
additionalProperties:
preserveUnknownFields: false
Copy link

Choose a reason for hiding this comment

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

fyi, this is the default in v1. No need to specify.

@JoelSpeed JoelSpeed force-pushed the structural-machines branch 2 times, most recently from 5cb8e01 to 7a78987 Compare April 22, 2020 10:09
@enxebre
Copy link
Member

enxebre commented Apr 22, 2020

/retest
/approve

@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enxebre

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 22, 2020
@JoelSpeed
Copy link
Contributor Author

/retest

2 similar comments
@JoelSpeed
Copy link
Contributor Author

/retest

@JoelSpeed
Copy link
Contributor Author

/retest

@elmiko
Copy link
Contributor

elmiko commented Apr 24, 2020

this is a great addition, love the fuzzing tests too. nicely done Joel!

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 24, 2020
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Apr 24, 2020

@JoelSpeed: The following test failed, say /retest to rerun all failed tests:

Test name Commit Details Rerun command
ci/prow/e2e-azure 7a78987 link /test e2e-azure

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions 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/test-infra repository. I understand the commands that are listed here.

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift-merge-robot openshift-merge-robot merged commit b9f8d29 into openshift:master Apr 24, 2020
@openshift-ci-robot
Copy link
Contributor

@JoelSpeed: All pull requests linked via external trackers have merged: openshift/machine-api-operator#552. Bugzilla bug 1769004 has been moved to the MODIFIED state.

In response to this:

BUG 1769004: Make Machine/MachineSets structural

Instructions 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/test-infra repository.

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. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants