diff --git a/config/crds/kyverno.io_admissionreports.yaml b/config/crds/kyverno.io_admissionreports.yaml index aa696d9f1b..5b84c7a1a1 100644 --- a/config/crds/kyverno.io_admissionreports.yaml +++ b/config/crds/kyverno.io_admissionreports.yaml @@ -77,9 +77,11 @@ spec: blockOwnerDeletion: description: If true, AND if the owner has the "foregroundDeletion" finalizer, then the owner cannot be deleted from the key-value - store until this reference is removed. Defaults to false. To - set this field, a user needs "delete" permission of the owner, - otherwise 422 (Unprocessable Entity) will be returned. + store until this reference is removed. See https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion + for how the garbage collector interacts with this field and + enforces the foreground deletion. Defaults to false. To set + this field, a user needs "delete" permission of the owner, otherwise + 422 (Unprocessable Entity) will be returned. type: boolean controller: description: If true, this reference points to the managing controller. @@ -175,32 +177,33 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty - describing its usage when embedded in APIs. 1. Ignored fields. It - includes many fields which are not generally honored. For - instance, ResourceVersion and FieldPath are both very rarely - valid in actual usage. 2. Invalid usage help. It is impossible - to add specific help for individual usage. In most embedded - usages, there are particular restrictions like, "must refer - only to types A and B" or "UID not honored" or "name must - be restricted". Those cannot be well described when embedded. - 3. Inconsistent validation. Because the usages are different, - the validation rules are different by usage, which makes - it hard for users to predict what will happen. 4. The fields - are both imprecise and overly precise. Kind is not a precise - mapping to a URL. This can produce ambiguity during interpretation - and require a REST mapping. In most cases, the dependency - is on the group,resource tuple and the version of the actual + describing its usage when embedded in APIs. 1. Ignored fields. + \ It includes many fields which are not generally honored. + \ For instance, ResourceVersion and FieldPath are both very + rarely valid in actual usage. 2. Invalid usage help. It + is impossible to add specific help for individual usage. + \ In most embedded usages, there are particular restrictions + like, \"must refer only to types A and B\" or \"UID not + honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. + \ Because the usages are different, the validation rules + are different by usage, which makes it hard for users to + predict what will happen. 4. The fields are both imprecise + and overly precise. Kind is not a precise mapping to a + URL. This can produce ambiguity during interpretation and + require a REST mapping. In most cases, the dependency is + on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates to this - type will affect numerous schemas. Don''t make new APIs - embed an underspecified API type they do not control. Instead - of using this type, create a locally provided and used type - that is well-focused on your reference. For example, ServiceReferences - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n + Instead of using this type, create a locally provided and + used type that is well-focused on your reference. For example, + ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 + ." properties: apiVersion: description: API version of the referent. diff --git a/config/crds/kyverno.io_backgroundscanreports.yaml b/config/crds/kyverno.io_backgroundscanreports.yaml index f6997dfdbb..3e1ca4d553 100644 --- a/config/crds/kyverno.io_backgroundscanreports.yaml +++ b/config/crds/kyverno.io_backgroundscanreports.yaml @@ -143,32 +143,33 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty - describing its usage when embedded in APIs. 1. Ignored fields. It - includes many fields which are not generally honored. For - instance, ResourceVersion and FieldPath are both very rarely - valid in actual usage. 2. Invalid usage help. It is impossible - to add specific help for individual usage. In most embedded - usages, there are particular restrictions like, "must refer - only to types A and B" or "UID not honored" or "name must - be restricted". Those cannot be well described when embedded. - 3. Inconsistent validation. Because the usages are different, - the validation rules are different by usage, which makes - it hard for users to predict what will happen. 4. The fields - are both imprecise and overly precise. Kind is not a precise - mapping to a URL. This can produce ambiguity during interpretation - and require a REST mapping. In most cases, the dependency - is on the group,resource tuple and the version of the actual + describing its usage when embedded in APIs. 1. Ignored fields. + \ It includes many fields which are not generally honored. + \ For instance, ResourceVersion and FieldPath are both very + rarely valid in actual usage. 2. Invalid usage help. It + is impossible to add specific help for individual usage. + \ In most embedded usages, there are particular restrictions + like, \"must refer only to types A and B\" or \"UID not + honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. + \ Because the usages are different, the validation rules + are different by usage, which makes it hard for users to + predict what will happen. 4. The fields are both imprecise + and overly precise. Kind is not a precise mapping to a + URL. This can produce ambiguity during interpretation and + require a REST mapping. In most cases, the dependency is + on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates to this - type will affect numerous schemas. Don''t make new APIs - embed an underspecified API type they do not control. Instead - of using this type, create a locally provided and used type - that is well-focused on your reference. For example, ServiceReferences - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n + Instead of using this type, create a locally provided and + used type that is well-focused on your reference. For example, + ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 + ." properties: apiVersion: description: API version of the referent. diff --git a/config/crds/kyverno.io_clusteradmissionreports.yaml b/config/crds/kyverno.io_clusteradmissionreports.yaml index fdf7848b20..de7da4243d 100644 --- a/config/crds/kyverno.io_clusteradmissionreports.yaml +++ b/config/crds/kyverno.io_clusteradmissionreports.yaml @@ -78,9 +78,11 @@ spec: blockOwnerDeletion: description: If true, AND if the owner has the "foregroundDeletion" finalizer, then the owner cannot be deleted from the key-value - store until this reference is removed. Defaults to false. To - set this field, a user needs "delete" permission of the owner, - otherwise 422 (Unprocessable Entity) will be returned. + store until this reference is removed. See https://kubernetes.io/docs/concepts/architecture/garbage-collection/#foreground-deletion + for how the garbage collector interacts with this field and + enforces the foreground deletion. Defaults to false. To set + this field, a user needs "delete" permission of the owner, otherwise + 422 (Unprocessable Entity) will be returned. type: boolean controller: description: If true, this reference points to the managing controller. @@ -176,32 +178,33 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty - describing its usage when embedded in APIs. 1. Ignored fields. It - includes many fields which are not generally honored. For - instance, ResourceVersion and FieldPath are both very rarely - valid in actual usage. 2. Invalid usage help. It is impossible - to add specific help for individual usage. In most embedded - usages, there are particular restrictions like, "must refer - only to types A and B" or "UID not honored" or "name must - be restricted". Those cannot be well described when embedded. - 3. Inconsistent validation. Because the usages are different, - the validation rules are different by usage, which makes - it hard for users to predict what will happen. 4. The fields - are both imprecise and overly precise. Kind is not a precise - mapping to a URL. This can produce ambiguity during interpretation - and require a REST mapping. In most cases, the dependency - is on the group,resource tuple and the version of the actual + describing its usage when embedded in APIs. 1. Ignored fields. + \ It includes many fields which are not generally honored. + \ For instance, ResourceVersion and FieldPath are both very + rarely valid in actual usage. 2. Invalid usage help. It + is impossible to add specific help for individual usage. + \ In most embedded usages, there are particular restrictions + like, \"must refer only to types A and B\" or \"UID not + honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. + \ Because the usages are different, the validation rules + are different by usage, which makes it hard for users to + predict what will happen. 4. The fields are both imprecise + and overly precise. Kind is not a precise mapping to a + URL. This can produce ambiguity during interpretation and + require a REST mapping. In most cases, the dependency is + on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates to this - type will affect numerous schemas. Don''t make new APIs - embed an underspecified API type they do not control. Instead - of using this type, create a locally provided and used type - that is well-focused on your reference. For example, ServiceReferences - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n + Instead of using this type, create a locally provided and + used type that is well-focused on your reference. For example, + ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 + ." properties: apiVersion: description: API version of the referent. diff --git a/config/crds/kyverno.io_clusterbackgroundscanreports.yaml b/config/crds/kyverno.io_clusterbackgroundscanreports.yaml index 21926cabb5..5cf4f3054b 100644 --- a/config/crds/kyverno.io_clusterbackgroundscanreports.yaml +++ b/config/crds/kyverno.io_clusterbackgroundscanreports.yaml @@ -143,32 +143,33 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty - describing its usage when embedded in APIs. 1. Ignored fields. It - includes many fields which are not generally honored. For - instance, ResourceVersion and FieldPath are both very rarely - valid in actual usage. 2. Invalid usage help. It is impossible - to add specific help for individual usage. In most embedded - usages, there are particular restrictions like, "must refer - only to types A and B" or "UID not honored" or "name must - be restricted". Those cannot be well described when embedded. - 3. Inconsistent validation. Because the usages are different, - the validation rules are different by usage, which makes - it hard for users to predict what will happen. 4. The fields - are both imprecise and overly precise. Kind is not a precise - mapping to a URL. This can produce ambiguity during interpretation - and require a REST mapping. In most cases, the dependency - is on the group,resource tuple and the version of the actual + describing its usage when embedded in APIs. 1. Ignored fields. + \ It includes many fields which are not generally honored. + \ For instance, ResourceVersion and FieldPath are both very + rarely valid in actual usage. 2. Invalid usage help. It + is impossible to add specific help for individual usage. + \ In most embedded usages, there are particular restrictions + like, \"must refer only to types A and B\" or \"UID not + honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. + \ Because the usages are different, the validation rules + are different by usage, which makes it hard for users to + predict what will happen. 4. The fields are both imprecise + and overly precise. Kind is not a precise mapping to a + URL. This can produce ambiguity during interpretation and + require a REST mapping. In most cases, the dependency is + on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates to this - type will affect numerous schemas. Don''t make new APIs - embed an underspecified API type they do not control. Instead - of using this type, create a locally provided and used type - that is well-focused on your reference. For example, ServiceReferences - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n + Instead of using this type, create a locally provided and + used type that is well-focused on your reference. For example, + ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 + ." properties: apiVersion: description: API version of the referent. diff --git a/config/crds/kyverno.io_clusterpolicies.yaml b/config/crds/kyverno.io_clusterpolicies.yaml index 5a3c9703cb..a4d003eaa4 100644 --- a/config/crds/kyverno.io_clusterpolicies.yaml +++ b/config/crds/kyverno.io_clusterpolicies.yaml @@ -5678,8 +5678,8 @@ spec: description: "Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, - type FooStatus struct{ // Represents the observations of a foo's - current state. // Known .status.conditions.type are: \"Available\", + \n type FooStatus struct{ // Represents the observations of a + foo's current state. // Known .status.conditions.type are: \"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\" @@ -11148,8 +11148,8 @@ spec: description: "Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, - type FooStatus struct{ // Represents the observations of a foo's - current state. // Known .status.conditions.type are: \"Available\", + \n type FooStatus struct{ // Represents the observations of a + foo's current state. // Known .status.conditions.type are: \"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\" diff --git a/config/crds/kyverno.io_policies.yaml b/config/crds/kyverno.io_policies.yaml index 975414e045..60e6961fae 100644 --- a/config/crds/kyverno.io_policies.yaml +++ b/config/crds/kyverno.io_policies.yaml @@ -5680,8 +5680,8 @@ spec: description: "Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, - type FooStatus struct{ // Represents the observations of a foo's - current state. // Known .status.conditions.type are: \"Available\", + \n type FooStatus struct{ // Represents the observations of a + foo's current state. // Known .status.conditions.type are: \"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\" @@ -11151,8 +11151,8 @@ spec: description: "Condition contains details for one aspect of the current state of this API Resource. --- This struct is intended for direct use as an array at the field path .status.conditions. For example, - type FooStatus struct{ // Represents the observations of a foo's - current state. // Known .status.conditions.type are: \"Available\", + \n type FooStatus struct{ // Represents the observations of a + foo's current state. // Known .status.conditions.type are: \"Available\", \"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge // +listType=map // +listMapKey=type Conditions []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\" diff --git a/config/crds/wgpolicyk8s.io_clusterpolicyreports.yaml b/config/crds/wgpolicyk8s.io_clusterpolicyreports.yaml index f00c856125..147e5a29cb 100644 --- a/config/crds/wgpolicyk8s.io_clusterpolicyreports.yaml +++ b/config/crds/wgpolicyk8s.io_clusterpolicyreports.yaml @@ -137,7 +137,7 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information to let + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs. 1. Ignored fields. It includes many @@ -145,23 +145,23 @@ spec: and FieldPath are both very rarely valid in actual usage. 2. Invalid usage help. It is impossible to add specific help for individual usage. In most embedded usages, there are particular - restrictions like, "must refer only to types A and B" or "UID - not honored" or "name must be restricted". Those cannot be well - described when embedded. 3. Inconsistent validation. Because + restrictions like, \"must refer only to types A and B\" or \"UID + not honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will - happen. 4. The fields are both imprecise and overly precise. Kind - is not a precise mapping to a URL. This can produce ambiguity + happen. 4. The fields are both imprecise and overly precise. + \ Kind is not a precise mapping to a URL. This can produce ambiguity during interpretation and require a REST mapping. In most cases, the dependency is on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates - to this type will affect numerous schemas. Don''t make new - APIs embed an underspecified API type they do not control. Instead + to this type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + ." properties: apiVersion: description: API version of the referent. diff --git a/config/crds/wgpolicyk8s.io_policyreports.yaml b/config/crds/wgpolicyk8s.io_policyreports.yaml index 78ddf485fa..064770a9b4 100644 --- a/config/crds/wgpolicyk8s.io_policyreports.yaml +++ b/config/crds/wgpolicyk8s.io_policyreports.yaml @@ -136,7 +136,7 @@ spec: description: Subjects is an optional reference to the checked Kubernetes resources items: - description: 'ObjectReference contains enough information to let + description: "ObjectReference contains enough information to let you inspect or modify the referred object. --- New uses of this type are discouraged because of difficulty describing its usage when embedded in APIs. 1. Ignored fields. It includes many @@ -144,23 +144,23 @@ spec: and FieldPath are both very rarely valid in actual usage. 2. Invalid usage help. It is impossible to add specific help for individual usage. In most embedded usages, there are particular - restrictions like, "must refer only to types A and B" or "UID - not honored" or "name must be restricted". Those cannot be well - described when embedded. 3. Inconsistent validation. Because + restrictions like, \"must refer only to types A and B\" or \"UID + not honored\" or \"name must be restricted\". Those cannot be + well described when embedded. 3. Inconsistent validation. Because the usages are different, the validation rules are different by usage, which makes it hard for users to predict what will - happen. 4. The fields are both imprecise and overly precise. Kind - is not a precise mapping to a URL. This can produce ambiguity + happen. 4. The fields are both imprecise and overly precise. + \ Kind is not a precise mapping to a URL. This can produce ambiguity during interpretation and require a REST mapping. In most cases, the dependency is on the group,resource tuple and the version of the actual struct is irrelevant. 5. We cannot easily change it. Because this type is embedded in many locations, updates - to this type will affect numerous schemas. Don''t make new - APIs embed an underspecified API type they do not control. Instead + to this type will affect numerous schemas. Don't make new APIs + embed an underspecified API type they do not control. \n Instead of using this type, create a locally provided and used type that is well-focused on your reference. For example, ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 - .' + ." properties: apiVersion: description: API version of the referent.