Array rather than Object for persistentVolume

[kanarip]

In the example for Storage Requirement Objects, the persistentVolume entries seems to be an object, but may need to be or become an array -- so multiple persistentVolumes could be specified:

https://github.com/projectatomic/nulecule/tree/master/spec#storage-requirement-example

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

  {
    "persistentVolume": [
      {
        "name": "var-lib-mongodb-data",
        "accessMode": "ReadWrite",
        "size": 4
      },
      {
        "name": "var-log-mongodb",
        "accessMode": "ReadWrite",
        "size": 4
      }
    ]
  }

[aweiteka]

@kanarip sorry for the delayed response. This makes perfect sense.

[goern]

The flow of thoughts was more like an application has a list of requirements. By now we only have one type of a requirements defined: a storage requirement.

So it would be:

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

[vpavlin]

I agree with @goern as that let's us to add f.e. some networking requirements (OpenShift route, Docker networking plugins..) later.

[vpavlin]

Maybe, what about this:

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

[vpavlin]

Sorry, I didn't meant to close it at all:/

And btw, what about this structure:

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

[cdrage]

@vpavlin I agree with type. There's quite a few different types in Kubernetes as well as OpenShift and having that as an option needs to be addressed.

For example, this is what Kubernetes and OpenShift supports:

GCEPersistentDisk
AWSElasticBlockStore
NFS
iSCSI
RBD (Ceph Block Device)
Glusterfs
HostPath (single node testing only)

And Docker:

Blockbridge
Ceph
ClusterHQ
EMC
Portworx

[kanarip]

@cdrage Is the type of underlying storage to use not environment specific, and therefore a question regardless? How would a storage type in a Nulecule application translate to deployment?

I think @vpavlin meant to suggest the requirement is marked as being of a type: PersistentVolume rather than a requirement for a PersistentVolume to use a particular underlying storage type.

[cdrage]

@kanarip you hit the nail on the coffin in regards to why it should be implemented. Yes, it is environment specific, however, if type was not included, Nulecule / Atomic App would not have a clue in regards of implementing persistent storage, by default it would most likely use HostPath or NFS. By providing a type, the Kuberneters or OpenShift provider within Nulecule will deploy that specific persistent storage.

[cdrage]

I think this will take more thought into how we are able to implement said persistent storage.. As usually you provide this within the specific Kubernetes / OpenShift artifact file.

EDIT, ex:

requirements:
  -  name: "var-lib-mongodb-data"
     properties:
       type: "nfs"
       accessMode: "ReadWrite"
       size: 4
     nfs:
        path: /tmp
        server: 10.10.10.10

ping @aweiteka @goern for thoughts

[dustymabe]

@cdrage I think what they were trying to say is lets have the requirements section apply to more than just persistent volumes. Your point is still valid though because you are saying that we need to be able to specify what type of persistent volume to apply.

Maybe something like this would work:

---
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

But then the user could use something like this if they didn't care what type of persistent storage it was:

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

[aweiteka]

1. We've taken @kanarip 's simple request to allow for a list of storage objects and turned it into an larger architectural discussion on the limitations of our spec. His request is a simple one. Could we make a simple update to the spec?
2. Storage requirements are just one of many things an application might need. Why don't we start a new thread to discuss "all the things"? Then we have an opportunity to discover a useful abstraction model to deal with service requirements, etc. and begin to address service discovery and all of that interesting stuff.

[dustymabe]

@aweiteka right. so you are saying for the sake of this issue let's just take what we have and make it an array and we can open a separate issue to docuement architecture for broader requirements.

@cdrage ^^ thoughts?

[goern]

We should avoid implementation specific details in a declaration of requirements, as that implies a certain way to implement things and takes away freedom from the implementator/plattform/provider. Having said that, I would delete

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

The application should really dont care how I do provide 4GiB of R/W storage. If these details are required by the provider as input, they should be in answers.conf so that they can be set at deployment time.

[goern]

@aweiteka full_ack for 2. and 1. is solved, isnt it? I simply wait for the RP from @kanarip ;)

[cdrage]

Continued in #193 :) let's keep the discussion there in relation to type and array stuff here. But I agree that we should have arrayed volumes in our spec.

[goern]

I am going to close this issue, as my reply #181 (comment) is true, the Nulecule Specification 0.0.2 allows (and has json schema definition to formally validate) what @kanarip asked for.