Closed kanarip closed 8 years ago
@kanarip sorry for the delayed response. This makes perfect sense.
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
I agree with @goern as that let's us to add f.e. some networking requirements (OpenShift route, Docker networking plugins..) later.
Maybe, what about this:
---
requirements:
- name: "var-lib-mongodb-data"
type: "persistentColume"
properties:
accessMode: "ReadWrite"
size: 4 # GB by default
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
@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
@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.
@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.
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
@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 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?
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.
@aweiteka full_ack for 2. and 1. is solved, isnt it? I simply wait for the RP from @kanarip ;)
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.
I am going to close this issue, as my reply https://github.com/projectatomic/nulecule/issues/181#issuecomment-158149598 is true, the Nulecule Specification 0.0.2 allows (and has json schema definition to formally validate) what @kanarip asked for.
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