Persistent storage types

[cdrage]

This is a tentative issue / discussion for persistent storage as well as persistent storage types as a continuation of issue #181

@goern
I agree with you in regards to

volumeType: "nfs"
       volumeArgs:
           path: /tmp
           server: 10.10.10.10

being deleted from

---
requirements:
  -  name: "var-lib-mongodb-data"
     type: "persistentVolume"
     properties:
       accessMode: "ReadWrite"
       size: 4 # GB by default
       volumeType: "nfs"
       volumeArgs:
           path: /tmp
           server: 10.10.10.10

We assume that the user has already configured what type of storage they'd like to use (nfs, gce, etc.), we shouldn't have to add it to Nulecule, but rather answers.conf.

[goern]

It might even be three roles:

1. software vendor, packaging everything up to be deployed on kube and openshift
2. deployment guy providing answers.conf, setting the size to 6GiB
3. platform guy running openshift and making the decision that storage will come from AWS

[goern]

Next think I see is a route object for OpenShift, if we want to expose a service via a URL, we could simply add

---
requirements:
  - type: "route"
    hostname: "www.acme.example.com"
    service: "service-name"

An implementation like Atomic App could generate an OpenShift route configuration from that:

---
apiVersion: v1
kind: Route
metadata:
  name: host-route
spec:
  host: www.acme.example.com  
  to:
    kind: Service
    name: service-name

[vpavlin]

From my pov, I as a developer don't care about the type of underlying storage type (f.e. nfs). So this doesn't belong to the spec.

@goern is right about other types - that was what I was trying to suggest in previous discussion (thanks for clarification;)

How do we make size amendable via answers.conf?

[cdrage]

Talked about this with @goern and concluded that atomicapp should not know on the underlying storage and should let the underlying provider take care of that (take from a storage pool already configured, etc.)

So what should be the final format?

requirements:
  -  name: "var-lib-mongodb-data"
     type: "persistentVolume"
     properties:
       accessMode: "ReadWrite"
       size: 4 # GB by default

as suggested by @dustymabe ?

our current format in the spec is:

requirements: 
  - persistentVolume: 
      accessMode: ReadWrite
      name: var-lib-data
      size: 4

[vpavlin]

What if we do s/properties/params and then make them modifiable via answers file? Would that bring too much confusion?:-)

[goern]

From my point of view, persistentVolume requirement of the Nulecule is a request or prerequisite of the application (stated by the ISV how nuleculized the application): "I application need 4GiB of persistent volume". The platform provider or the deployment guy is always free to provision more storage to the application. So @vpavlin why do we want to have the bare minimum required by the application be modifiable by the deployment gut, as the platform operator may provide more storage anyways!?

[vpavlin]

I don't know...it was just a random idea..maybe because params would make sense for other types of requirements (like routes)?

[aweiteka]

Per my comment there's a gap in that the app needs to mount the volume at some path. So this only solves half of the problem. The orchestration artifact basically solves this problem already. I'm not sure how to abstract this concept any further, or what value it provides. It does sound nice to simply say, "My app needs storage at this path. Please take care of the details."

[dustymabe]

So should we add a path property to persistent volume? https://github.com/projectatomic/nulecule/blob/master/spec/requirements/persistentvolume.json

The only other way I see mapping it out is to have volumes be discoverable like services so that a volume with a name gets mounted at a configurable location.. but I don't think that is something we want to try to do right now.

[aweiteka]

So should we add a path property to persistent volume? https://github.com/projectatomic/nulecule/blob/master/spec/requirements/persistentvolume.json

After discussion with @goern I'm revising my thoughts on this: the application artefact will define how it wants to use the volume, where it should be mounted. We don't need to provide a path in the spec.

[jberkus]

Regarding the path: we may say that the provider should define the path for the host/network, but the app spec should provide the path inside the container, since that is a requirement of the app.

For example, if I need persistentStorage for my PostgreSQL database app, then I need to be able to specify that that storage should be mounted inside the container at /var/pgsql/data. The Nulecule file is the appropriate place to do this, not the provider files, because that storage is going to be at /var/pgsql/data inside the container regardless of how the host is providing it.

[jberkus]

so that would make the new format:

requirements: 
  - persistentVolume: 
      accessMode: ReadWrite
      name: var-lib-data
      size: 4
      path: /var/lib/data

where "path" is the path inside the container.

[dustymabe]

@aweiteka @goern @cdrage ^^. Let's flesh this out and get it settled.

[goern]

@jberkus you are right for some cases, it could be clever to bind that volume to a specific path within the container/application context. I would make it a required attribute.

In any way we can have a path attribute within the persistentVolume object without changing the spec (as you are free to add whatever you want to the yaml), while defining its meaning/semantics in the Atomic App context.

[dustymabe]

@aweiteka @goern @cdrage ^^. Let's flesh this out and get it settled.

Meant to also add @vpavlin

@jberkus you are right for some cases, it could be clever to bind that volume to a specific path within the container/application context. I would make it a required attribute.

So we should add it as a required attribute?

In any way we can have a path attribute within the persistentVolume object without changing the spec (as you are free to add whatever you want to the yaml), while defining its meaning/semantics in the Atomic App context.

I'd rather not deviate too much from the spec. This becomes a management headache in the future.

[goern]

uh oh... sorry, _wouldn't_ make it a required attribute

ACK, so I'll have a look at it early next week, or you send in a PR?

[dustymabe]

@goern if you don't have something by early next week then please send a PR yourself.

@cdrage, can we get the ball rolling on adding support for this to Atomic App? And we really need to get some of our Nulecule Library examples to show off this feature.

[cdrage]

@goern Were you able to have a look at this? :)

Going forward once we have this finalized I can implement this into atomicapp, especially since this would particular help with implement persistent storage for the docker and openshift providers.