mirrors/kyverno
mirrors/kyverno
1
0
Fork 0
mirror of https://github.com/kyverno/kyverno.git synced 2025-03-30 19:35:06 +00:00
Code Activity

Fix CRD format issue

Browse source 
Signed-off-by: ShutingZhao <shuting@nirmata.com>
This commit is contained in:
ShutingZhao 2022-10-05 18:53:43 +08:00 • committed by shuting
parent d3a18d0c83
commit dd1fe55ec9
8 changed files with 128 additions and 120 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
config/crds/kyverno.io_admissionreports.yaml
View file

@ -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.

45
config/crds/kyverno.io_backgroundscanreports.yaml
View file

@ -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.

53
config/crds/kyverno.io_clusteradmissionreports.yaml
View file

@ -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.

45
config/crds/kyverno.io_clusterbackgroundscanreports.yaml
View file

@ -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.

8
config/crds/kyverno.io_clusterpolicies.yaml
View file

@ -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\"

8
config/crds/kyverno.io_policies.yaml
View file

@ -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\"

18
config/crds/wgpolicyk8s.io_clusterpolicyreports.yaml
View file

@ -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.

18
config/crds/wgpolicyk8s.io_policyreports.yaml
View file

@ -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.