# Are volumes still supported on v3?
**URL:** https://community.convox.com/t/are-volumes-still-supported-on-v3/762
**Category:** Rack (Version 3)
**Created:** [July 29, 2020, 10:11am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762 "2020-07-29T10:11:21Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@crohr](https://community.convox.com/u/crohr)
#### Post date: [July 29, 2020, 10:11am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762/1 "2020-07-29T10:11:21Z")
Hello,
I’m trying to migrate a rack from v2 to v3, using DigitalOcean as the underlying provider. The rack install went fine, but then one of my apps uses volumes shared between the services, and it doesn’t seem to work anymore. As I can’t see any reference in the documentation regarding volumes, is it still supported?
Looking at the underlying kubernetes infrastructure it seems like persistent storage claims are still being made for my volumes, but they stay in the PENDING state indefinitely. Indeed, the persistent storage tab doesn’t show any volume being created to fulfil the claims. Do I somehow have to create them beforehand?
Thanks,
Cyril
---
### Author:  [@crohr](https://community.convox.com/u/crohr)
#### Post date: [July 29, 2020, 10:12am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762/2 "2020-07-29T10:12:57Z")
For reference my `convox.yml` looks like this:
```auto
services:
web:
build: .
command: /app/docker/web
domain: "${HOST}"
port: 3000
volumes:
- "/home/data"
- "/home/public"
- "/home/lib"
worker:
build: .
command: /app/docker/worker
volumes:
- "/home/data"
- "/home/public"
- "/home/lib"
```
---
### Author:  [@crohr](https://community.convox.com/u/crohr)
#### Post date: [July 30, 2020, 7:01am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762/3 "2020-07-30T07:01:10Z")
Got in touch with DO support, and it seems their storage class does not support the `selector` field in the Persistent Volume Claim definition.
This is what’s generated by Convox:
```auto
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e
namespace: paas-my-app
selfLink: >-
/api/v1/namespaces/paas-my-app/persistentvolumeclaims/paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e
uid: c3c3a749-4633-4bb6-b6a6-e3db504bcfb2
resourceVersion: '338589'
creationTimestamp: '2020-07-29T08:06:06Z'
labels:
app: my-app
atom: e0460e5e50595bdcd62d4d5a4269546bc0c493271dac645aed65ab3e822b
provider: k8s
rack: paas
release: RMZACPEEGVM
system: convox
annotations:
kubectl.kubernetes.io/last-applied-configuration: >
{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"labels":{"app":"my-app","atom":"e0460e5e50595bdcd62d4d5a4269546bc0c493271dac645aed65ab3e822b","provider":"k8s","rack":"paas","release":"RMZACPEEGVM","system":"convox"},"name":"paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e","namespace":"paas-my-app"},"spec":{"accessModes":["ReadWriteMany"],"resources":{"requests":{"storage":"10Gi"}},"selector":{"matchLabels":{"app":"my-app","rack":"paas","system":"convox","volume":"paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e"}}}}
volume.beta.kubernetes.io/storage-provisioner: dobs.csi.digitalocean.com
finalizers:
- kubernetes.io/pvc-protection
spec:
accessModes:
- ReadWriteMany
selector:
matchLabels:
app: my-app
rack: paas
system: convox
volume: paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e
resources:
requests:
storage: 10Gi
storageClassName: do-block-storage
volumeMode: Filesystem
status:
phase: Pending
```
This is what they see in their backend:
```auto
paas-my-app 48m Warning ProvisioningFailed persistentvolumeclaim/paas-my-app-23f50e7a8f20234a0f92f486674d92e6fb9deb4e failed to provision volume with StorageClass "do-block-storage": claim Selector is not supported
```
I must say my first attempts with v3 racks are a bit underwhelming. It looks like there are many (undocumented/unsupported) variations in terms of supported features between the various k8s providers, and I’m afraid Convox will have to use the lowest common set of features to be truly inter-operable, or risk having subpar/broken experiences with some of the providers (in which case, why bother with them in the first place).
---
### Author:  [@ian](https://community.convox.com/u/ian)
#### Post date: [August 14, 2020, 11:03am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762/4 "2020-08-14T11:03:55Z")
I’m also having this issue.
Can the convox team give some indication about where the problem lies with DO + volumes, and what a resolution depends on?
Thanks!
---
### Author:  [@andrew1](https://community.convox.com/u/andrew1)
#### Post date: [April 17, 2021, 11:40am UTC](https://community.convox.com/t/are-volumes-still-supported-on-v3/762/5 "2021-04-17T11:40:54Z")
I’ve tried to adding a volume to my convox.yml, but when I deploy to AWS rack, I get this error:
```
....
2021-04-17T11:24:29Z system/k8s/seq-689fc5c485-6snj2 persistentvolumeclaim "test-seq-cd7a42fa218f6591dbf454715bdb40d5622
1e802" not found
2021-04-17T11:24:29Z system/k8s/seq-689fc5c485 Created pod: seq-689fc5c485-6snj2
2021-04-17T11:24:29Z system/k8s/atom/app Status: Pending => Error
2021-04-17T11:24:31Z system/k8s/atom/app Status: Error => Rollback
2021-04-17T11:24:31Z system/k8s/atom/app Status: Rollback => Reverted
2021-04-17T11:24:31Z system/k8s/seq-689fc5c485-6snj2 Failed to bind volumes: provisioning failed for PVC "test-seq-cd7a4
2fa218f6591dbf454715bdb40d56221e802"
...
```
Also, the Convox docs (for v3) don’t seem to mention volumes at all. Does this mean they are not supported at all?
Is there some undocumented rack setup required to get volumes to work?
Without volumes I won’t be able to use Convox at all.