|
|
|
|
@ -1,22 +1,22 @@
|
|
|
|
|
apiVersion: apiextensions.k8s.io/v1
|
|
|
|
|
kind: CustomResourceDefinition
|
|
|
|
|
metadata:
|
|
|
|
|
name: nodeimages.update.edgeless.systems
|
|
|
|
|
name: nodeversions.update.edgeless.systems
|
|
|
|
|
annotations:
|
|
|
|
|
controller-gen.kubebuilder.io/version: v0.9.0
|
|
|
|
|
spec:
|
|
|
|
|
group: update.edgeless.systems
|
|
|
|
|
names:
|
|
|
|
|
kind: NodeImage
|
|
|
|
|
listKind: NodeImageList
|
|
|
|
|
plural: nodeimages
|
|
|
|
|
singular: nodeimage
|
|
|
|
|
kind: NodeVersion
|
|
|
|
|
listKind: NodeVersionList
|
|
|
|
|
plural: nodeversions
|
|
|
|
|
singular: nodeversion
|
|
|
|
|
scope: Cluster
|
|
|
|
|
versions:
|
|
|
|
|
- name: v1alpha1
|
|
|
|
|
schema:
|
|
|
|
|
openAPIV3Schema:
|
|
|
|
|
description: NodeImage is the Schema for the nodeimages API.
|
|
|
|
|
description: NodeVersion is the Schema for the nodeimages API.
|
|
|
|
|
properties:
|
|
|
|
|
apiVersion:
|
|
|
|
|
description: 'APIVersion defines the versioned schema of this representation
|
|
|
|
|
@ -31,7 +31,7 @@ spec:
|
|
|
|
|
metadata:
|
|
|
|
|
type: object
|
|
|
|
|
spec:
|
|
|
|
|
description: NodeImageSpec defines the desired state of NodeImage.
|
|
|
|
|
description: NodeVersionSpec defines the desired state of NodeImage.
|
|
|
|
|
properties:
|
|
|
|
|
image:
|
|
|
|
|
description: ImageReference is the image to use for all nodes.
|
|
|
|
|
@ -40,9 +40,13 @@ spec:
|
|
|
|
|
description: ImageVersion is the CSP independent version of the image
|
|
|
|
|
to use for all nodes.
|
|
|
|
|
type: string
|
|
|
|
|
kubernetesComponentsReference:
|
|
|
|
|
description: KubernetesComponentsReference is a reference to the ConfigMap
|
|
|
|
|
containing the Kubernetes components to use for all nodes.
|
|
|
|
|
type: string
|
|
|
|
|
type: object
|
|
|
|
|
status:
|
|
|
|
|
description: NodeImageStatus defines the observed state of NodeImage.
|
|
|
|
|
description: NodeVersionStatus defines the observed state of NodeImage.
|
|
|
|
|
properties:
|
|
|
|
|
budget:
|
|
|
|
|
description: Budget is the amount of extra nodes that can be created
|
|
|
|
|
@ -56,8 +60,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,
|
|
|
|
|
\n 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\"
|
|
|
|
|
@ -71,8 +75,8 @@ spec:
|
|
|
|
|
format: date-time
|
|
|
|
|
type: string
|
|
|
|
|
message:
|
|
|
|
|
description: message is a human readable message indicating details
|
|
|
|
|
about the transition. This may be an empty string.
|
|
|
|
|
description: message is a human readable message indicating
|
|
|
|
|
details about the transition. This may be an empty string.
|
|
|
|
|
maxLength: 32768
|
|
|
|
|
type: string
|
|
|
|
|
observedGeneration:
|
|
|
|
|
@ -86,11 +90,11 @@ spec:
|
|
|
|
|
type: integer
|
|
|
|
|
reason:
|
|
|
|
|
description: reason contains a programmatic identifier indicating
|
|
|
|
|
the reason for the condition's last transition. Producers of
|
|
|
|
|
specific condition types may define expected values and meanings
|
|
|
|
|
for this field, and whether the values are considered a guaranteed
|
|
|
|
|
API. The value should be a CamelCase string. This field may
|
|
|
|
|
not be empty.
|
|
|
|
|
the reason for the condition's last transition. Producers
|
|
|
|
|
of specific condition types may define expected values and
|
|
|
|
|
meanings for this field, and whether the values are considered
|
|
|
|
|
a guaranteed API. The value should be a CamelCase string.
|
|
|
|
|
This field may not be empty.
|
|
|
|
|
maxLength: 1024
|
|
|
|
|
minLength: 1
|
|
|
|
|
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
|
|
|
|
|
@ -120,32 +124,33 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
donors:
|
|
|
|
|
description: Donors is a list of outdated nodes that donate labels to
|
|
|
|
|
heirs.
|
|
|
|
|
description: Donors is a list of outdated nodes that donate labels
|
|
|
|
|
to heirs.
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -183,32 +188,33 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
heirs:
|
|
|
|
|
description: Heirs is a list of nodes using the latest image that still
|
|
|
|
|
need to inherit labels from donors.
|
|
|
|
|
description: Heirs is a list of nodes using the latest image that
|
|
|
|
|
still need to inherit labels from donors.
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -246,33 +252,34 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
invalid:
|
|
|
|
|
description: Invalid is a list of invalid nodes (nodes that cannot be
|
|
|
|
|
processed by the operator due to missing information or transient
|
|
|
|
|
description: Invalid is a list of invalid nodes (nodes that cannot
|
|
|
|
|
be processed by the operator due to missing information or transient
|
|
|
|
|
faults).
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -310,31 +317,33 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
mints:
|
|
|
|
|
description: Mints is a list of up to date nodes that will become heirs.
|
|
|
|
|
description: Mints is a list of up to date nodes that will become
|
|
|
|
|
heirs.
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -372,32 +381,33 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
obsolete:
|
|
|
|
|
description: Obsolete is a list of obsolete nodes (nodes that have been
|
|
|
|
|
created by the operator but are no longer needed).
|
|
|
|
|
description: Obsolete is a list of obsolete nodes (nodes that have
|
|
|
|
|
been created by the operator but are no longer needed).
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -438,29 +448,30 @@ spec:
|
|
|
|
|
description: Outdated is a list of nodes that are using an outdated
|
|
|
|
|
image.
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -501,29 +512,30 @@ spec:
|
|
|
|
|
description: Pending is a list of pending nodes (joining or leaving
|
|
|
|
|
the cluster).
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -561,32 +573,33 @@ spec:
|
|
|
|
|
type: object
|
|
|
|
|
type: array
|
|
|
|
|
upToDate:
|
|
|
|
|
description: UpToDate is a list of nodes that are using the latest image
|
|
|
|
|
and labels.
|
|
|
|
|
description: UpToDate is a list of nodes that are using the latest
|
|
|
|
|
image and labels.
|
|
|
|
|
items:
|
|
|
|
|
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 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. \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
|
|
|
|
|
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 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. \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:
|
|
|
|
|
@ -632,9 +645,3 @@ spec:
|
|
|
|
|
storage: true
|
|
|
|
|
subresources:
|
|
|
|
|
status: {}
|
|
|
|
|
status:
|
|
|
|
|
acceptedNames:
|
|
|
|
|
kind: ""
|
|
|
|
|
plural: ""
|
|
|
|
|
conditions: []
|
|
|
|
|
storedVersions: []
|
|
|
|
|
|
3u13r