On Mon, Sep 16, 2019 at 1:55 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
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.
these details definitely make a difference to me. perhaps i should clarify my previous statement, i would expect any changes to the request or response /schemas/ to be associated with a version bump. if these tolerances are allowed within the current schema, then it makes sense to me that no version change would occur. thanks for the clarification Eric and Sean peace o/ Sean