[epic] Adding metadata to each deployment (docker, kubernetes, openshift).

[cdrage]

This will pave the way for using:

• atomicapp ps
• atomicapp stop {id}
• ID's for each atomicapp deployment

Without the need of supplying an atomicapp generated directory.

So without further ado! Let's get a spec / plan formulated!

Providers supported with metadata:

docker:

docker run \
   -d \
   --label com.example.group="webservers" \
   --label com.example.environment="production" \
   busybox \
   top

kubernetes:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx

openshift: same as k8s^^^

marathon: ????

Proposed labels (what comes first to my head) examples:

com.atomicapp.spec="0.0.2"
com.atomicapp.version="0.4.3"
com.atomicapp.app.version="0.0.1"
com.atomicapp.app.name="foobar"
com.atomicapp.app.description="my foobar"
com.atomicapp.app.provider="kubernetes"
com.atomicapp.app.created_at = 1458316146 # epoch time
com.atomicapp.app.id="3ff3af615073" # unique UID using current utils.py command

[cdrage]

So one day we can have this (rough example):

▶ atomicapp ps
ATOMICAPP ID        IMAGE               PROVIDER                  CREATED             STATUS                              NAMES       IMAGES
2e988ed4a501        atomicapp-foobar    kubernetes          21 minutes ago      Online        default_centos-httpd_959aa1878a69          {mariadb, redis, nginx}

[surajssd]

Awesome +1

[concaf]

+1, yay! Unblocks #628

[cdrage]

@containscafeine

Indeed it does!

Can I have your input @surajssd and @containscafeine in regards to labels? Any that you two can think of that we should add / the format?

[concaf]

@cdrage All the labels you listed LGTM! How about having a com.atomicapp.app.endpoints=IP:Port label too?

[cdrage]

@containscafeine k8s or openshift should handle that :)

[concaf]

@cdrage okay, so do we ask k8s/openshift for the endpoints available each time the command is run or do we fetch that from the Nulecule file?

[kadel]

marathon: ????

Marathon has also labels that are similar to labels in other providers: https://mesosphere.github.io/marathon/docs/generated/api.html#v2_apps_post

Similarly to k8s you can query apps by label: https://mesosphere.github.io/marathon/docs/generated/api.html#v2_apps_get

[dustymabe]

hey @cdrage. How do we "discover" what apps are running?

[cdrage]

@dustymabe Once labels are implement we can poll the docker, openshift and kubernetes providers via their restful APIs.

We'll have to come up a way in the future to neatly warn (non-ui intrusive) if we are unable to connect to a respective provider (ex. docker is up, but k8s api is down). But this has to be subtle as to not discourage users in the UI :)

[dustymabe]

@dustymabe Once labels are implement we can poll the docker, openshift and kubernetes providers via their restful APIs.

The problem with this is that we allow each deployment to specify a different endpoint if they want to. So I could deploy one app to one kubernetes cluster and another app to an openshift cluser and another app to a 2nd kubernetes cluster, etc.. So you have to know how to communicate with the endpoints and that's not something you can just pick up from the environment. You need to look at the answers.conf.gen for each application.

[cdrage]

@dustymabe

Yeah, that'll be the difficult part, being able to list remote hosts / different environments.

What I would like to do is implement a local solution to query localhost API end-points (for now) and then in the future take the challenge to implement to listing remote end-points. This would be similar to how docker-machine stores certs to remove docker instances in order to query / list them all.

[concaf]

So you have to know how to communicate with the endpoints and that's not something you can just pick up from the environment. You need to look at the answers.conf.gen for each application.

What I would like to do is implement a local solution to query localhost API end-points (for now) and then in the future take the challenge to implement to listing remote end-points.

@dustymabe @cdrage Is it possible that we get the endpoints' information from the Nulecule/answers file, and just try to make a connection to those endpoints using telnet or curl, and return a +1 or -1 accordingly. Am I missing something?

[cdrage]

@containscafeine Using the .kube/config file would be the most viable.

Another is yes, through the Nulecule/answers file, but (in my opinion) parsing the entire /var/lib/atomicapp directory for that information would be a bad idea.

[concaf]

parsing the entire /var/lib/atomicapp directory for that information would be a bad idea.

@cdrage When an app in launched, we map the app.id with its endpoints. When that app.id is queried, we can make connection to those mapped endpoints and see if they are accessible or not. Do we need /var/lib/atomicapp for this?

[cdrage]

@containscafeine Querying a providers API end-point would be better than using /var/lib/atomicapp since /var/lib/atomicapp changes on each system as well as the fact that if the person has a k8s or openshift hosted remotely that had an atomicapp deployed to it from a different user :)

This is going to be a challenge. But a fun one! Figuring out about each host will be interesting. Parsing .kube/config will be a good start.