Thanks for your contribution! It seems the test is failing on travis.

@olivergondza I've pushed a new commit but travis has not been triggered

Strange, manual PR rebuild retried from the original commit and not the latest one. Reopening worked, though...

I gave this a try. JSON response:

{
  "quota_set": {
    "snapshots_shared": -1,
    "per_volume_gigabytes": -1,
    "snapshots_tripleo": -1,
    "volumes_shared": -1,
    "gigabytes": 1200,
    "backup_gigabytes": 100,
    "gigabytes_shared": -1,
    "snapshots": 200,
    "id": "deadbeef",
    "gigabytes_tripleo": -1,
    "snapshots_ceph": -1,
    "gigabytes_ceph": -1,
    "groups": 10,
    "volumes_ceph": -1,
    "backups": 5,
    "volumes_tripleo": -1,
    "volumes": 100
  }
}

getVolumeTypesQuotas():

backup_gigabytes:100
backups:5
gigabytes_ceph:-1
gigabytes_shared:-1
gigabytes_tripleo:-1
groups:10
per_volume_gigabytes:-1
snapshots_ceph:-1
snapshots_shared:-1
snapshots_tripleo:-1
volumes_ceph:-1
volumes_shared:-1
volumes_tripleo:-1

We take all the keys not mapped to fields and serve it from the getVolumeTypesQuotas() effectively expecting those are the Volume Types quota. Putting aside this is dangerous as the API can add more keys in the future, per_volume_gigabytes, groups and backups does not seem to belong there.

I find the REST API quite ugly around the dynamic keys, but how about checking the documented prefixes in the setVolumeTypesQuotas and only setting those we know are Volume Types quota?

I find the REST API quite ugly around the dynamic keys, but how about checking the documented prefixes in the setVolumeTypesQuotas and only setting those we know are Volume Types quota?

you are right, I had started doing that, I have it into a separate branch, but I didn't like it 'cause I ended up to write too much logic inside the dto

I'll resume the code, refactor and push it

Awesome, thanks for your contribution!