> >
>
> I don't believe that it is clear that a microversion bump was required for
> the "groups" response showing up in a GET quota-sets response, and here's
> why:
>
> This API has, since at least Havana, returned dynamic fields based on quotas
> that are assigned to volume types.  i.e.:
>
> $ cinder --debug quota-show b73b1b7e82a247038cd01a441ec5a806
> DEBUG:keystoneauth:RESP BODY: {"quota_set": {"per_volume_gigabytes": -1,
> "volumes_ceph": -1, "groups": 10, "gigabytes": 1000, "backup_gigabytes":
> 1000, "snapshots": 10, "volumes_enc": -1, "snapshots_enc": -1,
> "snapshots_ceph": -1, "gigabytes_ceph": -1, "volumes": 10, "gigabytes_enc":
> -1, "backups": 10, "id": "b73b1b7e82a247038cd01a441ec5a806"}}
>
> "gigabytes_ceph" is in that response because there's a "ceph" volume type
> defined, same for "gigabytes_enc", etc.
>
> This puts this API alongside something more like listing volume types -- you
> get a list of what's defined on the deployment, not a pre-baked list of
> defined fields.
>

I think this is the root of the confusion, and why I still think that
enforcements, at least as it is now, should be reverted from tempest.

This is not an API change where Cinder changed the columns in the response,
it's the rows. This is a dynamic list. Like Eric points out, this really is no
different than listing volumes or volumes types.

This definitely should *not* be a microversion bump and the enforcement by
tempest of the content (not the structure) is wrong.

Sean