|
34 | 34 | spec:
|
35 | 35 | description: LimitadorSpec defines the desired state of Limitador
|
36 | 36 | properties:
|
| 37 | + image: |
| 38 | + properties: |
| 39 | + name: |
| 40 | + description: Name of the image |
| 41 | + type: string |
| 42 | + pullSecret: |
| 43 | + description: PullSecret for pulling private images |
| 44 | + properties: |
| 45 | + name: |
| 46 | + description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names |
| 47 | + TODO: Add other useful fields. apiVersion, kind, uid?' |
| 48 | + type: string |
| 49 | + type: object |
| 50 | + x-kubernetes-map-type: atomic |
| 51 | + tag: |
| 52 | + description: Tag of the image |
| 53 | + type: string |
| 54 | + type: object |
37 | 55 | limits:
|
38 | 56 | items:
|
39 | 57 | description: RateLimit defines the desired Limitador limit
|
@@ -91,32 +109,8 @@ spec:
|
91 | 109 | redis:
|
92 | 110 | properties:
|
93 | 111 | configSecretRef:
|
94 |
| - description: 'ObjectReference contains enough information |
95 |
| - to let you inspect or modify the referred object. --- New |
96 |
| - uses of this type are discouraged because of difficulty |
97 |
| - describing its usage when embedded in APIs. 1. Ignored fields. It |
98 |
| - includes many fields which are not generally honored. For |
99 |
| - instance, ResourceVersion and FieldPath are both very rarely |
100 |
| - valid in actual usage. 2. Invalid usage help. It is impossible |
101 |
| - to add specific help for individual usage. In most embedded |
102 |
| - usages, there are particular restrictions like, "must refer |
103 |
| - only to types A and B" or "UID not honored" or "name must |
104 |
| - be restricted". Those cannot be well described when embedded. |
105 |
| - 3. Inconsistent validation. Because the usages are different, |
106 |
| - the validation rules are different by usage, which makes |
107 |
| - it hard for users to predict what will happen. 4. The fields |
108 |
| - are both imprecise and overly precise. Kind is not a precise |
109 |
| - mapping to a URL. This can produce ambiguity during interpretation |
110 |
| - and require a REST mapping. In most cases, the dependency |
111 |
| - is on the group,resource tuple and the version of the actual |
112 |
| - struct is irrelevant. 5. We cannot easily change it. Because |
113 |
| - this type is embedded in many locations, updates to this |
114 |
| - type will affect numerous schemas. Don''t make new APIs |
115 |
| - embed an underspecified API type they do not control. Instead |
116 |
| - of using this type, create a locally provided and used type |
117 |
| - that is well-focused on your reference. For example, ServiceReferences |
118 |
| - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 |
119 |
| - .' |
| 112 | + description: ConfigSecretRef refers to the secret holding |
| 113 | + the URL for Redis. |
120 | 114 | properties:
|
121 | 115 | apiVersion:
|
122 | 116 | description: API version of the referent.
|
@@ -157,32 +151,8 @@ spec:
|
157 | 151 | redis-cached:
|
158 | 152 | properties:
|
159 | 153 | configSecretRef:
|
160 |
| - description: 'ObjectReference contains enough information |
161 |
| - to let you inspect or modify the referred object. --- New |
162 |
| - uses of this type are discouraged because of difficulty |
163 |
| - describing its usage when embedded in APIs. 1. Ignored fields. It |
164 |
| - includes many fields which are not generally honored. For |
165 |
| - instance, ResourceVersion and FieldPath are both very rarely |
166 |
| - valid in actual usage. 2. Invalid usage help. It is impossible |
167 |
| - to add specific help for individual usage. In most embedded |
168 |
| - usages, there are particular restrictions like, "must refer |
169 |
| - only to types A and B" or "UID not honored" or "name must |
170 |
| - be restricted". Those cannot be well described when embedded. |
171 |
| - 3. Inconsistent validation. Because the usages are different, |
172 |
| - the validation rules are different by usage, which makes |
173 |
| - it hard for users to predict what will happen. 4. The fields |
174 |
| - are both imprecise and overly precise. Kind is not a precise |
175 |
| - mapping to a URL. This can produce ambiguity during interpretation |
176 |
| - and require a REST mapping. In most cases, the dependency |
177 |
| - is on the group,resource tuple and the version of the actual |
178 |
| - struct is irrelevant. 5. We cannot easily change it. Because |
179 |
| - this type is embedded in many locations, updates to this |
180 |
| - type will affect numerous schemas. Don''t make new APIs |
181 |
| - embed an underspecified API type they do not control. Instead |
182 |
| - of using this type, create a locally provided and used type |
183 |
| - that is well-focused on your reference. For example, ServiceReferences |
184 |
| - for admission registration: https://github.com/kubernetes/api/blob/release-1.17/admissionregistration/v1/types.go#L533 |
185 |
| - .' |
| 154 | + description: ConfigSecretRef refers to the secret holding |
| 155 | + the URL for Redis. |
186 | 156 | properties:
|
187 | 157 | apiVersion:
|
188 | 158 | description: API version of the referent.
|
@@ -241,6 +211,7 @@ spec:
|
241 | 211 | type: object
|
242 | 212 | type: object
|
243 | 213 | version:
|
| 214 | + description: 'Deprecated: Use Image for specifying image version' |
244 | 215 | type: string
|
245 | 216 | type: object
|
246 | 217 | status:
|
|
0 commit comments