Persistent volume on kubernetes?

[nonotest]

ISSUE TYPE

• Feature Idea

  SUMMARY

Hello,

This feature idea is mainly for kubernetes, not sure about openstack.

I am not sure if I missed out some options but it looks like there is no support for persistent volumes?

It would be great if we could have shipit support for:

• gcePersistentDisk
• awsElasticBlockStore
• flocker
• ...

for example?

It seems at the moment only hostPath and emptyDir are supported?

Thanks!

[evuolas]

Any plans for this?

I'm currently manually edited main.yml after running ansible-container shipit kube to allow use of GCE persistent disks.

btw, I ❤️ this project, for a existing Ansible user this project has helped a lot to get know to Docker and Kubernetes

[chouseknecht]

My assumption is that the named volumes are not available during build and run. The build command uses the volumes definition found at the service level (i.e. outside of _devoverrides). The run command uses the definition found in _devoverrides, or if not specified, falls back to the service level definition. During shipit the named volumes are available, and so we need to override the service level definition.

To provide an override mechanism for shipit, I think we could simply expand options.kube in container.yml to include volumes and the named volume definitions. The volumes attribute would be formatted exactly the same as docker-compose volumes, and it would override the service level definition. A named volume would just be a dict of attributes specific to the type of volume.

It would be incumbent upon the user to create the named volumes outside of Ansible Container prior to running the generated role.

For example, the following defines two named volumes (test-data and read-only-data), and the named volume definitions point to pre-existing gcePersistentDisk type volumes:

version: "1"
services:
  web:
    volumes:
      - /var/data:/data
      - /var/readonly:/read:r

    dev_overrides:
      - ~/data:/data
      - ~/read:/read:r

    options:
       kube:
         volumes:
            - test-data:/data
            - read-only-data:/read:r
         test-data:
            gcePersistentDisk:
               pdName: my-data-disk
               fsType: ext4
         read-only-data:
            gcePersistentDisk:
               pdName: my-readonly-disk
               fsType: ext4

[j00bar]

Thoughts:

1) If the kompose work goes through and container.yml gets expanded to support more of the compose v2 schema syntax, the volumes directive would already need to support named volumes. 2) What do other potential future shipit targets support in terms of storage drivers? Is there something more generic we can use without having to repeat ourselves?