"all" was originally chosen as a shortcut to "things that you probably want to delete most of the time". RCs and pods and builds probably no longer fit under that definition, specifically because they are correctly cleaned up by other components when they are deleted. Or we could contextualize all in the export context or come up with a new sub option. David's suggestion is the easiest today.
On Feb 16, 2016, at 8:02 AM, David Eads <[email protected]> wrote: If you only want a subset of things, you can enumerate them: `oc export bc,dc,is,istag,svc` as a for instance. That will export all buildconfigs, deploymentconfigs, etc On Tue, Feb 16, 2016 at 4:13 AM, Candide Kemmler <[email protected]> wrote: > I'm now starting to be happy about my deployment. My next ambition is to > be able to replicate it easily. So I'm trying to write a template and I had > hoped to get started with the `oc export all` command. However, this gives > me a list of a gazillion objects among which things like Builds and > Replication Controllers and Pods which are things that I think were > automatically created for me as I deployed the individual pieces separately. > > Is there a way to "smart" export objects in a project or is at least are > there some guidelines on how/what to filter out of what's generated by `oc > export all`? > > _______________________________________________ > users mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users > _______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
