Bug 1342606
| Summary: | oc delete all --all does not delete configmaps | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Erik M Jacobs <ejacobs> |
| Component: | oc | Assignee: | Fabiano Franz <ffranz> |
| Status: | CLOSED WONTFIX | QA Contact: | Xingxing Xia <xxia> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.2.0 | CC: | aos-bugs, ccoleman, jokerman, mmccomas |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-07-22 18:46:24 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Erik M Jacobs
2016-06-03 16:15:22 UTC
Clayton, do we want to fix this? There are also other resources that are not part of 'all' in `delete` and `get`, like pvcs and templates. pvcs and templates are intentionally not part of all. secrets are intentionally not part of all. Configmaps being part of all is probably ok, but we'd need to clarify why it's ok to delete configmaps but not secrets. Why is anything intentionally not part of all? The only reason to not make something part of all is because we are silly and don't have a confirm dialogue for --all. --all should delete ALL, otherwise we need to clearly, painfully and explicitly document what is NOT deleted by --all and then we should probably additionally provide --really-all or some flag that can actually delete all the things. As per the following upstream discussion, ConfigMaps are not going to be added to 'all' because if deleted it's potentially unrecoverable: https://github.com/kubernetes/kubernetes/pull/28955#issuecomment-232737113 Adding Clayton here to further comments if needed. |