Open Stack

On Mon, Sep 16, 2019 at 1:55 PM Sean McGinnis <sean.mcginnis at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190916/f50c4d1d/attachment.html>