mirror of
https://github.com/kubevela/kubevela.git
synced 2026-02-23 22:33:58 +00:00
Compare commits
14 Commits
v1.6.6
...
release-1.
| Author | SHA1 | Date | |
|---|---|---|---|
|
b7683ebdfe | ||
|
4bbd6c3827 | ||
|
4bc847b19f | ||
|
6553a90dd4 | ||
|
|
51d536ed12 | ||
|
ac721a1bb1 | ||
|
|
468452df16 | ||
|
|
c5493237f9 | ||
|
|
b11eb845b2 | ||
|
|
b12968c2ae | ||
|
|
d8d0c91c59 | ||
|
|
5f6209e8de | ||
|
|
a198fa5f9a | ||
|
|
f01639e175 |
2
.github/workflows/apiserver-test.yaml
vendored
2
.github/workflows/apiserver-test.yaml
vendored
@@ -78,6 +78,8 @@ jobs:
|
||||
|
||||
- name: Install ginkgo
|
||||
run: |
|
||||
sudo sed -i 's/azure\.//' /etc/apt/sources.list
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y golang-ginkgo-dev
|
||||
|
||||
- name: Start MongoDB
|
||||
|
||||
2
.github/workflows/unit-test.yml
vendored
2
.github/workflows/unit-test.yml
vendored
@@ -58,6 +58,8 @@ jobs:
|
||||
|
||||
- name: Install ginkgo
|
||||
run: |
|
||||
sudo sed -i 's/azure\.//' /etc/apt/sources.list
|
||||
sudo apt-get update
|
||||
sudo apt-get install -y golang-ginkgo-dev
|
||||
|
||||
- name: Setup K3d
|
||||
|
||||
@@ -333,7 +333,8 @@ type WorkflowStatus struct {
|
||||
Steps []workflowv1alpha1.WorkflowStepStatus `json:"steps,omitempty"`
|
||||
|
||||
StartTime metav1.Time `json:"startTime,omitempty"`
|
||||
EndTime metav1.Time `json:"endTime,omitempty"`
|
||||
// +nullable
|
||||
EndTime metav1.Time `json:"endTime,omitempty"`
|
||||
}
|
||||
|
||||
// DefinitionType describes the type of DefinitionRevision.
|
||||
|
||||
@@ -499,7 +499,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -508,25 +508,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -659,7 +659,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -668,28 +668,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -776,7 +776,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -785,11 +785,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -798,13 +798,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -844,6 +844,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -2414,7 +2415,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -2423,25 +2424,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2574,7 +2575,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -2583,28 +2584,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2691,7 +2692,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -2700,11 +2701,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -2713,13 +2714,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2759,6 +2760,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -4752,31 +4754,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -4813,6 +4816,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -450,31 +450,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -601,7 +601,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -610,24 +610,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -707,31 +707,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -768,6 +769,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -1212,31 +1214,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1363,7 +1365,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -1372,24 +1374,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1469,31 +1471,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1530,6 +1533,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -59,7 +59,7 @@ spec:
|
||||
type: string
|
||||
traits:
|
||||
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
|
||||
@@ -69,26 +69,26 @@ spec:
|
||||
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
|
||||
.'
|
||||
\"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:
|
||||
description: API version of the referent.
|
||||
@@ -129,7 +129,7 @@ spec:
|
||||
type: object
|
||||
type: array
|
||||
workload:
|
||||
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
|
||||
@@ -138,11 +138,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -151,13 +151,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -213,31 +213,31 @@ spec:
|
||||
description: WorkloadReferences to the workloads that are in this
|
||||
scope.
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -305,7 +305,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
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
|
||||
@@ -314,11 +314,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -327,13 +327,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -461,7 +461,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
description: 'ObjectReference contains enough information to
|
||||
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
|
||||
@@ -469,24 +469,25 @@ spec:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
|
||||
@@ -499,7 +499,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -508,25 +508,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -659,7 +659,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -668,28 +668,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -776,7 +776,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -785,11 +785,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -798,13 +798,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -844,6 +844,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -2414,7 +2415,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -2423,25 +2424,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2574,7 +2575,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -2583,28 +2584,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2691,7 +2692,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -2700,11 +2701,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -2713,13 +2714,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2759,6 +2760,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -4752,31 +4754,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -4813,6 +4816,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -450,31 +450,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -601,7 +601,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -610,24 +610,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -707,31 +707,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -768,6 +769,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -1212,31 +1214,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1363,7 +1365,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -1372,24 +1374,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1469,31 +1471,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1530,6 +1533,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -59,7 +59,7 @@ spec:
|
||||
type: string
|
||||
traits:
|
||||
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
|
||||
@@ -69,26 +69,26 @@ spec:
|
||||
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
|
||||
.'
|
||||
\"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:
|
||||
description: API version of the referent.
|
||||
@@ -129,7 +129,7 @@ spec:
|
||||
type: object
|
||||
type: array
|
||||
workload:
|
||||
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
|
||||
@@ -138,11 +138,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -151,13 +151,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -213,31 +213,31 @@ spec:
|
||||
description: WorkloadReferences to the workloads that are in this
|
||||
scope.
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -305,7 +305,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
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
|
||||
@@ -314,11 +314,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -327,13 +327,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -461,7 +461,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
description: 'ObjectReference contains enough information to
|
||||
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
|
||||
@@ -469,24 +469,25 @@ spec:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
|
||||
@@ -74,6 +74,12 @@ var _ = Describe("Addon Test", func() {
|
||||
Expect(output).To(ContainSubstring("enabled successfully."))
|
||||
})
|
||||
|
||||
It("Enable addon with specified registry ", func() {
|
||||
output, err := e2e.LongTimeExec("vela addon enable KubeVela/test-addon", 300*time.Second)
|
||||
Expect(err).NotTo(HaveOccurred())
|
||||
Expect(output).To(ContainSubstring("enabled successfully."))
|
||||
})
|
||||
|
||||
It("Disable addon test-addon", func() {
|
||||
output, err := e2e.LongTimeExec("vela addon disable test-addon", 600*time.Second)
|
||||
Expect(err).NotTo(HaveOccurred())
|
||||
|
||||
156
go.mod
156
go.mod
@@ -19,7 +19,7 @@ require (
|
||||
github.com/briandowns/spinner v1.11.1
|
||||
github.com/chartmuseum/helm-push v0.10.2
|
||||
github.com/cloudtty/cloudtty v0.2.0
|
||||
github.com/containerd/containerd v1.5.16
|
||||
github.com/containerd/containerd v1.6.6
|
||||
github.com/coreos/go-oidc v2.1.0+incompatible
|
||||
github.com/coreos/prometheus-operator v0.41.1
|
||||
github.com/crossplane/crossplane-runtime v0.14.1-0.20210722005935-0b469fcc77cd
|
||||
@@ -28,7 +28,7 @@ require (
|
||||
github.com/deckarep/golang-set v1.7.1
|
||||
github.com/emicklei/go-restful-openapi/v2 v2.3.0
|
||||
github.com/emicklei/go-restful/v3 v3.8.0
|
||||
github.com/evanphx/json-patch v4.12.0+incompatible
|
||||
github.com/evanphx/json-patch v5.6.0+incompatible
|
||||
github.com/fatih/camelcase v1.0.0
|
||||
github.com/fatih/color v1.13.0
|
||||
github.com/fluxcd/helm-controller/api v0.21.0
|
||||
@@ -38,31 +38,31 @@ require (
|
||||
github.com/gertd/go-pluralize v0.1.7
|
||||
github.com/getkin/kin-openapi v0.94.0
|
||||
github.com/ghodss/yaml v1.0.0
|
||||
github.com/go-logr/logr v1.2.2
|
||||
github.com/go-logr/logr v1.2.3
|
||||
github.com/go-openapi/spec v0.19.8
|
||||
github.com/go-playground/validator/v10 v10.9.0
|
||||
github.com/go-resty/resty/v2 v2.7.0
|
||||
github.com/golang/mock v1.6.0
|
||||
github.com/google/go-cmp v0.5.8
|
||||
github.com/google/go-cmp v0.5.9
|
||||
github.com/google/go-containerregistry v0.9.0
|
||||
github.com/google/go-github/v32 v32.1.0
|
||||
github.com/google/uuid v1.3.0
|
||||
github.com/gorilla/websocket v1.4.2
|
||||
github.com/gosuri/uilive v0.0.4
|
||||
github.com/gosuri/uitable v0.0.4
|
||||
github.com/hashicorp/go-version v1.3.0
|
||||
github.com/hashicorp/go-version v1.6.0
|
||||
github.com/hashicorp/hcl/v2 v2.9.1
|
||||
github.com/hinshun/vt10x v0.0.0-20180616224451-1954e6464174
|
||||
github.com/imdario/mergo v0.3.12
|
||||
github.com/klauspost/compress v1.15.11
|
||||
github.com/klauspost/compress v1.15.12
|
||||
github.com/koding/websocketproxy v0.0.0-20181220232114-7ed82d81a28c
|
||||
github.com/kubevela/pkg v0.0.0-20221024115939-a103acee6db2
|
||||
github.com/kubevela/pkg v0.0.0-20230105054759-263dc191bf51
|
||||
github.com/kubevela/prism v1.5.1-0.20220915071949-6bf3ad33f84f
|
||||
github.com/kubevela/workflow v0.3.4-0.20230103040208-bca032d481ed
|
||||
github.com/kubevela/workflow v0.3.6
|
||||
github.com/kyokomi/emoji v2.2.4+incompatible
|
||||
github.com/mitchellh/hashstructure/v2 v2.0.1
|
||||
github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd
|
||||
github.com/oam-dev/cluster-gateway v1.4.0
|
||||
github.com/oam-dev/cluster-gateway v1.7.0-alpha.1
|
||||
github.com/oam-dev/cluster-register v1.0.4-0.20220928064144-5f76a9d7ca8c
|
||||
github.com/oam-dev/terraform-config-inspect v0.0.0-20210418082552-fc72d929aa28
|
||||
github.com/oam-dev/terraform-controller v0.7.0
|
||||
@@ -76,10 +76,10 @@ require (
|
||||
github.com/rivo/tview v0.0.0-20220709181631-73bf2902b59a
|
||||
github.com/robfig/cron/v3 v3.0.1
|
||||
github.com/rogpeppe/go-internal v1.9.0
|
||||
github.com/sirupsen/logrus v1.8.1
|
||||
github.com/spf13/cobra v1.4.0
|
||||
github.com/sirupsen/logrus v1.9.0
|
||||
github.com/spf13/cobra v1.6.0
|
||||
github.com/spf13/pflag v1.0.5
|
||||
github.com/stretchr/testify v1.7.1
|
||||
github.com/stretchr/testify v1.8.0
|
||||
github.com/tidwall/gjson v1.9.3
|
||||
github.com/wercker/stern v0.0.0-20190705090245-4fa46dd6987f
|
||||
github.com/wonderflow/cert-manager-api v1.0.4-0.20210304051430-e08aa76f6c5f
|
||||
@@ -94,23 +94,23 @@ require (
|
||||
gopkg.in/src-d/go-git.v4 v4.13.1
|
||||
gopkg.in/yaml.v3 v3.0.1
|
||||
gotest.tools v2.2.0+incompatible
|
||||
helm.sh/helm/v3 v3.7.2
|
||||
helm.sh/helm/v3 v3.10.3
|
||||
istio.io/client-go v1.13.4
|
||||
k8s.io/api v0.23.6
|
||||
k8s.io/apiextensions-apiserver v0.23.6
|
||||
k8s.io/apimachinery v0.23.6
|
||||
k8s.io/apiserver v0.23.6
|
||||
k8s.io/cli-runtime v0.23.6
|
||||
k8s.io/client-go v0.23.6
|
||||
k8s.io/component-base v0.23.6
|
||||
k8s.io/api v0.25.3
|
||||
k8s.io/apiextensions-apiserver v0.25.2
|
||||
k8s.io/apimachinery v0.25.3
|
||||
k8s.io/apiserver v0.25.3
|
||||
k8s.io/cli-runtime v0.25.2
|
||||
k8s.io/client-go v0.25.3
|
||||
k8s.io/component-base v0.25.3
|
||||
k8s.io/helm v2.17.0+incompatible
|
||||
k8s.io/klog/v2 v2.60.1
|
||||
k8s.io/kube-aggregator v0.23.0
|
||||
k8s.io/kubectl v0.23.6
|
||||
k8s.io/metrics v0.23.6
|
||||
k8s.io/utils v0.0.0-20220210201930-3a6ce19ff2f9
|
||||
k8s.io/klog/v2 v2.70.1
|
||||
k8s.io/kube-aggregator v0.25.3
|
||||
k8s.io/kubectl v0.25.2
|
||||
k8s.io/metrics v0.25.2
|
||||
k8s.io/utils v0.0.0-20220728103510-ee6ede2d64ed
|
||||
open-cluster-management.io/api v0.7.0
|
||||
sigs.k8s.io/controller-runtime v0.11.2
|
||||
sigs.k8s.io/controller-runtime v0.12.3
|
||||
sigs.k8s.io/controller-tools v0.6.2
|
||||
sigs.k8s.io/gateway-api v0.4.3
|
||||
sigs.k8s.io/kind v0.9.0
|
||||
@@ -120,20 +120,20 @@ require (
|
||||
require (
|
||||
github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1 // indirect
|
||||
github.com/Azure/go-autorest v14.2.0+incompatible // indirect
|
||||
github.com/Azure/go-autorest/autorest v0.11.18 // indirect
|
||||
github.com/Azure/go-autorest/autorest/adal v0.9.13 // indirect
|
||||
github.com/Azure/go-autorest/autorest v0.11.27 // indirect
|
||||
github.com/Azure/go-autorest/autorest/adal v0.9.20 // indirect
|
||||
github.com/Azure/go-autorest/autorest/date v0.3.0 // indirect
|
||||
github.com/Azure/go-autorest/logger v0.2.1 // indirect
|
||||
github.com/Azure/go-autorest/tracing v0.6.0 // indirect
|
||||
github.com/BurntSushi/toml v0.4.1 // indirect
|
||||
github.com/MakeNowJust/heredoc v0.0.0-20170808103936-bb23615498cd // indirect
|
||||
github.com/BurntSushi/toml v1.2.1 // indirect
|
||||
github.com/MakeNowJust/heredoc v1.0.0 // indirect
|
||||
github.com/Masterminds/goutils v1.1.1 // indirect
|
||||
github.com/Masterminds/semver v1.5.0 // indirect
|
||||
github.com/Masterminds/sprig v2.22.0+incompatible // indirect
|
||||
github.com/Masterminds/sprig/v3 v3.2.2 // indirect
|
||||
github.com/Masterminds/squirrel v1.5.2 // indirect
|
||||
github.com/Masterminds/squirrel v1.5.3 // indirect
|
||||
github.com/Microsoft/go-winio v0.5.2 // indirect
|
||||
github.com/Microsoft/hcsshim v0.8.24 // indirect
|
||||
github.com/Microsoft/hcsshim v0.9.3 // indirect
|
||||
github.com/NYTimes/gziphandler v1.1.1 // indirect
|
||||
github.com/PuerkitoBio/purell v1.1.1 // indirect
|
||||
github.com/PuerkitoBio/urlesc v0.0.0-20170810143723-de5bf2ad4578 // indirect
|
||||
@@ -152,10 +152,10 @@ require (
|
||||
github.com/asaskevich/govalidator v0.0.0-20200428143746-21a406dcc535 // indirect
|
||||
github.com/aws/aws-sdk-go v1.36.30 // indirect
|
||||
github.com/beorn7/perks v1.0.1 // indirect
|
||||
github.com/blang/semver v3.5.1+incompatible // indirect
|
||||
github.com/blang/semver/v4 v4.0.0 // indirect
|
||||
github.com/buger/jsonparser v1.1.1 // indirect
|
||||
github.com/cespare/xxhash/v2 v2.1.2 // indirect
|
||||
github.com/chai2010/gettext-go v0.0.0-20160711120539-c6fed771bfd5 // indirect
|
||||
github.com/chai2010/gettext-go v1.0.2 // indirect
|
||||
github.com/clbanning/mxj/v2 v2.5.5 // indirect
|
||||
github.com/cockroachdb/apd/v2 v2.0.2 // indirect
|
||||
github.com/containerd/continuity v0.3.0 // indirect
|
||||
@@ -164,14 +164,13 @@ require (
|
||||
github.com/cpuguy83/go-md2man/v2 v2.0.2 // indirect
|
||||
github.com/creack/pty v1.1.11 // indirect
|
||||
github.com/cyphar/filepath-securejoin v0.2.3 // indirect
|
||||
github.com/docker/cli v20.10.16+incompatible // indirect
|
||||
github.com/docker/cli v20.10.17+incompatible // indirect
|
||||
github.com/docker/distribution v2.8.1+incompatible // indirect
|
||||
github.com/docker/docker v20.10.16+incompatible // indirect
|
||||
github.com/docker/docker v20.10.17+incompatible // indirect
|
||||
github.com/docker/docker-credential-helpers v0.6.4 // indirect
|
||||
github.com/docker/go-connections v0.4.0 // indirect
|
||||
github.com/docker/go-metrics v0.0.1 // indirect
|
||||
github.com/docker/go-units v0.4.0 // indirect
|
||||
github.com/emicklei/go-restful v2.9.5+incompatible // indirect
|
||||
github.com/emicklei/proto v1.10.0 // indirect
|
||||
github.com/emirpasic/gods v1.12.0 // indirect
|
||||
github.com/evanphx/json-patch/v5 v5.1.0 // indirect
|
||||
@@ -181,11 +180,12 @@ require (
|
||||
github.com/fluxcd/pkg/apis/acl v0.0.3 // indirect
|
||||
github.com/fluxcd/pkg/apis/kustomize v0.3.3 // indirect
|
||||
github.com/fluxcd/pkg/apis/meta v0.13.0 // indirect
|
||||
github.com/fsnotify/fsnotify v1.5.1 // indirect
|
||||
github.com/fsnotify/fsnotify v1.5.4 // indirect
|
||||
github.com/fvbommel/sortorder v1.0.1 // indirect
|
||||
github.com/gdamore/encoding v1.0.0 // indirect
|
||||
github.com/go-errors/errors v1.0.1 // indirect
|
||||
github.com/go-logr/zapr v1.2.0 // indirect
|
||||
github.com/go-gorp/gorp/v3 v3.0.2 // indirect
|
||||
github.com/go-logr/zapr v1.2.3 // indirect
|
||||
github.com/go-openapi/jsonpointer v0.19.5 // indirect
|
||||
github.com/go-openapi/jsonreference v0.19.5 // indirect
|
||||
github.com/go-openapi/swag v0.19.14 // indirect
|
||||
@@ -195,25 +195,26 @@ require (
|
||||
github.com/gobuffalo/flect v0.2.3 // indirect
|
||||
github.com/gobwas/glob v0.2.3 // indirect
|
||||
github.com/gogo/protobuf v1.3.2 // indirect
|
||||
github.com/golang-jwt/jwt/v4 v4.2.0 // indirect
|
||||
github.com/golang/glog v1.0.0 // indirect
|
||||
github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
|
||||
github.com/golang/protobuf v1.5.2 // indirect
|
||||
github.com/golang/snappy v0.0.3 // indirect
|
||||
github.com/google/btree v1.0.1 // indirect
|
||||
github.com/google/gnostic v0.5.7-v3refs // indirect
|
||||
github.com/google/go-querystring v1.1.0 // indirect
|
||||
github.com/google/gofuzz v1.2.0 // indirect
|
||||
github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510 // indirect
|
||||
github.com/googleapis/gnostic v0.5.5 // indirect
|
||||
github.com/gorilla/mux v1.8.0 // indirect
|
||||
github.com/gregjones/httpcache v0.0.0-20190611155906-901d90724c79 // indirect
|
||||
github.com/grpc-ecosystem/go-grpc-prometheus v1.2.0 // indirect
|
||||
github.com/grpc-ecosystem/grpc-gateway v1.16.0 // indirect
|
||||
github.com/hashicorp/hcl v1.0.0 // indirect
|
||||
github.com/huandu/xstrings v1.3.2 // indirect
|
||||
github.com/inconshreveable/mousetrap v1.0.0 // indirect
|
||||
github.com/inconshreveable/mousetrap v1.0.1 // indirect
|
||||
github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99 // indirect
|
||||
github.com/jmespath/go-jmespath v0.4.0 // indirect
|
||||
github.com/jmoiron/sqlx v1.3.1 // indirect
|
||||
github.com/jmoiron/sqlx v1.3.5 // indirect
|
||||
github.com/josharian/intern v1.0.0 // indirect
|
||||
github.com/json-iterator/go v1.1.12 // indirect
|
||||
github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51 // indirect
|
||||
@@ -223,12 +224,12 @@ require (
|
||||
github.com/lann/builder v0.0.0-20180802200727-47ae307949d0 // indirect
|
||||
github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 // indirect
|
||||
github.com/leodido/go-urn v1.2.1 // indirect
|
||||
github.com/lib/pq v1.10.3 // indirect
|
||||
github.com/lib/pq v1.10.6 // indirect
|
||||
github.com/liggitt/tabwriter v0.0.0-20181228230101-89fcab3d43de // indirect
|
||||
github.com/lucasb-eyer/go-colorful v1.2.0 // indirect
|
||||
github.com/mailru/easyjson v0.7.6 // indirect
|
||||
github.com/mattn/go-colorable v0.1.11 // indirect
|
||||
github.com/mattn/go-isatty v0.0.14 // indirect
|
||||
github.com/mattn/go-colorable v0.1.13 // indirect
|
||||
github.com/mattn/go-isatty v0.0.16 // indirect
|
||||
github.com/mattn/go-runewidth v0.0.13 // indirect
|
||||
github.com/matttproud/golang_protobuf_extensions v1.0.4 // indirect
|
||||
github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b // indirect
|
||||
@@ -238,7 +239,7 @@ require (
|
||||
github.com/mitchellh/reflectwalk v1.0.2 // indirect
|
||||
github.com/moby/locker v1.0.1 // indirect
|
||||
github.com/moby/spdystream v0.2.0 // indirect
|
||||
github.com/moby/term v0.0.0-20210610120745-9d4ed1856297 // indirect
|
||||
github.com/moby/term v0.0.0-20210619224110-3f7ff695adc6 // indirect
|
||||
github.com/modern-go/reflect2 v1.0.2 // indirect
|
||||
github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 // indirect
|
||||
github.com/morikuni/aec v1.0.0 // indirect
|
||||
@@ -248,21 +249,21 @@ require (
|
||||
github.com/nxadm/tail v1.4.8 // indirect
|
||||
github.com/opencontainers/go-digest v1.0.0 // indirect
|
||||
github.com/opencontainers/image-spec v1.0.3-0.20220114050600-8b9d41f48198 // indirect
|
||||
github.com/openshift/library-go v0.0.0-20220112153822-ac82336bd076 // indirect
|
||||
github.com/openshift/library-go v0.0.0-20221111030555-73ed40c0a938 // indirect
|
||||
github.com/peterbourgon/diskv v2.0.1+incompatible // indirect
|
||||
github.com/pmezard/go-difflib v1.0.0 // indirect
|
||||
github.com/pquerna/cachecontrol v0.0.0-20171018203845-0dec1b30a021 // indirect
|
||||
github.com/pquerna/cachecontrol v0.1.0 // indirect
|
||||
github.com/prometheus/common v0.32.1 // indirect
|
||||
github.com/prometheus/procfs v0.7.3 // indirect
|
||||
github.com/protocolbuffers/txtpbfmt v0.0.0-20220428173112-74888fd59c2b // indirect
|
||||
github.com/rivo/uniseg v0.2.0 // indirect
|
||||
github.com/rubenv/sql-migrate v0.0.0-20210614095031-55d5740dbbcc // indirect
|
||||
github.com/rubenv/sql-migrate v1.1.2 // indirect
|
||||
github.com/russross/blackfriday v1.6.0 // indirect
|
||||
github.com/russross/blackfriday/v2 v2.1.0 // indirect
|
||||
github.com/sergi/go-diff v1.1.0 // indirect
|
||||
github.com/shopspring/decimal v1.2.0 // indirect
|
||||
github.com/spf13/afero v1.8.0 // indirect
|
||||
github.com/spf13/cast v1.4.1 // indirect
|
||||
github.com/spf13/afero v1.8.2 // indirect
|
||||
github.com/spf13/cast v1.5.0 // indirect
|
||||
github.com/src-d/gcfg v1.4.0 // indirect
|
||||
github.com/tidwall/match v1.1.1 // indirect
|
||||
github.com/tidwall/pretty v1.2.0 // indirect
|
||||
@@ -275,38 +276,37 @@ require (
|
||||
github.com/xeipuuv/gojsonschema v1.2.0 // indirect
|
||||
github.com/youmark/pkcs8 v0.0.0-20181117223130-1be2e3e5546d // indirect
|
||||
github.com/zclconf/go-cty v1.8.0 // indirect
|
||||
go.etcd.io/etcd/api/v3 v3.5.0 // indirect
|
||||
go.etcd.io/etcd/client/pkg/v3 v3.5.0 // indirect
|
||||
go.etcd.io/etcd/client/v3 v3.5.0 // indirect
|
||||
go.etcd.io/etcd/api/v3 v3.5.4 // indirect
|
||||
go.etcd.io/etcd/client/pkg/v3 v3.5.4 // indirect
|
||||
go.etcd.io/etcd/client/v3 v3.5.4 // indirect
|
||||
go.opentelemetry.io/contrib v0.20.0 // indirect
|
||||
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.20.0 // indirect
|
||||
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.28.0 // indirect
|
||||
go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel v1.3.0 // indirect
|
||||
go.opentelemetry.io/otel/exporters/otlp v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel/metric v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel/sdk v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel/sdk v1.3.0 // indirect
|
||||
go.opentelemetry.io/otel/sdk/export/metric v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel/sdk/metric v0.20.0 // indirect
|
||||
go.opentelemetry.io/otel/trace v0.20.0 // indirect
|
||||
go.opentelemetry.io/proto/otlp v0.7.0 // indirect
|
||||
go.opentelemetry.io/otel/trace v1.3.0 // indirect
|
||||
go.opentelemetry.io/proto/otlp v0.11.0 // indirect
|
||||
go.starlark.net v0.0.0-20200306205701-8dd3e2ee1dd5 // indirect
|
||||
go.uber.org/atomic v1.9.0 // indirect
|
||||
go.uber.org/multierr v1.7.0 // indirect
|
||||
go.uber.org/zap v1.21.0 // indirect
|
||||
golang.org/x/mod v0.6.0-dev.0.20220818022119-ed83ed61efb9 // indirect
|
||||
golang.org/x/net v0.1.0 // indirect
|
||||
golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4 // indirect
|
||||
golang.org/x/mod v0.6.0 // indirect
|
||||
golang.org/x/net v0.1.1-0.20221104162952-702349b0e862 // indirect
|
||||
golang.org/x/sync v0.0.0-20220819030929-7fc1605a5dde // indirect
|
||||
golang.org/x/sys v0.1.0 // indirect
|
||||
golang.org/x/time v0.0.0-20220922220347-f3bd1da661af // indirect
|
||||
golang.org/x/tools v0.1.12 // indirect
|
||||
golang.org/x/tools v0.2.0 // indirect
|
||||
google.golang.org/appengine v1.6.7 // indirect
|
||||
google.golang.org/grpc v1.48.0 // indirect
|
||||
google.golang.org/protobuf v1.28.0 // indirect
|
||||
gopkg.in/alexcesaro/quotedprintable.v3 v3.0.0-20150716171945-2caba252f4dc // indirect
|
||||
gopkg.in/gomail.v2 v2.0.0-20160411212932-81ebce5c23df // indirect
|
||||
gopkg.in/gorp.v1 v1.7.2 // indirect
|
||||
gopkg.in/inf.v0 v0.9.1 // indirect
|
||||
gopkg.in/ini.v1 v1.66.2 // indirect
|
||||
gopkg.in/ini.v1 v1.67.0 // indirect
|
||||
gopkg.in/natefinch/lumberjack.v2 v2.0.0 // indirect
|
||||
gopkg.in/square/go-jose.v2 v2.5.1 // indirect
|
||||
gopkg.in/src-d/go-billy.v4 v4.3.2 // indirect
|
||||
@@ -315,15 +315,15 @@ require (
|
||||
istio.io/api v0.0.0-20220512212136-561ffec82582 // indirect
|
||||
istio.io/gogo-genproto v0.0.0-20211208193508-5ab4acc9eb1e // indirect
|
||||
k8s.io/klog v1.0.0 // indirect
|
||||
k8s.io/kube-openapi v0.0.0-20211115234752-e816edb12b65 // indirect
|
||||
oras.land/oras-go v0.4.0 // indirect
|
||||
k8s.io/kube-openapi v0.0.0-20220803162953-67bda5d908f1 // indirect
|
||||
oras.land/oras-go v1.2.0 // indirect
|
||||
sigs.k8s.io/apiserver-network-proxy v0.0.30 // indirect
|
||||
sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.30 // indirect
|
||||
sigs.k8s.io/apiserver-runtime v1.1.1 // indirect
|
||||
sigs.k8s.io/json v0.0.0-20211208200746-9f7c6b3444d2 // indirect
|
||||
sigs.k8s.io/kustomize/api v0.10.1 // indirect
|
||||
sigs.k8s.io/kustomize/kyaml v0.13.0 // indirect
|
||||
sigs.k8s.io/structured-merge-diff/v4 v4.2.1 // indirect
|
||||
sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.33 // indirect
|
||||
sigs.k8s.io/apiserver-runtime v1.1.2-0.20221102045245-fb656940062f // indirect
|
||||
sigs.k8s.io/json v0.0.0-20220713155537-f223a00ba0e2 // indirect
|
||||
sigs.k8s.io/kustomize/api v0.12.1 // indirect
|
||||
sigs.k8s.io/kustomize/kyaml v0.13.9 // indirect
|
||||
sigs.k8s.io/structured-merge-diff/v4 v4.2.3 // indirect
|
||||
)
|
||||
|
||||
require (
|
||||
@@ -331,11 +331,11 @@ require (
|
||||
github.com/hashicorp/go-cleanhttp v0.5.2 // indirect
|
||||
github.com/hashicorp/go-retryablehttp v0.7.0 // indirect
|
||||
github.com/kevinburke/ssh_config v0.0.0-20201106050909-4977a11b4351 // indirect
|
||||
github.com/magiconair/properties v1.8.5
|
||||
github.com/magiconair/properties v1.8.6
|
||||
github.com/nacos-group/nacos-sdk-go/v2 v2.1.0
|
||||
github.com/opencontainers/runc v1.1.3 // indirect
|
||||
github.com/openkruise/rollouts v0.1.1-0.20220622054609-149e5a48da5e
|
||||
github.com/pelletier/go-toml v1.9.4
|
||||
github.com/pelletier/go-toml v1.9.5
|
||||
github.com/xanzy/ssh-agent v0.3.0 // indirect
|
||||
google.golang.org/genproto v0.0.0-20220628213854-d9e0b6570c03 // indirect
|
||||
gopkg.in/yaml.v2 v2.4.0
|
||||
@@ -346,5 +346,11 @@ replace (
|
||||
github.com/docker/cli => github.com/docker/cli v20.10.9+incompatible
|
||||
github.com/docker/docker => github.com/moby/moby v17.12.0-ce-rc1.0.20200618181300-9dc6525e6118+incompatible
|
||||
github.com/wercker/stern => github.com/oam-dev/stern v1.13.2
|
||||
go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc => go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.20.0
|
||||
go.opentelemetry.io/otel => go.opentelemetry.io/otel v0.20.0
|
||||
go.opentelemetry.io/otel/metric => go.opentelemetry.io/otel/metric v0.20.0
|
||||
go.opentelemetry.io/otel/sdk => go.opentelemetry.io/otel/sdk v0.20.0
|
||||
go.opentelemetry.io/otel/trace => go.opentelemetry.io/otel/trace v0.20.0
|
||||
go.opentelemetry.io/proto/otlp => go.opentelemetry.io/proto/otlp v0.7.0
|
||||
sigs.k8s.io/apiserver-network-proxy/konnectivity-client => sigs.k8s.io/apiserver-network-proxy/konnectivity-client v0.0.24
|
||||
)
|
||||
|
||||
@@ -499,7 +499,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -508,25 +508,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -659,7 +659,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -668,28 +668,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -776,7 +776,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -785,11 +785,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -798,13 +798,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -844,6 +844,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -2414,7 +2415,7 @@ spec:
|
||||
description: Components record the related Components created
|
||||
by Application Controller
|
||||
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
|
||||
@@ -2423,25 +2424,25 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2574,7 +2575,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -2583,28 +2584,28 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2691,7 +2692,7 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
@@ -2700,11 +2701,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -2713,13 +2714,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -2759,6 +2760,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -4752,31 +4754,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -4813,6 +4816,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -451,31 +451,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -602,7 +602,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -611,24 +611,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -708,31 +708,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -769,6 +770,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
@@ -1213,31 +1215,31 @@ spec:
|
||||
description: Components record the related Components created by Application
|
||||
Controller
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1364,7 +1366,7 @@ spec:
|
||||
type: string
|
||||
scopes:
|
||||
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
|
||||
@@ -1373,24 +1375,24 @@ spec:
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1470,31 +1472,32 @@ spec:
|
||||
appRevision:
|
||||
type: string
|
||||
contextBackend:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -1531,6 +1534,7 @@ spec:
|
||||
type: object
|
||||
endTime:
|
||||
format: date-time
|
||||
nullable: true
|
||||
type: string
|
||||
finished:
|
||||
type: boolean
|
||||
|
||||
@@ -59,7 +59,7 @@ spec:
|
||||
type: string
|
||||
traits:
|
||||
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
|
||||
@@ -69,26 +69,26 @@ spec:
|
||||
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
|
||||
.'
|
||||
\"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:
|
||||
description: API version of the referent.
|
||||
@@ -129,7 +129,7 @@ spec:
|
||||
type: object
|
||||
type: array
|
||||
workload:
|
||||
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
|
||||
@@ -138,11 +138,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -151,13 +151,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -213,31 +213,31 @@ spec:
|
||||
description: WorkloadReferences to the workloads that are in this
|
||||
scope.
|
||||
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 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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -305,7 +305,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
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
|
||||
@@ -314,11 +314,11 @@ spec:
|
||||
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
|
||||
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
|
||||
@@ -327,13 +327,13 @@ spec:
|
||||
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
|
||||
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:
|
||||
description: API version of the referent.
|
||||
@@ -461,7 +461,7 @@ spec:
|
||||
description: HealthStatus represents health status strings.
|
||||
type: string
|
||||
targetWorkload:
|
||||
description: 'ObjectReference contains enough information to
|
||||
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
|
||||
@@ -469,24 +469,25 @@ spec:
|
||||
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
|
||||
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
|
||||
.'
|
||||
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:
|
||||
description: API version of the referent.
|
||||
|
||||
@@ -17,9 +17,12 @@ limitations under the License.
|
||||
package addon
|
||||
|
||||
import (
|
||||
"bytes"
|
||||
"context"
|
||||
"errors"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"os"
|
||||
"strings"
|
||||
|
||||
v1 "k8s.io/api/core/v1"
|
||||
@@ -29,6 +32,38 @@ import (
|
||||
. "github.com/onsi/gomega"
|
||||
)
|
||||
|
||||
func setupMockServer() *httptest.Server {
|
||||
var listenURL string
|
||||
s := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, req *http.Request) {
|
||||
fileList := []string{
|
||||
"index.yaml",
|
||||
"fluxcd-test-version-1.0.0.tgz",
|
||||
"fluxcd-test-version-2.0.0.tgz",
|
||||
"vela-workflow-v0.3.5.tgz",
|
||||
"foo-v1.0.0.tgz",
|
||||
"bar-v1.0.0.tgz",
|
||||
"bar-v2.0.0.tgz",
|
||||
"mock-be-dep-addon-v1.0.0.tgz",
|
||||
}
|
||||
for _, f := range fileList {
|
||||
if strings.Contains(req.URL.Path, f) {
|
||||
file, err := os.ReadFile("../../e2e/addon/mock/testrepo/helm-repo/" + f)
|
||||
if err != nil {
|
||||
_, _ = w.Write([]byte(err.Error()))
|
||||
}
|
||||
if f == "index.yaml" {
|
||||
// in index.yaml, url is hardcoded to 127.0.0.1:9098,
|
||||
// so we need to replace it with the real random listen url
|
||||
file = bytes.ReplaceAll(file, []byte("http://127.0.0.1:9098"), []byte(listenURL))
|
||||
}
|
||||
_, _ = w.Write(file)
|
||||
}
|
||||
}
|
||||
}))
|
||||
listenURL = s.URL
|
||||
return s
|
||||
}
|
||||
|
||||
var _ = Describe("test FindAddonPackagesDetailFromRegistry", func() {
|
||||
Describe("when no registry is added, no matter what you do, it will just return error", func() {
|
||||
Context("when empty addonNames and registryNames is supplied", func() {
|
||||
@@ -50,12 +85,15 @@ var _ = Describe("test FindAddonPackagesDetailFromRegistry", func() {
|
||||
})
|
||||
|
||||
Describe("one versioned registry is added", func() {
|
||||
var s *httptest.Server
|
||||
|
||||
BeforeEach(func() {
|
||||
// Prepare KubeVela registry
|
||||
s = setupMockServer()
|
||||
// Prepare registry
|
||||
reg := &Registry{
|
||||
Name: "KubeVela",
|
||||
Name: "addon_helper_test",
|
||||
Helm: &HelmSource{
|
||||
URL: "https://addons.kubevela.net",
|
||||
URL: s.URL,
|
||||
},
|
||||
}
|
||||
ds := NewRegistryDataStore(k8sClient)
|
||||
@@ -63,38 +101,36 @@ var _ = Describe("test FindAddonPackagesDetailFromRegistry", func() {
|
||||
})
|
||||
|
||||
AfterEach(func() {
|
||||
// Clean up KubeVela registry
|
||||
// Clean up registry
|
||||
ds := NewRegistryDataStore(k8sClient)
|
||||
Expect(ds.DeleteRegistry(context.Background(), "KubeVela")).To(Succeed())
|
||||
Expect(ds.DeleteRegistry(context.Background(), "addon_helper_test")).To(Succeed())
|
||||
s.Close()
|
||||
})
|
||||
|
||||
Context("when empty addonNames and registryNames is supplied", func() {
|
||||
It("should return error, empty addonNames are not allowed", func() {
|
||||
_, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{}, []string{"KubeVela"})
|
||||
_, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{}, []string{"addon_helper_test"})
|
||||
Expect(err).To(HaveOccurred())
|
||||
})
|
||||
It("should return error, empty addonNames are not allowed", func() {
|
||||
_, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, nil, []string{"KubeVela"})
|
||||
_, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, nil, []string{"addon_helper_test"})
|
||||
Expect(err).To(HaveOccurred())
|
||||
})
|
||||
})
|
||||
|
||||
Context("one existing addon name provided", func() {
|
||||
It("should return one valid result, matching all registries", func() {
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"velaux"}, nil)
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"foo"}, nil)
|
||||
|
||||
Expect(err).To(Succeed())
|
||||
Expect(res).To(HaveLen(1))
|
||||
Expect(res[0].Name).To(Equal("velaux"))
|
||||
Expect(res[0].InstallPackage).ToNot(BeNil())
|
||||
Expect(res[0].APISchema).ToNot(BeNil())
|
||||
Expect(res[0].Name).To(Equal("foo"))
|
||||
})
|
||||
It("should return one valid result, matching one registry", func() {
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"velaux"}, []string{"KubeVela"})
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"foo"}, []string{"addon_helper_test"})
|
||||
Expect(err).To(Succeed())
|
||||
Expect(res).To(HaveLen(1))
|
||||
Expect(res[0].Name).To(Equal("velaux"))
|
||||
Expect(res[0].InstallPackage).ToNot(BeNil())
|
||||
Expect(res[0].APISchema).ToNot(BeNil())
|
||||
Expect(res[0].Name).To(Equal("foo"))
|
||||
})
|
||||
})
|
||||
|
||||
@@ -108,26 +144,20 @@ var _ = Describe("test FindAddonPackagesDetailFromRegistry", func() {
|
||||
|
||||
Context("two existing addon names provided", func() {
|
||||
It("should return two valid result", func() {
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"velaux", "traefik"}, nil)
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"foo", "bar"}, nil)
|
||||
Expect(err).To(Succeed())
|
||||
Expect(res).To(HaveLen(2))
|
||||
Expect(res[0].Name).To(Equal("velaux"))
|
||||
Expect(res[0].InstallPackage).ToNot(BeNil())
|
||||
Expect(res[0].APISchema).ToNot(BeNil())
|
||||
Expect(res[1].Name).To(Equal("traefik"))
|
||||
Expect(res[1].InstallPackage).ToNot(BeNil())
|
||||
Expect(res[1].APISchema).ToNot(BeNil())
|
||||
Expect(res[0].Name).To(Equal("foo"))
|
||||
Expect(res[1].Name).To(Equal("bar"))
|
||||
})
|
||||
})
|
||||
|
||||
Context("one existing addon name and one non-existent addon name provided", func() {
|
||||
It("should return only one valid result", func() {
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"velaux", "non-existent-addon"}, nil)
|
||||
res, err := FindAddonPackagesDetailFromRegistry(context.Background(), k8sClient, []string{"foo", "non-existent-addon"}, nil)
|
||||
Expect(err).To(Succeed())
|
||||
Expect(res).To(HaveLen(1))
|
||||
Expect(res[0].Name).To(Equal("velaux"))
|
||||
Expect(res[0].InstallPackage).ToNot(BeNil())
|
||||
Expect(res[0].APISchema).ToNot(BeNil())
|
||||
Expect(res[0].Name).To(Equal("foo"))
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
@@ -50,7 +50,7 @@ type Workflow struct {
|
||||
|
||||
// WorkflowStep defines how to execute a workflow step.
|
||||
type WorkflowStep struct {
|
||||
WorkflowStepBase `json:",inline"`
|
||||
WorkflowStepBase `json:",inline" bson:",inline"`
|
||||
SubSteps []WorkflowStepBase `json:"subSteps,omitempty"`
|
||||
}
|
||||
|
||||
@@ -123,7 +123,7 @@ type WorkflowRecord struct {
|
||||
|
||||
// WorkflowStepStatus is the workflow step status database model
|
||||
type WorkflowStepStatus struct {
|
||||
StepStatus `json:",inline"`
|
||||
StepStatus `json:",inline" bson:",inline"`
|
||||
SubStepsStatus []StepStatus `json:"subSteps,omitempty"`
|
||||
}
|
||||
|
||||
|
||||
@@ -137,6 +137,14 @@ func (u *configServiceImpl) CreateConfig(ctx context.Context, project string, re
|
||||
return nil, err
|
||||
}
|
||||
}
|
||||
exist, err := u.Factory.IsExist(ctx, ns, req.Name)
|
||||
if err != nil {
|
||||
klog.Errorf("check config name is exist failure %s", err.Error())
|
||||
return nil, bcode.ErrConfigExist
|
||||
}
|
||||
if exist {
|
||||
return nil, bcode.ErrConfigExist
|
||||
}
|
||||
var properties = make(map[string]interface{})
|
||||
if err := json.Unmarshal([]byte(req.Properties), &properties); err != nil {
|
||||
return nil, err
|
||||
@@ -156,9 +164,6 @@ func (u *configServiceImpl) CreateConfig(ctx context.Context, project string, re
|
||||
return nil, err
|
||||
}
|
||||
if err := u.Factory.CreateOrUpdateConfig(ctx, configItem, ns); err != nil {
|
||||
if errors.Is(err, config.ErrConfigExist) {
|
||||
return nil, bcode.ErrConfigExist
|
||||
}
|
||||
return nil, err
|
||||
}
|
||||
return convertConfig(project, *configItem), nil
|
||||
@@ -196,9 +201,12 @@ func (u *configServiceImpl) UpdateConfig(ctx context.Context, project string, na
|
||||
return nil, err
|
||||
}
|
||||
if err := u.Factory.CreateOrUpdateConfig(ctx, configItem, ns); err != nil {
|
||||
if errors.Is(err, config.ErrConfigExist) {
|
||||
if errors.Is(err, config.ErrChangeTemplate) {
|
||||
return nil, bcode.ErrChangeTemplate
|
||||
}
|
||||
if errors.Is(err, config.ErrChangeSecretType) {
|
||||
return nil, bcode.ErrChangeSecretType
|
||||
}
|
||||
return nil, err
|
||||
}
|
||||
return convertConfig(project, *configItem), nil
|
||||
|
||||
@@ -37,4 +37,7 @@ var (
|
||||
|
||||
// ErrNotFoundDistribution means the distribution is not exist
|
||||
ErrNotFoundDistribution = NewBcode(404, 16007, "the distribution is not exist")
|
||||
|
||||
// ErrChangeSecretType the secret type of the config can not be change
|
||||
ErrChangeSecretType = NewBcode(400, 16008, "the secret type of the config can not be change")
|
||||
)
|
||||
|
||||
@@ -88,6 +88,12 @@ var ErrConfigNotFound = errors.New("the config is not exist")
|
||||
// ErrTemplateNotFound means the template is not exist
|
||||
var ErrTemplateNotFound = errors.New("the template is not exist")
|
||||
|
||||
// ErrChangeTemplate means the template of the config can not be change
|
||||
var ErrChangeTemplate = errors.New("the template of the config can not be change")
|
||||
|
||||
// ErrChangeSecretType means the secret type of the config can not be change
|
||||
var ErrChangeSecretType = errors.New("the secret type of the config can not be change")
|
||||
|
||||
// NamespacedName the namespace and name model
|
||||
type NamespacedName struct {
|
||||
Name string `json:"name"`
|
||||
@@ -192,6 +198,7 @@ type Factory interface {
|
||||
ListConfigs(ctx context.Context, namespace, template, scope string, withStatus bool) ([]*Config, error)
|
||||
DeleteConfig(ctx context.Context, namespace, name string) error
|
||||
CreateOrUpdateConfig(ctx context.Context, i *Config, ns string) error
|
||||
IsExist(ctx context.Context, namespace, name string) (bool, error)
|
||||
|
||||
CreateOrUpdateDistribution(ctx context.Context, ns, name string, ads *CreateDistributionSpec) error
|
||||
ListDistributions(ctx context.Context, ns string) ([]*Distribution, error)
|
||||
@@ -549,7 +556,10 @@ func (k *kubeConfigFactory) CreateOrUpdateConfig(ctx context.Context, i *Config,
|
||||
var secret v1.Secret
|
||||
if err := k.cli.Get(ctx, pkgtypes.NamespacedName{Namespace: i.Namespace, Name: i.Name}, &secret); err == nil {
|
||||
if secret.Labels[types.LabelConfigType] != i.Template.Name {
|
||||
return ErrConfigExist
|
||||
return ErrChangeTemplate
|
||||
}
|
||||
if secret.Type != i.Secret.Type {
|
||||
return ErrChangeSecretType
|
||||
}
|
||||
}
|
||||
if err := k.apiApply.Apply(ctx, i.Secret, apply.Quiet()); err != nil {
|
||||
@@ -571,6 +581,17 @@ func (k *kubeConfigFactory) CreateOrUpdateConfig(ctx context.Context, i *Config,
|
||||
return nil
|
||||
}
|
||||
|
||||
func (k *kubeConfigFactory) IsExist(ctx context.Context, namespace, name string) (bool, error) {
|
||||
var secret v1.Secret
|
||||
if err := k.cli.Get(ctx, pkgtypes.NamespacedName{Namespace: namespace, Name: name}, &secret); err != nil {
|
||||
if apierrors.IsNotFound(err) {
|
||||
return false, nil
|
||||
}
|
||||
return false, err
|
||||
}
|
||||
return true, nil
|
||||
}
|
||||
|
||||
func (k *kubeConfigFactory) ListConfigs(ctx context.Context, namespace, template, scope string, withStatus bool) ([]*Config, error) {
|
||||
var list = &v1.SecretList{}
|
||||
requirement := fmt.Sprintf("%s=%s", types.LabelConfigCatalog, types.VelaCoreConfig)
|
||||
|
||||
@@ -145,6 +145,12 @@ var _ = Describe("test config factory", func() {
|
||||
Expect(len(config.Targets)).Should(Equal(1))
|
||||
})
|
||||
|
||||
It("check if the config exist", func() {
|
||||
exist, err := fac.IsExist(context.TODO(), "default", "db-config")
|
||||
Expect(err).Should(BeNil())
|
||||
Expect(exist).Should(BeTrue())
|
||||
})
|
||||
|
||||
It("list the distributions", func() {
|
||||
distributions, err := fac.ListDistributions(context.TODO(), "default")
|
||||
Expect(err).Should(BeNil())
|
||||
|
||||
@@ -195,7 +195,9 @@ func (r *Reconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Resu
|
||||
app.Status.SetConditions(condition.ReadyCondition(common.PolicyCondition.String()))
|
||||
r.Recorder.Event(app, event.Normal(velatypes.ReasonPolicyGenerated, velatypes.MessagePolicyGenerated))
|
||||
|
||||
workflowInstance, runners, err := handler.GenerateApplicationSteps(logCtx, app, appParser, appFile, handler.currentAppRev)
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
|
||||
workflowInstance, runners, err := handler.GenerateApplicationSteps(logCtx, app, appParser, appFile)
|
||||
if err != nil {
|
||||
logCtx.Error(err, "[handle workflow]")
|
||||
r.Recorder.Event(app, event.Warning(velatypes.ReasonFailedWorkflow, err))
|
||||
@@ -256,7 +258,7 @@ func (r *Reconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Resu
|
||||
}
|
||||
}
|
||||
case workflowv1alpha1.WorkflowStateSkipped:
|
||||
return ctrl.Result{}, nil
|
||||
return r.result(nil).requeue(executor.GetBackoffWaitTime()).ret()
|
||||
default:
|
||||
}
|
||||
|
||||
@@ -450,15 +452,12 @@ func (r *Reconciler) doWorkflowFinish(logCtx monitorContext.Context, app *v1beta
|
||||
wfContext.CleanupMemoryStore(app.Name, app.Namespace)
|
||||
t := time.Since(app.Status.Workflow.StartTime.Time).Seconds()
|
||||
metrics.WorkflowFinishedTimeHistogram.WithLabelValues(string(state)).Observe(t)
|
||||
switch state {
|
||||
case workflowv1alpha1.WorkflowStateSucceeded:
|
||||
if state == workflowv1alpha1.WorkflowStateSucceeded {
|
||||
app.Status.SetConditions(condition.ReadyCondition(common.WorkflowCondition.String()))
|
||||
r.Recorder.Event(app, event.Normal(velatypes.ReasonApplied, velatypes.MessageWorkflowFinished))
|
||||
handler.UpdateApplicationRevisionStatus(logCtx, handler.currentAppRev, true, app.Status.Workflow)
|
||||
logCtx.Info("Application manifests has applied by workflow successfully")
|
||||
default:
|
||||
handler.UpdateApplicationRevisionStatus(logCtx, handler.latestAppRev, false, app.Status.Workflow)
|
||||
}
|
||||
handler.UpdateApplicationRevisionStatus(logCtx, handler.currentAppRev, app.Status.Workflow)
|
||||
logCtx.Info("Application manifests has applied by workflow successfully")
|
||||
}
|
||||
|
||||
func hasHealthCheckPolicy(policies []*appfile.Workload) bool {
|
||||
|
||||
@@ -801,6 +801,76 @@ var _ = Describe("Test Application Controller", func() {
|
||||
}, appRevision)).Should(BeNil())
|
||||
})
|
||||
|
||||
It("revision should be updated if the workflow is restarted", func() {
|
||||
|
||||
ns := &corev1.Namespace{
|
||||
ObjectMeta: metav1.ObjectMeta{
|
||||
Name: "vela-test-app-restart-revision",
|
||||
},
|
||||
}
|
||||
Expect(k8sClient.Create(ctx, ns)).Should(BeNil())
|
||||
|
||||
app := &v1beta1.Application{
|
||||
ObjectMeta: metav1.ObjectMeta{
|
||||
Name: "vela-test-app-restart-revision",
|
||||
Namespace: "vela-test-app-restart-revision",
|
||||
},
|
||||
Spec: v1beta1.ApplicationSpec{
|
||||
Components: []common.ApplicationComponent{},
|
||||
Workflow: &v1beta1.Workflow{
|
||||
Steps: []workflowv1alpha1.WorkflowStep{
|
||||
{
|
||||
WorkflowStepBase: workflowv1alpha1.WorkflowStepBase{
|
||||
Name: "suspend",
|
||||
Type: "suspend",
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
},
|
||||
}
|
||||
|
||||
Expect(k8sClient.Create(ctx, app.DeepCopy())).Should(BeNil())
|
||||
|
||||
appKey := client.ObjectKey{
|
||||
Name: app.Name,
|
||||
Namespace: app.Namespace,
|
||||
}
|
||||
testutil.ReconcileOnceAfterFinalizer(reconciler, reconcile.Request{NamespacedName: appKey})
|
||||
By("Check Application Created with the correct revision")
|
||||
curApp := &v1beta1.Application{}
|
||||
Expect(k8sClient.Get(ctx, appKey, curApp)).Should(BeNil())
|
||||
Expect(curApp.Status.Phase).Should(Equal(common.ApplicationWorkflowSuspending))
|
||||
Expect(curApp.Status.LatestRevision).ShouldNot(BeNil())
|
||||
Expect(curApp.Status.LatestRevision.Revision).Should(BeEquivalentTo(1))
|
||||
|
||||
appRevision := &v1beta1.ApplicationRevision{}
|
||||
Expect(k8sClient.Get(ctx, client.ObjectKey{
|
||||
Namespace: app.Namespace,
|
||||
Name: curApp.Status.LatestRevision.Name,
|
||||
}, appRevision)).Should(BeNil())
|
||||
Expect(appRevision.Status.Workflow).Should(BeNil())
|
||||
|
||||
// update the app
|
||||
curApp.Spec.Workflow.Steps[0].DependsOn = []string{"invalid"}
|
||||
Expect(k8sClient.Update(ctx, curApp)).Should(BeNil())
|
||||
Expect(k8sClient.Get(ctx, appKey, curApp)).Should(BeNil())
|
||||
testutil.ReconcileOnce(reconciler, reconcile.Request{NamespacedName: appKey})
|
||||
|
||||
Expect(k8sClient.Get(ctx, client.ObjectKey{
|
||||
Namespace: app.Namespace,
|
||||
Name: curApp.Status.LatestRevision.Name,
|
||||
}, appRevision)).Should(BeNil())
|
||||
Expect(appRevision.Status.Workflow).ShouldNot(BeNil())
|
||||
Expect(appRevision.Status.Workflow.Finished).Should(BeTrue())
|
||||
Expect(appRevision.Status.Workflow.Terminated).Should(BeTrue())
|
||||
Expect(appRevision.Status.Workflow.EndTime.IsZero()).ShouldNot(BeTrue())
|
||||
Expect(appRevision.Status.Workflow.Phase).Should(Equal(workflowv1alpha1.WorkflowStateSuspending))
|
||||
|
||||
By("Delete Application, clean the resource")
|
||||
Expect(k8sClient.Delete(ctx, app)).Should(BeNil())
|
||||
})
|
||||
|
||||
It("revision should exist in created workload render by context.appRevision", func() {
|
||||
|
||||
ns := &corev1.Namespace{
|
||||
|
||||
@@ -83,9 +83,9 @@ var (
|
||||
func (h *AppHandler) GenerateApplicationSteps(ctx monitorContext.Context,
|
||||
app *v1beta1.Application,
|
||||
appParser *appfile.Parser,
|
||||
af *appfile.Appfile,
|
||||
appRev *v1beta1.ApplicationRevision) (*wfTypes.WorkflowInstance, []wfTypes.TaskRunner, error) {
|
||||
af *appfile.Appfile) (*wfTypes.WorkflowInstance, []wfTypes.TaskRunner, error) {
|
||||
|
||||
appRev := h.currentAppRev
|
||||
handlerProviders := providers.NewProviders()
|
||||
kube.Install(handlerProviders, h.r.Client,
|
||||
map[string]string{
|
||||
@@ -110,7 +110,7 @@ func (h *AppHandler) GenerateApplicationSteps(ctx monitorContext.Context,
|
||||
})
|
||||
query.Install(handlerProviders, h.r.Client, nil)
|
||||
|
||||
instance := generateWorkflowInstance(af, app, appRev.Name)
|
||||
instance := generateWorkflowInstance(af, app)
|
||||
executor.InitializeWorkflowInstance(instance)
|
||||
runners, err := generator.GenerateRunners(ctx, instance, wfTypes.StepGeneratorOptions{
|
||||
Providers: handlerProviders,
|
||||
@@ -135,7 +135,7 @@ func (h *AppHandler) GenerateApplicationSteps(ctx monitorContext.Context,
|
||||
return instance, runners, nil
|
||||
}
|
||||
|
||||
// needRestart check if application workflow need restart and return the desired
|
||||
// CheckWorkflowRestart check if application workflow need restart and return the desired
|
||||
// rev to be set in status
|
||||
// 1. If workflow status is empty, it means no previous running record, the
|
||||
// workflow will restart (cold start)
|
||||
@@ -144,8 +144,8 @@ func (h *AppHandler) GenerateApplicationSteps(ctx monitorContext.Context,
|
||||
// 3. If workflow status is not empty, the desired rev will be the
|
||||
// ApplicationRevision name. For backward compatibility, the legacy style
|
||||
// <rev>:<hash> will be recognized and reduced into <rev>
|
||||
func needRestart(app *v1beta1.Application, revName string) (string, bool) {
|
||||
desiredRev, currentRev := revName, ""
|
||||
func (h *AppHandler) CheckWorkflowRestart(ctx monitorContext.Context, app *v1beta1.Application) {
|
||||
desiredRev, currentRev := h.currentAppRev.Name, ""
|
||||
if app.Status.Workflow != nil {
|
||||
currentRev = app.Status.Workflow.AppRevision
|
||||
}
|
||||
@@ -158,10 +158,40 @@ func needRestart(app *v1beta1.Application, revName string) (string, bool) {
|
||||
currentRev = currentRev[:idx]
|
||||
}
|
||||
}
|
||||
return desiredRev, currentRev == "" || desiredRev != currentRev
|
||||
if currentRev != "" && desiredRev == currentRev {
|
||||
return
|
||||
}
|
||||
// record in revision
|
||||
if h.latestAppRev != nil && h.latestAppRev.Status.Workflow == nil && app.Status.Workflow != nil {
|
||||
app.Status.Workflow.Terminated = true
|
||||
app.Status.Workflow.Finished = true
|
||||
if app.Status.Workflow.EndTime.IsZero() {
|
||||
app.Status.Workflow.EndTime = metav1.Now()
|
||||
}
|
||||
h.UpdateApplicationRevisionStatus(ctx, h.latestAppRev, app.Status.Workflow)
|
||||
}
|
||||
|
||||
// clean recorded resources info.
|
||||
app.Status.Services = nil
|
||||
app.Status.AppliedResources = nil
|
||||
|
||||
// clean conditions after render
|
||||
var reservedConditions []condition.Condition
|
||||
for i, cond := range app.Status.Conditions {
|
||||
condTpy, err := common.ParseApplicationConditionType(string(cond.Type))
|
||||
if err == nil {
|
||||
if condTpy <= common.RenderCondition {
|
||||
reservedConditions = append(reservedConditions, app.Status.Conditions[i])
|
||||
}
|
||||
}
|
||||
}
|
||||
app.Status.Conditions = reservedConditions
|
||||
app.Status.Workflow = &common.WorkflowStatus{
|
||||
AppRevision: desiredRev,
|
||||
}
|
||||
}
|
||||
|
||||
func generateWorkflowInstance(af *appfile.Appfile, app *v1beta1.Application, appRev string) *wfTypes.WorkflowInstance {
|
||||
func generateWorkflowInstance(af *appfile.Appfile, app *v1beta1.Application) *wfTypes.WorkflowInstance {
|
||||
instance := &wfTypes.WorkflowInstance{
|
||||
WorkflowMeta: wfTypes.WorkflowMeta{
|
||||
Name: af.Name,
|
||||
@@ -183,27 +213,6 @@ func generateWorkflowInstance(af *appfile.Appfile, app *v1beta1.Application, app
|
||||
Steps: af.WorkflowSteps,
|
||||
Mode: af.WorkflowMode,
|
||||
}
|
||||
if desiredRev, nr := needRestart(app, appRev); nr {
|
||||
// clean recorded resources info.
|
||||
app.Status.Services = nil
|
||||
app.Status.AppliedResources = nil
|
||||
|
||||
// clean conditions after render
|
||||
var reservedConditions []condition.Condition
|
||||
for i, cond := range app.Status.Conditions {
|
||||
condTpy, err := common.ParseApplicationConditionType(string(cond.Type))
|
||||
if err == nil {
|
||||
if condTpy <= common.RenderCondition {
|
||||
reservedConditions = append(reservedConditions, app.Status.Conditions[i])
|
||||
}
|
||||
}
|
||||
}
|
||||
app.Status.Conditions = reservedConditions
|
||||
app.Status.Workflow = &common.WorkflowStatus{
|
||||
AppRevision: desiredRev,
|
||||
}
|
||||
return instance
|
||||
}
|
||||
status := app.Status.Workflow
|
||||
instance.Status = workflowv1alpha1.WorkflowRunStatus{
|
||||
Mode: *af.WorkflowMode,
|
||||
|
||||
@@ -112,13 +112,15 @@ var _ = Describe("Test Application workflow generator", func() {
|
||||
Expect(err).Should(BeNil())
|
||||
_, err = af.GeneratePolicyManifests(context.Background())
|
||||
Expect(err).Should(BeNil())
|
||||
appRev := &oamcore.ApplicationRevision{}
|
||||
|
||||
handler, err := NewAppHandler(ctx, reconciler, app, appParser)
|
||||
Expect(err).Should(Succeed())
|
||||
|
||||
logCtx := monitorContext.NewTraceContext(ctx, "")
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af, appRev)
|
||||
handler.currentAppRev = &oamcore.ApplicationRevision{}
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af)
|
||||
Expect(err).To(BeNil())
|
||||
Expect(len(taskRunner)).Should(BeEquivalentTo(2))
|
||||
Expect(taskRunner[0].Name()).Should(BeEquivalentTo("myweb1"))
|
||||
@@ -154,13 +156,14 @@ var _ = Describe("Test Application workflow generator", func() {
|
||||
Expect(err).Should(BeNil())
|
||||
_, err = af.GeneratePolicyManifests(context.Background())
|
||||
Expect(err).Should(BeNil())
|
||||
appRev := &oamcore.ApplicationRevision{}
|
||||
|
||||
handler, err := NewAppHandler(ctx, reconciler, app, appParser)
|
||||
Expect(err).Should(Succeed())
|
||||
|
||||
logCtx := monitorContext.NewTraceContext(ctx, "")
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af, appRev)
|
||||
handler.currentAppRev = &oamcore.ApplicationRevision{}
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af)
|
||||
Expect(err).To(BeNil())
|
||||
Expect(len(taskRunner)).Should(BeEquivalentTo(2))
|
||||
Expect(taskRunner[0].Name()).Should(BeEquivalentTo("myweb1"))
|
||||
@@ -274,13 +277,14 @@ var _ = Describe("Test Application workflow generator", func() {
|
||||
}
|
||||
af, err := appParser.GenerateAppFile(ctx, app)
|
||||
Expect(err).Should(BeNil())
|
||||
appRev := &oamcore.ApplicationRevision{}
|
||||
|
||||
handler, err := NewAppHandler(ctx, reconciler, app, appParser)
|
||||
Expect(err).Should(Succeed())
|
||||
|
||||
logCtx := monitorContext.NewTraceContext(ctx, "")
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af, appRev)
|
||||
handler.currentAppRev = &oamcore.ApplicationRevision{}
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
_, taskRunner, err := handler.GenerateApplicationSteps(logCtx, app, appParser, af)
|
||||
Expect(err).To(BeNil())
|
||||
Expect(len(taskRunner)).Should(BeEquivalentTo(2))
|
||||
Expect(taskRunner[0].Name()).Should(BeEquivalentTo("myweb1"))
|
||||
@@ -315,13 +319,14 @@ var _ = Describe("Test Application workflow generator", func() {
|
||||
}
|
||||
af, err := appParser.GenerateAppFile(ctx, app)
|
||||
Expect(err).Should(BeNil())
|
||||
appRev := &oamcore.ApplicationRevision{}
|
||||
|
||||
handler, err := NewAppHandler(ctx, reconciler, app, appParser)
|
||||
Expect(err).Should(Succeed())
|
||||
|
||||
logCtx := monitorContext.NewTraceContext(ctx, "")
|
||||
_, _, err = handler.GenerateApplicationSteps(logCtx, app, appParser, af, appRev)
|
||||
handler.currentAppRev = &oamcore.ApplicationRevision{}
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
_, _, err = handler.GenerateApplicationSteps(logCtx, app, appParser, af)
|
||||
Expect(err).NotTo(BeNil())
|
||||
})
|
||||
|
||||
@@ -353,13 +358,14 @@ var _ = Describe("Test Application workflow generator", func() {
|
||||
}
|
||||
af, err := appParser.GenerateAppFile(ctx, app)
|
||||
Expect(err).Should(BeNil())
|
||||
appRev := &oamcore.ApplicationRevision{}
|
||||
|
||||
handler, err := NewAppHandler(ctx, reconciler, app, appParser)
|
||||
Expect(err).Should(Succeed())
|
||||
|
||||
logCtx := monitorContext.NewTraceContext(ctx, "")
|
||||
_, _, err = handler.GenerateApplicationSteps(logCtx, app, appParser, af, appRev)
|
||||
handler.currentAppRev = &oamcore.ApplicationRevision{}
|
||||
handler.CheckWorkflowRestart(logCtx, app)
|
||||
_, _, err = handler.GenerateApplicationSteps(logCtx, app, appParser, af)
|
||||
Expect(err).NotTo(BeNil())
|
||||
})
|
||||
})
|
||||
|
||||
@@ -1006,11 +1006,11 @@ func (h historiesByComponentRevision) Less(i, j int) bool {
|
||||
}
|
||||
|
||||
// UpdateApplicationRevisionStatus update application revision status
|
||||
func (h *AppHandler) UpdateApplicationRevisionStatus(ctx context.Context, appRev *v1beta1.ApplicationRevision, succeed bool, wfStatus *common.WorkflowStatus) {
|
||||
func (h *AppHandler) UpdateApplicationRevisionStatus(ctx context.Context, appRev *v1beta1.ApplicationRevision, wfStatus *common.WorkflowStatus) {
|
||||
if appRev == nil || DisableAllApplicationRevision {
|
||||
return
|
||||
}
|
||||
appRev.Status.Succeeded = succeed
|
||||
appRev.Status.Succeeded = wfStatus.Phase == workflowv1alpha1.WorkflowStateSucceeded
|
||||
appRev.Status.Workflow = wfStatus
|
||||
if err := h.r.Client.Status().Update(ctx, appRev); err != nil {
|
||||
if logCtx, ok := ctx.(monitorContext.Context); ok {
|
||||
|
||||
@@ -184,8 +184,6 @@ var _ = Describe("test generate revision ", func() {
|
||||
// add an annotation to workload Definition
|
||||
wd.SetAnnotations(map[string]string{oam.AnnotationAppRollout: "true"})
|
||||
appRevision2.Spec.WorkloadDefinitions[wd.Name] = wd
|
||||
// change the cd meta
|
||||
cd.ClusterName = "testCluster"
|
||||
appRevision2.Spec.ComponentDefinitions[cd.Name] = cd
|
||||
|
||||
verifyEqual()
|
||||
|
||||
@@ -95,7 +95,7 @@ var _ = Describe("Test DefinitionRevision created by ComponentDefinition", func(
|
||||
content, err := os.ReadFile("./test-data/webservice-cd.yaml")
|
||||
Expect(err).Should(BeNil())
|
||||
var cd v1beta1.ComponentDefinition
|
||||
yaml.Unmarshal(content, &cd)
|
||||
Expect(yaml.Unmarshal(content, &cd)).Should(BeNil())
|
||||
cd.Name = cdName
|
||||
cd.Namespace = namespace
|
||||
|
||||
|
||||
@@ -355,13 +355,16 @@ func (td *traitDef) Complete(ctx process.Context, abstractTemplate string, param
|
||||
|
||||
patcher := val.LookupPath(value.FieldPath(PatchFieldName))
|
||||
base, auxiliaries := ctx.Output()
|
||||
if base != nil && patcher.Exists() {
|
||||
if patcher.Exists() {
|
||||
if base == nil {
|
||||
return fmt.Errorf("patch trait %s into an invalid workload", td.name)
|
||||
}
|
||||
if err := base.Unify(patcher, sets.CreateUnifyOptionsForPatcher(patcher)...); err != nil {
|
||||
return errors.WithMessagef(err, "invalid patch trait %s into workload", td.name)
|
||||
}
|
||||
}
|
||||
outputsPatcher := val.LookupPath(value.FieldPath(PatchOutputsFieldName))
|
||||
if base != nil && outputsPatcher.Exists() {
|
||||
if outputsPatcher.Exists() {
|
||||
for _, auxiliary := range auxiliaries {
|
||||
target := outputsPatcher.LookupPath(value.FieldPath(auxiliary.Name))
|
||||
if !target.Exists() {
|
||||
|
||||
@@ -25,6 +25,7 @@ import (
|
||||
"k8s.io/apimachinery/pkg/runtime"
|
||||
|
||||
"github.com/kubevela/workflow/pkg/cue/packages"
|
||||
wfprocess "github.com/kubevela/workflow/pkg/cue/process"
|
||||
|
||||
"github.com/oam-dev/kubevela/apis/types"
|
||||
"github.com/oam-dev/kubevela/pkg/cue/process"
|
||||
@@ -1534,3 +1535,34 @@ func TestTraitPatchSingleOutput(t *testing.T) {
|
||||
r.True(ok)
|
||||
r.Equal("val", val)
|
||||
}
|
||||
|
||||
func TestTraitCompleteErrorCases(t *testing.T) {
|
||||
cases := map[string]struct {
|
||||
ctx wfprocess.Context
|
||||
traitName string
|
||||
template string
|
||||
params map[string]interface{}
|
||||
err string
|
||||
}{
|
||||
"patch trait": {
|
||||
ctx: process.NewContext(process.ContextData{}),
|
||||
template: `
|
||||
patch: {
|
||||
// +patchKey=name
|
||||
spec: template: spec: containers: [parameter]
|
||||
}
|
||||
parameter: {
|
||||
name: string
|
||||
image: string
|
||||
command?: [...string]
|
||||
}`,
|
||||
err: "patch trait patch trait into an invalid workload",
|
||||
},
|
||||
}
|
||||
for k, v := range cases {
|
||||
td := NewTraitAbstractEngine(k, &packages.PackageDiscover{})
|
||||
err := td.Complete(v.ctx, v.template, v.params)
|
||||
assert.Error(t, err)
|
||||
assert.Contains(t, err.Error(), v.err)
|
||||
}
|
||||
}
|
||||
|
||||
@@ -364,6 +364,7 @@ func (h *gcHandler) deleteManagedResource(ctx context.Context, mr v1beta1.Manage
|
||||
return nil
|
||||
}
|
||||
}
|
||||
util.RemoveAnnotations(entry.obj, []string{oam.AnnotationAppSharedBy})
|
||||
if mr.SkipGC {
|
||||
if labels := entry.obj.GetLabels(); labels != nil {
|
||||
delete(labels, oam.LabelAppName)
|
||||
|
||||
@@ -25,6 +25,7 @@ import (
|
||||
|
||||
appsv1 "k8s.io/api/apps/v1"
|
||||
v12 "k8s.io/api/core/v1"
|
||||
kerrors "k8s.io/apimachinery/pkg/api/errors"
|
||||
"k8s.io/apimachinery/pkg/api/meta"
|
||||
v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
|
||||
"k8s.io/apimachinery/pkg/apis/meta/v1/unstructured"
|
||||
@@ -908,7 +909,7 @@ func iterateListSubResources(ctx context.Context, cluster string, k8sClient clie
|
||||
clusterCTX := multicluster.ContextWithClusterName(ctx, cluster)
|
||||
items, err := listItemByRule(clusterCTX, k8sClient, resource, *parentObject, specifiedFunc, rule.DefaultGenListOptionFunc, rule.DisableFilterByOwnerReference)
|
||||
if err != nil {
|
||||
if meta.IsNoMatchError(err) || runtime.IsNotRegisteredError(err) {
|
||||
if meta.IsNoMatchError(err) || runtime.IsNotRegisteredError(err) || kerrors.IsNotFound(err) {
|
||||
klog.Warningf("ignore list resources: %s as %v", resource.Kind, err)
|
||||
continue
|
||||
}
|
||||
|
||||
@@ -176,6 +176,7 @@ func NewAddonEnableCommand(c common.Args, ioStream cmdutil.IOStreams) *cobra.Com
|
||||
}
|
||||
addonOrDir := args[0]
|
||||
var name = addonOrDir
|
||||
var addonName string
|
||||
if file, err := os.Stat(addonOrDir); err == nil {
|
||||
if !file.IsDir() {
|
||||
return fmt.Errorf("%s is not addon dir", addonOrDir)
|
||||
@@ -186,13 +187,13 @@ func NewAddonEnableCommand(c common.Args, ioStream cmdutil.IOStreams) *cobra.Com
|
||||
if err != nil {
|
||||
return errors.Wrapf(err, "directory %s is invalid", addonOrDir)
|
||||
}
|
||||
name = filepath.Base(abs)
|
||||
addonName = filepath.Base(abs)
|
||||
if !yes2all {
|
||||
if err := checkUninstallFromClusters(ctx, k8sClient, name, addonArgs); err != nil {
|
||||
if err := checkUninstallFromClusters(ctx, k8sClient, addonName, addonArgs); err != nil {
|
||||
return err
|
||||
}
|
||||
}
|
||||
err = enableAddonByLocal(ctx, name, addonOrDir, k8sClient, dc, config, addonArgs)
|
||||
err = enableAddonByLocal(ctx, addonName, addonOrDir, k8sClient, dc, config, addonArgs)
|
||||
if err != nil {
|
||||
return err
|
||||
}
|
||||
@@ -200,8 +201,12 @@ func NewAddonEnableCommand(c common.Args, ioStream cmdutil.IOStreams) *cobra.Com
|
||||
if filepath.IsAbs(addonOrDir) || strings.HasPrefix(addonOrDir, ".") || strings.HasSuffix(addonOrDir, "/") {
|
||||
return fmt.Errorf("addon directory %s not found in local file system", addonOrDir)
|
||||
}
|
||||
_, addonName, err = splitSpecifyRegistry(name)
|
||||
if err != nil {
|
||||
return fmt.Errorf("failed to split addonName and addonRegistry: %w", err)
|
||||
}
|
||||
if !yes2all {
|
||||
if err := checkUninstallFromClusters(ctx, k8sClient, name, addonArgs); err != nil {
|
||||
if err := checkUninstallFromClusters(ctx, k8sClient, addonName, addonArgs); err != nil {
|
||||
return err
|
||||
}
|
||||
}
|
||||
@@ -213,8 +218,8 @@ func NewAddonEnableCommand(c common.Args, ioStream cmdutil.IOStreams) *cobra.Com
|
||||
if dryRun {
|
||||
return nil
|
||||
}
|
||||
fmt.Printf("Addon %s enabled successfully.\n", name)
|
||||
AdditionalEndpointPrinter(ctx, c, k8sClient, name, false)
|
||||
fmt.Printf("Addon %s enabled successfully.\n", addonName)
|
||||
AdditionalEndpointPrinter(ctx, c, k8sClient, addonName, false)
|
||||
return nil
|
||||
},
|
||||
}
|
||||
@@ -1157,12 +1162,12 @@ func hasAddon(addons []*pkgaddon.UIData, name string) bool {
|
||||
return false
|
||||
}
|
||||
|
||||
func transClusters(cstr string) []string {
|
||||
func transClusters(cstr string) []interface{} {
|
||||
if len(cstr) == 0 {
|
||||
return nil
|
||||
}
|
||||
cstr = strings.TrimPrefix(strings.TrimSuffix(cstr, "}"), "{")
|
||||
var clusterL []string
|
||||
var clusterL []interface{}
|
||||
clusterList := strings.Split(cstr, ",")
|
||||
for _, v := range clusterList {
|
||||
clusterL = append(clusterL, strings.TrimSpace(v))
|
||||
|
||||
@@ -191,19 +191,19 @@ func TestAddonUpgradeCmdWithErrLocalPath(t *testing.T) {
|
||||
func TestTransCluster(t *testing.T) {
|
||||
testcase := []struct {
|
||||
str string
|
||||
res []string
|
||||
res []interface{}
|
||||
}{
|
||||
{
|
||||
str: "{cluster1, cluster2}",
|
||||
res: []string{"cluster1", "cluster2"},
|
||||
res: []interface{}{"cluster1", "cluster2"},
|
||||
},
|
||||
{
|
||||
str: "{cluster1,cluster2}",
|
||||
res: []string{"cluster1", "cluster2"},
|
||||
res: []interface{}{"cluster1", "cluster2"},
|
||||
},
|
||||
{
|
||||
str: "{cluster1, cluster2 }",
|
||||
res: []string{"cluster1", "cluster2"},
|
||||
res: []interface{}{"cluster1", "cluster2"},
|
||||
},
|
||||
}
|
||||
for _, s := range testcase {
|
||||
|
||||
@@ -144,7 +144,7 @@ func NewGenKubeConfigCommand(f velacmd.Factory, streams util.IOStreams) *cobra.C
|
||||
Annotations: map[string]string{
|
||||
types.TagCommandType: types.TypeCD,
|
||||
},
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
Run: func(cmd *cobra.Command, args []string) {
|
||||
o.Complete(f, cmd)
|
||||
cmdutil.CheckErr(o.Validate())
|
||||
@@ -271,7 +271,7 @@ func NewListPrivilegesCommand(f velacmd.Factory, streams util.IOStreams) *cobra.
|
||||
Annotations: map[string]string{
|
||||
types.TagCommandType: types.TypeCD,
|
||||
},
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
Run: func(cmd *cobra.Command, args []string) {
|
||||
o.Complete(f, cmd)
|
||||
cmdutil.CheckErr(o.Validate(f, cmd))
|
||||
@@ -442,7 +442,7 @@ func NewGrantPrivilegesCommand(f velacmd.Factory, streams util.IOStreams) *cobra
|
||||
Annotations: map[string]string{
|
||||
types.TagCommandType: types.TypeCD,
|
||||
},
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
Run: func(cmd *cobra.Command, args []string) {
|
||||
o.Complete(f, cmd)
|
||||
cmdutil.CheckErr(o.Validate(f, cmd))
|
||||
|
||||
@@ -96,7 +96,7 @@ func NewClusterListCommand(c *common.Args) *cobra.Command {
|
||||
Aliases: []string{"ls"},
|
||||
Short: "list managed clusters",
|
||||
Long: "list worker clusters managed by KubeVela.",
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
table := newUITable().AddRow("CLUSTER", "ALIAS", "TYPE", "ENDPOINT", "ACCEPTED", "LABELS")
|
||||
client, err := c.GetClient()
|
||||
@@ -145,7 +145,7 @@ func NewClusterJoinCommand(c *common.Args, ioStreams cmdutil.IOStreams) *cobra.C
|
||||
Long: "join managed cluster by kubeconfig.",
|
||||
Example: "# Join cluster declared in my-child-cluster.kubeconfig\n" +
|
||||
"> vela cluster join my-child-cluster.kubeconfig --name example-cluster",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
// get ClusterName from flag or config
|
||||
clusterName, err := cmd.Flags().GetString(FlagClusterName)
|
||||
@@ -208,7 +208,7 @@ func NewClusterRenameCommand(c *common.Args) *cobra.Command {
|
||||
Use: "rename [OLD_NAME] [NEW_NAME]",
|
||||
Short: "rename managed cluster.",
|
||||
Long: "rename managed cluster.",
|
||||
Args: cobra.ExactValidArgs(2),
|
||||
Args: cobra.ExactArgs(2),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
oldClusterName := args[0]
|
||||
newClusterName := args[1]
|
||||
@@ -232,7 +232,7 @@ func NewClusterDetachCommand(c *common.Args) *cobra.Command {
|
||||
Use: "detach [CLUSTER_NAME]",
|
||||
Short: "detach managed cluster.",
|
||||
Long: "detach managed cluster.",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
clusterName := args[0]
|
||||
configPath, _ := cmd.Flags().GetString(FlagKubeConfigPath)
|
||||
@@ -259,7 +259,7 @@ func NewClusterAliasCommand(c *common.Args) *cobra.Command {
|
||||
Use: "alias CLUSTER_NAME ALIAS",
|
||||
Short: "alias a named cluster.",
|
||||
Long: "alias a named cluster.",
|
||||
Args: cobra.ExactValidArgs(2),
|
||||
Args: cobra.ExactArgs(2),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
clusterName, aliasName := args[0], args[1]
|
||||
k8sClient, err := c.GetClient()
|
||||
@@ -283,7 +283,7 @@ func NewClusterProbeCommand(c *common.Args) *cobra.Command {
|
||||
Use: "probe [CLUSTER_NAME]",
|
||||
Short: "health probe managed cluster.",
|
||||
Long: "health probe managed cluster.",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
clusterName := args[0]
|
||||
config, err := c.GetConfig()
|
||||
@@ -346,7 +346,7 @@ func NewClusterAddLabelsCommand(c *common.Args) *cobra.Command {
|
||||
Short: "add labels to managed cluster",
|
||||
Long: "add labels to managed cluster",
|
||||
Example: "vela cluster labels add my-cluster project=kubevela,owner=oam-dev",
|
||||
Args: cobra.ExactValidArgs(2),
|
||||
Args: cobra.ExactArgs(2),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
clusterName := args[0]
|
||||
addLabels := map[string]string{}
|
||||
@@ -382,7 +382,7 @@ func NewClusterDelLabelsCommand(c *common.Args) *cobra.Command {
|
||||
Aliases: []string{"delete", "remove"},
|
||||
Short: "delete labels for managed cluster",
|
||||
Long: "delete labels for managed cluster",
|
||||
Args: cobra.ExactValidArgs(2),
|
||||
Args: cobra.ExactArgs(2),
|
||||
Example: "vela cluster labels del my-cluster project,owner",
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
clusterName := args[0]
|
||||
|
||||
@@ -176,7 +176,7 @@ func NewDefinitionInitCommand(c common.Args) *cobra.Command {
|
||||
"> vela def init vswitch --type component --provider alibaba --desc xxx --git https://github.com/kubevela-contrib/terraform-modules.git --path alibaba/vswitch\n" +
|
||||
"# Initiate a Terraform ComponentDefinition named redis from local file for AWS.\n" +
|
||||
"> vela def init redis --type component --provider aws --desc \"Terraform configuration for AWS Redis\" --local redis.tf",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
var defStr string
|
||||
definitionType, err := cmd.Flags().GetString(FlagType)
|
||||
@@ -449,7 +449,7 @@ func NewDefinitionGetCommand(c common.Args) *cobra.Command {
|
||||
"> vela def get webservice\n" +
|
||||
"# Command below will get the TraitDefinition of annotations in namespace vela-system\n" +
|
||||
"> vela def get annotations --type trait --namespace vela-system",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
definitionType, err := cmd.Flags().GetString(FlagType)
|
||||
if err != nil {
|
||||
@@ -562,7 +562,7 @@ func NewDefinitionListCommand(c common.Args) *cobra.Command {
|
||||
"> vela def list\n" +
|
||||
"# Command below will list all definitions in the vela-system namespace\n" +
|
||||
"> vela def get annotations --type trait --namespace vela-system",
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
definitionType, err := cmd.Flags().GetString(FlagType)
|
||||
if err != nil {
|
||||
@@ -649,7 +649,7 @@ func NewDefinitionEditCommand(c common.Args) *cobra.Command {
|
||||
"> vela def edit webservice\n" +
|
||||
"# Command below will edit the TraitDefinition of ingress in vela-system namespace\n" +
|
||||
"> vela def edit ingress --type trait --namespace vela-system",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
definitionType, err := cmd.Flags().GetString(FlagType)
|
||||
if err != nil {
|
||||
@@ -749,7 +749,7 @@ func NewDefinitionRenderCommand(c common.Args) *cobra.Command {
|
||||
"> vela def render my-webservice.cue -o my-webservice.yaml" +
|
||||
"# Command below will render all cue format definitions in the ./defs/cue/ directory and save the YAML objects in ./defs/yaml/.\n" +
|
||||
"> vela def render ./defs/cue/ -o ./defs/yaml/",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
output, err := cmd.Flags().GetString(FlagOutput)
|
||||
if err != nil {
|
||||
@@ -862,7 +862,7 @@ func NewDefinitionApplyCommand(c common.Args, streams util.IOStreams) *cobra.Com
|
||||
"> vela def apply https://my-host-to-def/my-trait.cue --dry-run" +
|
||||
"# Apply a CUE from stdin \n" +
|
||||
"> vela def apply -",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
ctx := context.Background()
|
||||
dryRun, err := cmd.Flags().GetBool(FlagDryRun)
|
||||
@@ -975,7 +975,7 @@ func NewDefinitionDelCommand(c common.Args) *cobra.Command {
|
||||
Long: "Delete X-Definition in kubernetes cluster.",
|
||||
Example: "# Command below will delete TraitDefinition of annotations in default namespace\n" +
|
||||
"> vela def del annotations -t trait -n default",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
definitionType, err := cmd.Flags().GetString(FlagType)
|
||||
if err != nil {
|
||||
@@ -1041,7 +1041,7 @@ func NewDefinitionValidateCommand(c common.Args) *cobra.Command {
|
||||
"* Currently, this command only checks the cue format. This function is still working in progress and we will support more functional validation mechanism in the future.",
|
||||
Example: "# Command below will validate the my-def.cue file.\n" +
|
||||
"> vela def vet my-def.cue",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
cueBytes, err := os.ReadFile(args[0])
|
||||
if err != nil {
|
||||
@@ -1077,7 +1077,7 @@ func NewDefinitionGenAPICommand(c common.Args) *cobra.Command {
|
||||
"* Currently, this function is still working in progress and not all formats of parameter in X-definition are supported yet.",
|
||||
Example: "# Command below will generate the Go struct for the my-def.cue file.\n" +
|
||||
"> vela def gen-api my-def.cue",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
cueBytes, err := os.ReadFile(args[0])
|
||||
if err != nil {
|
||||
|
||||
@@ -256,7 +256,7 @@ func NewKubeApplyCommand(f velacmd.Factory, streams util.IOStreams) *cobra.Comma
|
||||
Annotations: map[string]string{
|
||||
types.TagCommandType: types.TypeCD,
|
||||
},
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
Run: func(cmd *cobra.Command, args []string) {
|
||||
o.namespace = velacmd.GetNamespace(f, cmd)
|
||||
o.clusters = velacmd.GetClusters(cmd)
|
||||
|
||||
@@ -62,7 +62,7 @@ func NewRevisionListCommand(c common.Args) *cobra.Command {
|
||||
Aliases: []string{"ls"},
|
||||
Short: "list application revisions",
|
||||
Long: "list Kubevela application revisions",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
namespace, err := GetFlagNamespaceOrEnv(cmd, c)
|
||||
if err != nil {
|
||||
@@ -129,7 +129,7 @@ func NewRevisionGetCommand(c common.Args) *cobra.Command {
|
||||
Aliases: []string{"get"},
|
||||
Short: "get specific revision of application",
|
||||
Long: "get specific revision of application",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
namespace, err := GetFlagNamespaceOrEnv(cmd, c)
|
||||
if err != nil {
|
||||
|
||||
@@ -81,7 +81,7 @@ func NewSystemInfoCommand(c common.Args) *cobra.Command {
|
||||
Use: "info",
|
||||
Short: "Print the system deployment detail information in all namespaces with label app.kubernetes.io/name=vela-core.",
|
||||
Long: "Print the system deployment detail information in all namespaces with label app.kubernetes.io/name=vela-core.",
|
||||
Args: cobra.ExactValidArgs(0),
|
||||
Args: cobra.ExactArgs(0),
|
||||
RunE: func(cmd *cobra.Command, args []string) error {
|
||||
// Get deploymentName from flag
|
||||
deployName, err := cmd.Flags().GetString(FlagSpecify)
|
||||
|
||||
@@ -58,7 +58,6 @@ var _ = Describe("test Application", func() {
|
||||
Expect(err).NotTo(HaveOccurred())
|
||||
Expect(application.Name).To(Equal("first-vela-app"))
|
||||
Expect(application.Namespace).To(Equal("default"))
|
||||
Expect(application.ClusterName).To(Equal(""))
|
||||
Expect(len(application.Spec.Components)).To(Equal(1))
|
||||
})
|
||||
It("application resource topology", func() {
|
||||
|
||||
@@ -69,7 +69,6 @@ var _ = Describe("test pod", func() {
|
||||
Name: "pod",
|
||||
Namespace: "ns",
|
||||
CreationTimestamp: metav1.Time{Time: time.Now()},
|
||||
ClusterName: "",
|
||||
},
|
||||
Spec: v1.PodSpec{
|
||||
NodeName: "node-1",
|
||||
|
||||
@@ -55,7 +55,7 @@ func NewUISchemaCommand(c common.Args, order string, ioStreams util.IOStreams) *
|
||||
cmd.AddCommand(&cobra.Command{
|
||||
Use: "apply",
|
||||
Short: "apply <ui schema file/dir path>",
|
||||
Args: cobra.ExactValidArgs(1),
|
||||
Args: cobra.ExactArgs(1),
|
||||
Long: "apply UI schema from a file or dir",
|
||||
Annotations: map[string]string{
|
||||
types.TagCommandType: types.TypeExtension,
|
||||
|
||||
@@ -80,7 +80,7 @@ func NewUnInstallCommand(c common.Args, order string, ioStreams util.IOStreams)
|
||||
return errors.Wrapf(err, "cannot check installed addon")
|
||||
}
|
||||
if len(addons) != 0 {
|
||||
return fmt.Errorf("these addons have been eanbled :%v, please guarantee there is no application using these addons and use `vela uninstall -f` uninstall include addon ", addons)
|
||||
return fmt.Errorf("these addons have been enabled :%v, please guarantee there is no application using these addons and use `vela uninstall -f` uninstall include addon ", addons)
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -22,6 +22,8 @@ metadata:
|
||||
name: replica-webservice
|
||||
namespace: vela-system
|
||||
spec:
|
||||
workload:
|
||||
type: autodetects.core.oam.dev
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
|
||||
@@ -153,7 +153,7 @@ var _ = Describe("Test the rest api about the config", func() {
|
||||
Expect(config.Secret).Should(BeNil())
|
||||
Expect(config.Properties["registry"]).Should(Equal("kubevela.test.com"))
|
||||
|
||||
By("the template is not exist")
|
||||
By("the config name is exist")
|
||||
req = v1.CreateConfigRequest{
|
||||
Name: "test-registry",
|
||||
Alias: "Test Registry",
|
||||
@@ -162,6 +162,17 @@ var _ = Describe("Test the rest api about the config", func() {
|
||||
Properties: `{"registry": "kubevela.test.com"}`,
|
||||
}
|
||||
res = post("/configs", req)
|
||||
Expect(res.StatusCode).Should(Equal(400))
|
||||
|
||||
By("the template is not exist")
|
||||
req = v1.CreateConfigRequest{
|
||||
Name: "test-registry2",
|
||||
Alias: "Test Registry",
|
||||
Description: "This is a demo config",
|
||||
Template: v1.NamespacedName{Name: templateName + "notfound"},
|
||||
Properties: `{"registry": "kubevela.test.com"}`,
|
||||
}
|
||||
res = post("/configs", req)
|
||||
Expect(res.StatusCode).Should(Equal(404))
|
||||
|
||||
By("without the template")
|
||||
|
||||
@@ -108,7 +108,7 @@ var _ = Describe("Test oam application rest api", func() {
|
||||
Policies: app.Spec.Policies,
|
||||
Workflow: app.Spec.Workflow,
|
||||
}
|
||||
res := post(fmt.Sprintf("/v1/namespaces/%s/applications/%s?dryRun=All", namespace, appName), req)
|
||||
res := post(fmt.Sprintf("/v1/namespaces/%s/applications/%s?dryRun=All", namespace, appName+"-dryrun"), req)
|
||||
Expect(res).ShouldNot(BeNil())
|
||||
Expect(cmp.Diff(res.StatusCode, 200)).Should(BeEmpty())
|
||||
Expect(res.Body).ShouldNot(BeNil())
|
||||
@@ -119,7 +119,7 @@ var _ = Describe("Test oam application rest api", func() {
|
||||
Components: app.Spec.Components[1:],
|
||||
}
|
||||
Eventually(func(g Gomega) {
|
||||
res = post(fmt.Sprintf("/v1/namespaces/%s/applications/%s?dryRun=All", namespace, appName), updateReq)
|
||||
res = post(fmt.Sprintf("/v1/namespaces/%s/applications/%s?dryRun=All", namespace, appName+"-dryrun"), updateReq)
|
||||
g.Expect(res).ShouldNot(BeNil())
|
||||
g.Expect(cmp.Diff(res.StatusCode, 200)).Should(BeEmpty())
|
||||
g.Expect(res.Body).ShouldNot(BeNil())
|
||||
|
||||
@@ -796,5 +796,26 @@ var _ = Describe("Test multicluster scenario", func() {
|
||||
g.Expect(cnt).Should(Equal(1))
|
||||
}).WithTimeout(30 * time.Second).WithPolling(2 * time.Second).Should(Succeed())
|
||||
})
|
||||
|
||||
It("Test application with gc policy and shared-resource policy", func() {
|
||||
app := &v1beta1.Application{}
|
||||
bs, err := os.ReadFile("./testdata/app/app-gc-shared.yaml")
|
||||
Expect(err).Should(Succeed())
|
||||
Expect(yaml.Unmarshal(bs, app)).Should(Succeed())
|
||||
app.SetNamespace(namespace)
|
||||
Expect(k8sClient.Create(hubCtx, app)).Should(Succeed())
|
||||
appKey := client.ObjectKeyFromObject(app)
|
||||
Eventually(func(g Gomega) {
|
||||
g.Expect(k8sClient.Get(hubCtx, appKey, app)).Should(Succeed())
|
||||
g.Expect(app.Status.Phase).Should(Equal(common.ApplicationRunning))
|
||||
g.Expect(k8sClient.Get(hubCtx, appKey, &corev1.ConfigMap{})).Should(Succeed())
|
||||
}).WithTimeout(10 * time.Second).Should(Succeed())
|
||||
Expect(k8sClient.Get(hubCtx, appKey, app)).Should(Succeed())
|
||||
Expect(k8sClient.Delete(hubCtx, app)).Should(Succeed())
|
||||
Eventually(func(g Gomega) {
|
||||
g.Expect(kerrors.IsNotFound(k8sClient.Get(hubCtx, appKey, app))).Should(BeTrue())
|
||||
g.Expect(k8sClient.Get(hubCtx, appKey, &corev1.ConfigMap{})).Should(Succeed())
|
||||
}).WithTimeout(10 * time.Second).Should(Succeed())
|
||||
})
|
||||
})
|
||||
})
|
||||
|
||||
26
test/e2e-multicluster-test/testdata/app/app-gc-shared.yaml
vendored
Normal file
26
test/e2e-multicluster-test/testdata/app/app-gc-shared.yaml
vendored
Normal file
@@ -0,0 +1,26 @@
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-gc-shared
|
||||
spec:
|
||||
components:
|
||||
- type: k8s-objects
|
||||
name: app-gc-shared
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: v1
|
||||
kind: ConfigMap
|
||||
policies:
|
||||
- name: gc-policy
|
||||
type: garbage-collect
|
||||
properties:
|
||||
rules:
|
||||
- selector:
|
||||
resourceTypes: ["ConfigMap"]
|
||||
strategy: never
|
||||
- name: shared-policy
|
||||
type: shared-resource
|
||||
properties:
|
||||
rules:
|
||||
- selector:
|
||||
resourceTypes: ["ConfigMap"]
|
||||
@@ -7,6 +7,8 @@ metadata:
|
||||
name: replica-webservice
|
||||
namespace: vela-system
|
||||
spec:
|
||||
workload:
|
||||
type: autodetects.core.oam.dev
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
|
||||
Reference in New Issue
Block a user