Skip to content

Commit

Permalink
bundle update
Browse files Browse the repository at this point in the history
  • Loading branch information
@eguzki
eguzki committed Sep 1, 2023
1 parent b6b191f commit 9a91794
Show file tree
Hide file tree
Showing 5 changed files with 140 additions and 95 deletions.
2 changes: 1 addition & 1 deletion bundle.Dockerfile
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ LABEL operators.operatorframework.io.bundle.manifests.v1=manifests/
LABEL operators.operatorframework.io.bundle.metadata.v1=metadata/
LABEL operators.operatorframework.io.bundle.package.v1=limitador-operator
LABEL operators.operatorframework.io.bundle.channels.v1=alpha
LABEL operators.operatorframework.io.metrics.builder=operator-sdk-v1.22.0
LABEL operators.operatorframework.io.metrics.builder=operator-sdk-v1.28.0
LABEL operators.operatorframework.io.metrics.mediatype.v1=metrics+v1
LABEL operators.operatorframework.io.metrics.project_layout=go.kubebuilder.io/v3

Expand Down
3 changes: 2 additions & 1 deletion bundle/manifests/limitador-operator.clusterserviceversion.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,8 @@ metadata:
capabilities: Basic Install
categories: Integration & Delivery
containerImage: quay.io/kuadrant/limitador-operator:latest
operators.operatorframework.io/builder: operator-sdk-v1.22.0
createdAt: "2023-09-01T15:14:18Z"
operators.operatorframework.io/builder: operator-sdk-v1.28.0
operators.operatorframework.io/project_layout: go.kubebuilder.io/v3
repository: https://github.com/Kuadrant/limitador-operator
support: kuadrant
Expand Down
114 changes: 68 additions & 46 deletions bundle/manifests/limitador.kuadrant.io_limitadors.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,26 @@ spec:
resourceRequirements:
description: ResourceRequirements describes the compute resource requirements.
properties:
claims:
description: "Claims lists the names of resources, defined in
spec.resourceClaims, that are used by this container. \n This
is an alpha field and requires enabling the DynamicResourceAllocation
feature gate. \n This field is immutable."
items:
description: ResourceClaim references one entry in PodSpec.ResourceClaims.
properties:
name:
description: Name must match the name of one entry in pod.spec.resourceClaims
of the Pod where this field is used. It makes that resource
available inside a container.
type: string
required:
- name
type: object
type: array
x-kubernetes-list-map-keys:
- name
x-kubernetes-list-type: map
limits:
additionalProperties:
anyOf:
Expand Down Expand Up @@ -139,32 +159,33 @@ spec:
redis:
properties:
configSecretRef:
description: 'ObjectReference contains enough information
description: "ObjectReference contains enough information
to let you inspect or modify the referred object. --- New
uses of this type are discouraged because of difficulty
describing its usage when embedded in APIs. 1. Ignored fields. It
includes many fields which are not generally honored. For
instance, ResourceVersion and FieldPath are both very rarely
valid in actual usage. 2. Invalid usage help. It is impossible
to add specific help for individual usage. In most embedded
usages, there are particular restrictions like, "must refer
only to types A and B" or "UID not honored" or "name must
be restricted". Those cannot be well described when embedded.
3. Inconsistent validation. Because the usages are different,
the validation rules are different by usage, which makes
it hard for users to predict what will happen. 4. The fields
are both imprecise and overly precise. Kind is not a precise
mapping to a URL. This can produce ambiguity during interpretation
and require a REST mapping. In most cases, the dependency
is on the group,resource tuple and the version of the actual
describing its usage when embedded in APIs. 1. Ignored fields.
\ It includes many fields which are not generally honored.
\ For instance, ResourceVersion and FieldPath are both very
rarely valid in actual usage. 2. Invalid usage help. It
is impossible to add specific help for individual usage.
\ In most embedded usages, there are particular restrictions
like, \"must refer only to types A and B\" or \"UID not
honored\" or \"name must be restricted\". Those cannot be
well described when embedded. 3. Inconsistent validation.
\ Because the usages are different, the validation rules
are different by usage, which makes it hard for users to
predict what will happen. 4. The fields are both imprecise
and overly precise. Kind is not a precise mapping to a
URL. This can produce ambiguity during interpretation and
require a REST mapping. In most cases, the dependency is
on the group,resource tuple and the version of the actual
struct is irrelevant. 5. We cannot easily change it. Because
this type is embedded in many locations, updates to this
type will affect numerous schemas. Don''t make new APIs
embed an underspecified API type they do not control. Instead
of using this type, create a locally provided and used type
that is well-focused on your reference. For example, ServiceReferences
for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
.'
type will affect numerous schemas. Don't make new APIs
embed an underspecified API type they do not control. \n
Instead of using this type, create a locally provided and
used type that is well-focused on your reference. For example,
ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
."
properties:
apiVersion:
description: API version of the referent.
Expand Down Expand Up @@ -205,32 +226,33 @@ spec:
redis-cached:
properties:
configSecretRef:
description: 'ObjectReference contains enough information
description: "ObjectReference contains enough information
to let you inspect or modify the referred object. --- New
uses of this type are discouraged because of difficulty
describing its usage when embedded in APIs. 1. Ignored fields. It
includes many fields which are not generally honored. For
instance, ResourceVersion and FieldPath are both very rarely
valid in actual usage. 2. Invalid usage help. It is impossible
to add specific help for individual usage. In most embedded
usages, there are particular restrictions like, "must refer
only to types A and B" or "UID not honored" or "name must
be restricted". Those cannot be well described when embedded.
3. Inconsistent validation. Because the usages are different,
the validation rules are different by usage, which makes
it hard for users to predict what will happen. 4. The fields
are both imprecise and overly precise. Kind is not a precise
mapping to a URL. This can produce ambiguity during interpretation
and require a REST mapping. In most cases, the dependency
is on the group,resource tuple and the version of the actual
describing its usage when embedded in APIs. 1. Ignored fields.
\ It includes many fields which are not generally honored.
\ For instance, ResourceVersion and FieldPath are both very
rarely valid in actual usage. 2. Invalid usage help. It
is impossible to add specific help for individual usage.
\ In most embedded usages, there are particular restrictions
like, \"must refer only to types A and B\" or \"UID not
honored\" or \"name must be restricted\". Those cannot be
well described when embedded. 3. Inconsistent validation.
\ Because the usages are different, the validation rules
are different by usage, which makes it hard for users to
predict what will happen. 4. The fields are both imprecise
and overly precise. Kind is not a precise mapping to a
URL. This can produce ambiguity during interpretation and
require a REST mapping. In most cases, the dependency is
on the group,resource tuple and the version of the actual
struct is irrelevant. 5. We cannot easily change it. Because
this type is embedded in many locations, updates to this
type will affect numerous schemas. Don''t make new APIs
embed an underspecified API type they do not control. Instead
of using this type, create a locally provided and used type
that is well-focused on your reference. For example, ServiceReferences
for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
.'
type will affect numerous schemas. Don't make new APIs
embed an underspecified API type they do not control. \n
Instead of using this type, create a locally provided and
used type that is well-focused on your reference. For example,
ServiceReferences for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533
."
properties:
apiVersion:
description: API version of the referent.
Expand Down Expand Up @@ -301,8 +323,8 @@ spec:
description: "Condition contains details for one aspect of the current
state of this API Resource. --- This struct is intended for direct
use as an array at the field path .status.conditions. For example,
type FooStatus struct{ // Represents the observations of a foo's
current state. // Known .status.conditions.type are: \"Available\",
\n type FooStatus struct{ // Represents the observations of a
foo's current state. // Known .status.conditions.type are: \"Available\",
\"Progressing\", and \"Degraded\" // +patchMergeKey=type // +patchStrategy=merge
// +listType=map // +listMapKey=type Conditions []metav1.Condition
`json:\"conditions,omitempty\" patchStrategy:\"merge\" patchMergeKey:\"type\"
Expand Down
2 changes: 1 addition & 1 deletion bundle/metadata/annotations.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ annotations:
operators.operatorframework.io.bundle.metadata.v1: metadata/
operators.operatorframework.io.bundle.package.v1: limitador-operator
operators.operatorframework.io.bundle.channels.v1: alpha
operators.operatorframework.io.metrics.builder: operator-sdk-v1.22.0
operators.operatorframework.io.metrics.builder: operator-sdk-v1.28.0
operators.operatorframework.io.metrics.mediatype.v1: metrics+v1
operators.operatorframework.io.metrics.project_layout: go.kubebuilder.io/v3

Expand Down
Loading

0 comments on commit 9a91794

Please sign in to comment.