Clarification : purpose of the odo's application

[cmoulliard]

What is the purpose of the odo's application ? To group related components of an application deployed into a k8s namespace ?

If this is the correct definition, why are the components related to an application not added to the application definition created within ~/.kube/odo file

Scenario played

odo application create app1
cat ~/.kube/odo
activeApplications:
- active: true
  activeComponent: ""
  name: app1
  project: myproject

odo create nodejs comp1
Please wait, creating comp1 component ...
Component 'comp1' was created and port 8080/TCP was opened
To push source code to the component run 'odo push'

Component 'comp1' is now set as active component.

odo list
ACTIVE     NAME      TYPE
*          comp1     nodejs

BUT

cat ~/.kube/odo
activeApplications:
- active: true
  activeComponent: comp1
  name: app1
  project: myproject

odo create nodejs comp2
Please wait, creating comp2 component ...
Component 'comp2' was created and port 8080/TCP was opened
To push source code to the component run 'odo push'

Component 'comp2' is now set as active component.

odo list
ACTIVE     NAME      TYPE
           comp1     nodejs
*          comp2     nodejs

2 components have been created but odo's application file only contains the following info
about active component but not all components related to the application

cat ~/.kube/odo
activeApplications:
- active: true
  activeComponent: comp2
  name: app1
  project: myproject

[cmoulliard]

Why don't you store the composition info within the odo's file ? How can we re-install or move the application to another cluster/namespace if we don't have this info ?

cat ~/.kube/odo
activeApplications:
- active: true
  activeComponent: comp2
  name: app1
  project: myproject

oc get dc/comp1-app1 -o yaml
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  annotations:
    app.kubernetes.io/component-source-type: local
    app.kubernetes.io/url: file:///Users/dabou/Temp/to-be-deleted/nodejs-ex
  creationTimestamp: 2018-09-04T09:42:44Z
  generation: 2
  labels:
    app: app1
    app.kubernetes.io/component-name: comp1
    app.kubernetes.io/component-type: nodejs
    app.kubernetes.io/component-version: latest
    app.kubernetes.io/name: app1
  name: comp1-app1
  namespace: myproject

oc get dc/comp2-app1 -o yaml
apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  annotations:
    app.kubernetes.io/component-source-type: local
    app.kubernetes.io/url: file:///Users/dabou/Temp/to-be-deleted/nodejs-ex
  creationTimestamp: 2018-09-04T09:52:12Z
  generation: 2
  labels:
    app: app1
    app.kubernetes.io/component-name: comp2
    app.kubernetes.io/component-type: nodejs
    app.kubernetes.io/component-version: latest
    app.kubernetes.io/name: app1
  name: comp2-app1
  namespace: myproject

[dgolovin]

My guess composition is stored in labels app: app1. To get components for application would require to run
oc get dc -l='app==app1'

Application name is used as a value of app label for component related resources.

[kadel]

If this is the correct definition, why are the components related to an application not added to the application definition created within ~/.kube/odo file

~/.kube/odo stores only information about the active application and active project nothing more. There are no application definitions or component definition in that file. All component definitions including to what application they belong to are stored in cluster inside OpenShift resources

If you want to export component you could do something like this:

oc get --export dc,route,is,pvc -o yaml -l app.kubernetes.io/component-name=mysb -l app.kubernetes.io/name=myapp

this will dump all resources related to mysb component in myapp application

But of course this is not ideal, as this is just reserves, the component has also data inside PVC, and those won't be exported. That is not easy to do.

[jorgemoralespou]

I think that current scope for odo is not to architect applications or be used for the outer cycle, but mostly only for the inner cycle, which means that you would not move applications from a cluster to a different cluster using odo. This will probably change in the future, but I would think that's long term goal.

Also, .kube/odo file will change when configuration proposal get implemented.

And there are some things that in the long run will also affect this behavior:

• server side odo (controller, operator, or however you want to call it)
• application CRD definition

I wouldn't get too much ahead of what should be done in the short run.

[kadel]

stale discussion