Open goern opened 8 years ago
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.
@cdrage ja, the example looks good to me.
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:
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"
ja we can, any proposal for a mapping? :)
volumes:
- foobar
- var-log-httpd
:)
ping @goern @aweiteka @vpavlin
thoughts on the proposal I posted in the comment above?
Looks fine to me.
Since we're not going to be going further with the storage requirement in Nulecule, should we close this issue?
Why should we not declare deployment time requirements of an application within the Nulecule Spec?
@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.
Could you please write up the user stories so that we can figure out what 'deployment' and what 'implement requirements' is
@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.
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
@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 :)
closed #193