You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -135,15 +133,6 @@ was due to something on the client side (like a missing flag, an invalid yaml fi
135
133
is due to some invalid operation on the server side.
136
134
137
135
138
-
### Notes/Constraints/Caveats (Optional)
139
-
140
-
<!--
141
-
What are the caveats to the proposal?
142
-
What are some important details that didn't come across above?
143
-
Go in to as much detail as necessary here.
144
-
This might be a good place to talk about core concepts and how they relate.
145
-
-->
146
-
147
136
### Risks and Mitigations
148
137
149
138
* Users already relying on specific error codes might face migration problems / false positives or negatives
@@ -292,24 +281,28 @@ Not applicable, as this is just a kubectl change
292
281
###### How can this feature be enabled / disabled in a live cluster?
293
282
294
283
295
-
-[X] Feature gate (also fill in values in `kep.yaml`)
296
-
- Feature gate name: ENV VAR `KUBECTL_ERROR_CODES`
297
-
284
+
-[X] Other
285
+
- Describe the mechanism: Environment Variable `KUBECTL_ERROR_CODES`
286
+
- Will enabling / disabling the feature require downtime of the control plane?
287
+
No
288
+
- Will enabling / disabling the feature require downtime or reprovisioning of a node?
289
+
No
298
290
###### Does enabling the feature change any default behavior?
299
291
300
-
Yes, kubectl exit codes numbers will change after the FG is enabled
292
+
Yes, kubectl exit codes numbers will change after the Environment variable is set
301
293
302
294
###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
303
295
304
-
Yes, just remove the Env Var.
296
+
Yes, just remove the Environment Variable.
305
297
306
298
###### What happens if we reenable the feature if it was previously rolled back?
307
299
308
300
kubectl will start issuing different and standardized exit codes again when errors occurs.
309
301
310
302
###### Are there any tests for feature enablement/disablement?
311
303
312
-
No.
304
+
A test simulating an error can be created, and check a return code
305
+
so we can assert if the enablement is working.
313
306
314
307
### Rollout, Upgrade and Rollback Planning
315
308
@@ -336,11 +329,15 @@ No
336
329
337
330
Not applicable
338
331
339
-
###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
332
+
###### How can someone using this feature know that it is working for their instance?
333
+
-[X] Other
334
+
- Details: There are some situations today were exit codes are not returned correctly. Knowing this situations, someone can test whether the expected exit code was returned given a well known situation.
335
+
336
+
###### What are the reasonable SLOs (Service Level Objectives) for the enhancement?
340
337
341
338
Not applicable
342
339
343
-
###### What are the reasonable SLOs (Service Level Objectives) for the above SLIs?
340
+
###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
344
341
345
342
Not applicable
346
343
@@ -400,9 +397,7 @@ Not applicable
400
397
401
398
## Drawbacks
402
399
403
-
<!--
404
-
Why should this KEP _not_ be implemented?
405
-
-->
400
+
N/A
406
401
407
402
## Alternatives
408
403
@@ -411,11 +406,3 @@ What other approaches did you consider, and why did you rule them out? These do
411
406
not need to be as detailed as the proposal, but should include enough
412
407
information to express the idea and why it was not acceptable.
413
408
-->
414
-
415
-
## Infrastructure Needed (Optional)
416
-
417
-
<!--
418
-
Use this section if you need things from the project/SIG. Examples include a
419
-
new subproject, repos requested, or GitHub details. Listing these here allows a
420
-
SIG to get the process for these resources started right away.
0 commit comments