An application may or may not include builds. It may or may not include images, secrets, config, or persistent volumes. As Aaron noted, there may be multiple per project. Some level of curation by the user is required - there is no "one application" defined, unfortunately. An admin may use two sets of labels, that overlap, but which identify which parts of a larger app are sub projects.
As a convention, apps are created from oc new-app with the label "app=NAME" set, but that is not a hard requirement. On Mon, Mar 14, 2016 at 2:11 PM, Aaron Weitekamp <aweit...@redhat.com> wrote: > On Mon, Mar 14, 2016 at 1:10 PM, Tomas Kral <tk...@redhat.com> wrote: >> >> Thank you, that makes sense, but this is also what was afraid of :( >> >> We want to be able to export any arbitrary application that we know >> nothing about :( >> Now we need to figure out which object were generated by OpenShift >> internally and which one were created by developer. > > > You're introducing an additional requirement. :) Can you confirm the initial > problem is resolved? > > If you're comfortable with exporting everything in a project then replace > "all" with the set of resources Clayton listed. It is dangerously > presumptive that there's only one "application" in a project. You may export > unexpected objects depending on what the user has deployed in the project. > >> >> I can see that ReplicationController that is generated by >> DeploymentConfig has annotation 'openshift.io/deployment-config.name: >> ...' and same apply for its Pods. >> >> For Pod that was created by ReplicationController (that is not from >> DeploymentConfig) I see annotation 'kubernetes.io/created-by: ...' >> >> Can we rely on those annotations to decide what to export and what to >> leave behind? Is this documented somewhere? >> >> >> >> >> On 03/14/2016 04:48 PM, Clayton Coleman wrote: >> > Export is a lower level tool that does not *exactly* export an entire >> > application, but rather tries to give you the tools to build it. >> > >> > I would suggest instead of running "oc export all", you try "oc export >> > dc,svc,route,is". "all" includes pods, replication controllers, >> > build configs, and builds, some of which you do not need. We expect >> > at some point in the future to have a higher level "export-app" >> > command, but when you export you need to determine what you want to >> > copy over and what you want to leave behind. >> > >> > On Mon, Mar 14, 2016 at 11:13 AM, Tomas Kral <tk...@redhat.com> wrote: >> >> Hi all, >> >> I'm working on project where we are basically using `oc export` for >> >> exporting project and importing it to another OpenShift instance. >> >> >> >> But it is not working as I would expect. >> >> >> >> My understanding of export feature is that it can be used to move >> >> objects between clusters or projects and I can use `oc export all` to >> >> move/copy whole project. >> >> >> >> I've deployed MLB Parks sample application >> >> (https://github.com/gshipley/openshift3mlbparks) >> >> >> >> Then I'm trying to move it to another project on same cluster using >> >> command: >> >> >> >> oc -n mlbparks export all | oc -n import create -f - >> >> >> >> >> >> But I get following errors: >> >> >> >> Error from server: replicationControllers "mongodb-1" already exists >> >> Error from server: Pod "mlbparks-1-build" is forbidden: unable to >> >> validate against any security context constraint: ...... >> >> >> >> Rest of the error and all steps that I'm doing are here: >> >> http://paste.fedoraproject.org/339618/96469114/ >> >> >> >> >> >> I'm running Origin v1.1.1 >> >> >> >> >> >> Is there something that is fundamentally wrong with my understanding of >> >> `oc export`? >> >> >> >> >> >> -- >> >> Tomas >> >> >> >> _______________________________________________ >> >> dev mailing list >> >> dev@lists.openshift.redhat.com >> >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> _______________________________________________ >> dev mailing list >> dev@lists.openshift.redhat.com >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > > _______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
