Feature Request: Volumes and PV/C support about dokku-scheduler-kubernetes HOT 12 CLOSED

When you create a PVC, should those that take the app name as the first arg, and why? I would imagine the --name flag should be the first arg instead.

Should we also have commands for removing PVCs/Volumes? What happens if they are mounted and someone tries to remove them? What is a --claimName vs --pvc?

from dokku-scheduler-kubernetes.

When you create a PVC, should those that take the app name as the first arg, and why? I would imagine the --name flag should be the first arg instead.

True, the app name may not even be needed except for some extra metadata since PVCs are not dependent on deployment.

Should we also have commands for removing PVCs/Volumes? What happens if they are mounted and someone tries to remove them?

Eventually, users will want to remove Volumes, even if it is mounted they are deleted. This might require deleting volumes (as defined in deployment spec) and deleting pvc as 2 separate commands
Please see protection for storage object

What is a --claimName vs --pvc?

As defined in sample deployment spec

--claimName is exactly used particularly when defining a PVC for the volume, i just felt --pvc might an option

I think this might also be helpful

from dokku-scheduler-kubernetes.

Should we have commands for listing all of these things as well?

from dokku-scheduler-kubernetes.

The current k8s manifest might be sufficient for the volume and mounts details. Listing PVCs will be useful before mounting/attaching to deployments

from dokku-scheduler-kubernetes.

• Create a PVC:

dokku scheduler-kubernetes:add-pvc --name $PVC_NAME --access-mode "ReadWriteOnce|ReadOnlyMany|ReadWriteMany " --storage "100" --ns $NAMESPACE [--storage-class-name "nfs"]
since PVC and PV have 1-1 relationship having the $APP_NAME in the mix will help us know that the PVC was used exclusively for that app. (almost all dokku commands refer the $APP_NAME first)

• Listing a PVC:

dokku scheduler-kubernetes:list-pvc [$NAMESPACE]

Deleting a PVC here (Postponed until no longer in active use by any Pods)

dokku scheduler-kubernetes:remove-pvc --name $PVC_NAME --ns $NAMESPACE

• Create and mount volume:

dokku scheduler-kubernetes:mount $APP_NAME --name VOLUME_NAME --claim-name $PVC_NAME --path /container/path

• List mounted volumes:

dokku scheduler-kubernetes:list-mount $APP_NAME

• Unmout a volume

dokku scheduler-kubernetes:unmount $APP_NAME --name $VOLUME_NAME --path /container/path --claim-name $PVC_NAME

• Unmout all volumes

dokku scheduler-kubernetes:unmount -all $APP_NAME

from dokku-scheduler-kubernetes.

What happens if you want to use a given PVC with multiple applications? I already have someone asking about that hypothetical use case, and I don't think it's a great idea to make these app-centric.

from dokku-scheduler-kubernetes.

We could potentially allow the ability to inject custom labels into a pvc if we wanted more metatada?

from dokku-scheduler-kubernetes.

What happens if you want to use a given PVC with multiple applications?
Sharing PVCs across multiple apps will require the apps to be in the same namespace/project and also use access modes ReadWriteMany and ReadOnlyMany.

Trying to use a PVC from another namespace should fail, so i felt it would be best practice to have an apps objects in the same namespace

We could potentially allow the ability to inject custom labels into a pvc if we wanted more metatada?

I guess

from dokku-scheduler-kubernetes.

I think we can definitely check to see if the PVC is in the correct namespace before allowing it to be linked (and fail a deploy if it moves namespaces).

from dokku-scheduler-kubernetes.

@savant
I've be able to complete the PVC feature, i tested using k8s on Digitalocean, access mode ReadWriteMany using nfs

from dokku-scheduler-kubernetes.

Awesome thanks! I'll take a look at this in the evening, busy with work-related tasks atm. Thanks for the hard work!

from dokku-scheduler-kubernetes.

closed by #25

from dokku-scheduler-kubernetes.