Why are PersistentVolumeClaims treated specially by some OpenShift commands
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Why does the scope oc get all (and oc delete all --all) in OpenShift 3.10 not include components of type PersistentVolumeClaim as well? A separate oc get pvc (and oc delete pvc --all) is required.
Is there a particular reason for treating these objects special? (Apparently they are only special in some regards; for instance, application templates can create them quite normally along with other components.)
Update Components of type Secret are also treated special in a perhaps similar way and for similar reasons. One reason I can think of is that these components typically may have longer lifetimes than applications.
openshift
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
add a comment |
Why does the scope oc get all (and oc delete all --all) in OpenShift 3.10 not include components of type PersistentVolumeClaim as well? A separate oc get pvc (and oc delete pvc --all) is required.
Is there a particular reason for treating these objects special? (Apparently they are only special in some regards; for instance, application templates can create them quite normally along with other components.)
Update Components of type Secret are also treated special in a perhaps similar way and for similar reasons. One reason I can think of is that these components typically may have longer lifetimes than applications.
openshift
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
Havingallmap to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really useoc delete all --allas too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…
– Graham Dumpleton
Nov 23 '18 at 20:06
Whoops, that should have been "you should not really useoc delete all --all".
– Graham Dumpleton
Nov 24 '18 at 4:01
@GrahamDumpleton Yes, I am actually usingoc delete all --selector app=<app>in cases when I want to delete all.
– rookie099
Nov 24 '18 at 5:08
1
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...afterallinoc get all,...oroc delete all,... --selector=<...> -n <project>
– apisim
Nov 26 '18 at 3:35
add a comment |
Why does the scope oc get all (and oc delete all --all) in OpenShift 3.10 not include components of type PersistentVolumeClaim as well? A separate oc get pvc (and oc delete pvc --all) is required.
Is there a particular reason for treating these objects special? (Apparently they are only special in some regards; for instance, application templates can create them quite normally along with other components.)
Update Components of type Secret are also treated special in a perhaps similar way and for similar reasons. One reason I can think of is that these components typically may have longer lifetimes than applications.
openshift
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
Why does the scope oc get all (and oc delete all --all) in OpenShift 3.10 not include components of type PersistentVolumeClaim as well? A separate oc get pvc (and oc delete pvc --all) is required.
Is there a particular reason for treating these objects special? (Apparently they are only special in some regards; for instance, application templates can create them quite normally along with other components.)
Update Components of type Secret are also treated special in a perhaps similar way and for similar reasons. One reason I can think of is that these components typically may have longer lifetimes than applications.
openshift
openshift
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
edited Nov 23 '18 at 15:08
rookie099
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
asked Nov 23 '18 at 14:31
rookie099rookie099
519111
519111
Havingallmap to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really useoc delete all --allas too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…
– Graham Dumpleton
Nov 23 '18 at 20:06
Whoops, that should have been "you should not really useoc delete all --all".
– Graham Dumpleton
Nov 24 '18 at 4:01
@GrahamDumpleton Yes, I am actually usingoc delete all --selector app=<app>in cases when I want to delete all.
– rookie099
Nov 24 '18 at 5:08
1
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...afterallinoc get all,...oroc delete all,... --selector=<...> -n <project>
– apisim
Nov 26 '18 at 3:35
add a comment |
Havingallmap to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really useoc delete all --allas too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…
– Graham Dumpleton
Nov 23 '18 at 20:06
Whoops, that should have been "you should not really useoc delete all --all".
– Graham Dumpleton
Nov 24 '18 at 4:01
@GrahamDumpleton Yes, I am actually usingoc delete all --selector app=<app>in cases when I want to delete all.
– rookie099
Nov 24 '18 at 5:08
1
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...afterallinoc get all,...oroc delete all,... --selector=<...> -n <project>
– apisim
Nov 26 '18 at 3:35
Having
all map to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really use oc delete all --all as too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…– Graham Dumpleton
Nov 23 '18 at 20:06
Having
all map to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really use oc delete all --all as too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…– Graham Dumpleton
Nov 23 '18 at 20:06
Whoops, that should have been "you should not really use
oc delete all --all".– Graham Dumpleton
Nov 24 '18 at 4:01
Whoops, that should have been "you should not really use
oc delete all --all".– Graham Dumpleton
Nov 24 '18 at 4:01
@GrahamDumpleton Yes, I am actually using
oc delete all --selector app=<app> in cases when I want to delete all.– rookie099
Nov 24 '18 at 5:08
@GrahamDumpleton Yes, I am actually using
oc delete all --selector app=<app> in cases when I want to delete all.– rookie099
Nov 24 '18 at 5:08
1
1
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...after
all in oc get all,... or oc delete all,... --selector=<...> -n <project>– apisim
Nov 26 '18 at 3:35
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...after
all in oc get all,... or oc delete all,... --selector=<...> -n <project>– apisim
Nov 26 '18 at 3:35
add a comment |
1 Answer
1
active
oldest
votes
I have by now concluded (also from the comments received) that is behavior is intended by design to guard against accidental deletions of dear persistent storage whose lifetime may substantially exceed single (versions of) applications.
As a consequence, I have now refactored the application template a bit. So far, a single template (YAML file) was in charge of creating all components (except secrets). This led to an "unbalanced" situation which required one oc new-app --template=app to create the app, but two oc deletes (oc delete all --selector app=... and oc delete pvc --selector app=..) to delete entirely. After splitting up the template into app.yaml and yaml.yaml the new, "balanced" arrangement is like this:
# create app (including its persistent storage)
oc new-app --template=app
oc new-app --template=pvc
# delete app (including its persistent storage)
oc delete all --selector app=...
oc delete pvc --selector app=...
I still leave secrets out of this scope and create them with oc create secret once up front.
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53448560%2fwhy-are-persistentvolumeclaims-treated-specially-by-some-openshift-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I have by now concluded (also from the comments received) that is behavior is intended by design to guard against accidental deletions of dear persistent storage whose lifetime may substantially exceed single (versions of) applications.
As a consequence, I have now refactored the application template a bit. So far, a single template (YAML file) was in charge of creating all components (except secrets). This led to an "unbalanced" situation which required one oc new-app --template=app to create the app, but two oc deletes (oc delete all --selector app=... and oc delete pvc --selector app=..) to delete entirely. After splitting up the template into app.yaml and yaml.yaml the new, "balanced" arrangement is like this:
# create app (including its persistent storage)
oc new-app --template=app
oc new-app --template=pvc
# delete app (including its persistent storage)
oc delete all --selector app=...
oc delete pvc --selector app=...
I still leave secrets out of this scope and create them with oc create secret once up front.
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
add a comment |
I have by now concluded (also from the comments received) that is behavior is intended by design to guard against accidental deletions of dear persistent storage whose lifetime may substantially exceed single (versions of) applications.
As a consequence, I have now refactored the application template a bit. So far, a single template (YAML file) was in charge of creating all components (except secrets). This led to an "unbalanced" situation which required one oc new-app --template=app to create the app, but two oc deletes (oc delete all --selector app=... and oc delete pvc --selector app=..) to delete entirely. After splitting up the template into app.yaml and yaml.yaml the new, "balanced" arrangement is like this:
# create app (including its persistent storage)
oc new-app --template=app
oc new-app --template=pvc
# delete app (including its persistent storage)
oc delete all --selector app=...
oc delete pvc --selector app=...
I still leave secrets out of this scope and create them with oc create secret once up front.
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
add a comment |
I have by now concluded (also from the comments received) that is behavior is intended by design to guard against accidental deletions of dear persistent storage whose lifetime may substantially exceed single (versions of) applications.
As a consequence, I have now refactored the application template a bit. So far, a single template (YAML file) was in charge of creating all components (except secrets). This led to an "unbalanced" situation which required one oc new-app --template=app to create the app, but two oc deletes (oc delete all --selector app=... and oc delete pvc --selector app=..) to delete entirely. After splitting up the template into app.yaml and yaml.yaml the new, "balanced" arrangement is like this:
# create app (including its persistent storage)
oc new-app --template=app
oc new-app --template=pvc
# delete app (including its persistent storage)
oc delete all --selector app=...
oc delete pvc --selector app=...
I still leave secrets out of this scope and create them with oc create secret once up front.
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
I have by now concluded (also from the comments received) that is behavior is intended by design to guard against accidental deletions of dear persistent storage whose lifetime may substantially exceed single (versions of) applications.
As a consequence, I have now refactored the application template a bit. So far, a single template (YAML file) was in charge of creating all components (except secrets). This led to an "unbalanced" situation which required one oc new-app --template=app to create the app, but two oc deletes (oc delete all --selector app=... and oc delete pvc --selector app=..) to delete entirely. After splitting up the template into app.yaml and yaml.yaml the new, "balanced" arrangement is like this:
# create app (including its persistent storage)
oc new-app --template=app
oc new-app --template=pvc
# delete app (including its persistent storage)
oc delete all --selector app=...
oc delete pvc --selector app=...
I still leave secrets out of this scope and create them with oc create secret once up front.
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
answered Nov 26 '18 at 8:46
rookie099rookie099
519111
519111
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53448560%2fwhy-are-persistentvolumeclaims-treated-specially-by-some-openshift-commands%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Having
allmap to all component types would be dangerous, so good that it doesn't and it only refers to the few that it does. Also, you should really useoc delete all --allas too much risk of deleting stuff you didn't mean to. Learn to use labels and then use a selector when deleting things. See cookbook.openshift.org/working-with-resource-objects/…– Graham Dumpleton
Nov 23 '18 at 20:06
Whoops, that should have been "you should not really use
oc delete all --all".– Graham Dumpleton
Nov 24 '18 at 4:01
@GrahamDumpleton Yes, I am actually using
oc delete all --selector app=<app>in cases when I want to delete all.– rookie099
Nov 24 '18 at 5:08
1
It is not (completely?) OpenShift's fault. This is "inherited" from Kubernetes. There are few discussions, like this one here - github.com/kubernetes/kubectl/issues/151. I remember having to list explicitly secrets, sa, templates, configmaps...after
allinoc get all,...oroc delete all,... --selector=<...> -n <project>– apisim
Nov 26 '18 at 3:35