Path for Storage, version bounce

[goern]

• add path to storage requirement
• bounced to version 0.1.0, lets start using semantic versioning!

closed #193

[cdrage]

Version bouncing sounds good to me, lot's have changed since 0.2.0

I agree with the storage requirement, adding in path makes sense. How would it be to implement for kubernetes?

And how do we specify which containers use which volume mounts via the persistent storage integration?

I'm assuming using a volume mount?

POST: 

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - image: nginx
      name: myfrontend
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      source:
        persistentVolumeClaim:
         accessMode: ReadWriteOnce
         claimRef:
           name: myclaim-1

For docker we pass the path and then for openshift it's interconnect with k8s anyways, so no issues there.

[goern]

@cdrage ja, the example looks good to me.

[cdrage]

Okay so this looks good to me.

Although our kubernetes examples people will still have to specify the persistent volume, for ex:

spec:
  containers:
    - image: nginx
      name: myfrontend
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd

The persistent volume requirement that we adding will solve the ability for creating persistent volume claims, but we still will need to declare it (possibly a parameter?) within each container artifact of Kubernetes which claim they will be using.

Perhaps in the future we can actually assign persistent volumes to each nulecule container.

If that makes sense :confused:

[cdrage]

Here's a (future) example were we possibly support a persistent volume per inherited app.

graph:
  - name: mariadb-centos7-atomicapp
    source: docker://projectatomic/mariadb-centos7-atomicapp
    volumes:
     - mariadb

  - name: helloapache-app
    params:
      - name: image
        description: The webserver image
        default: centos/httpd
      - name: hostport
        description: The host TCP port as the external endpoint
        default: 80
    artifacts:
      docker:
        - file://artifacts/docker/hello-apache-pod_run
      kubernetes:
        - file://artifacts/kubernetes/hello-apache-pod.json
      openshift:
        - inherit:
          - kubernetes
      marathon:
        - file://artifacts/marathon/helloapache.json
    volumes:
       - foobar
       - var-log-httpd

requirements:
  - persistentVolume:
      name: "var-log-httpd"
      accessMode: "ReadWriteOnce"
      size: 4
      path: "/var/log/httpd.log"
  - persistentVolume:
      name: "mariadb"
      accessMode: "ReadWriteOnce"
      size: 20
      path: "/database/folder"
  - persistentVolume:
      name: "foobar"
      accessMode: "ReadWriteMany"
      size: 10
      path: "/foo/bar"

[goern]

ja we can, any proposal for a mapping? :)

[cdrage]

    volumes:
       - foobar
       - var-log-httpd

:)

[cdrage]

ping @goern @aweiteka @vpavlin

thoughts on the proposal I posted in the comment above?

[aweiteka]

Looks fine to me.

[cdrage]

Since we're not going to be going further with the storage requirement in Nulecule, should we close this issue?

[goern]

Why should we not declare deployment time requirements of an application within the Nulecule Spec?

[cdrage]

@goern Because Nulecule will be focusing on deployment and distribution rather than implementing requirements such as persistent storage, which will be up to the user to implement.

[goern]

Could you please write up the user stories so that we can figure out what 'deployment' and what 'implement requirements' is

[cdrage]

@dustymabe are you able to help explain to @goern ? I'm not too good at explaining as to what happened at the face-to-face.

Essentially, in regards to Nulecule, we're focusing on the distributing and deployment of applications. Being able to package multi-container applications into one format (whether it is Docker container, .tar.gz, etc.) and being able to launch them.

The persistent storage doesn't fit into this situation and should be left to the user/client to decide what to use.

[cdrage]

Unless I'm wrong and this should stay.. but if it does, we should implement more features other than persistent storage (maybe scaling?) so it's more viable than it is now...

We should discuss this further

[cdrage]

@goern we're you able to understand as to we no longer require the persistent-storage dependency? We can discuss this in the open issue about it :)