<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">2019年9月17日(火) 6:23 Eric Harney <<a href="mailto:eharney@redhat.com">eharney@redhat.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/16/19 8:01 PM, Ghanshyam Mann wrote:<br>
> ---- On Tue, 17 Sep 2019 02:40:36 +0900 Eric Harney <<a href="mailto:eharney@redhat.com" target="_blank">eharney@redhat.com</a>> wrote ----<br>
> > On 9/16/19 6:02 AM, Ghanshyam Mann wrote:<br>
> > > ---- On Mon, 16 Sep 2019 18:53:58 +0900 Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>> wrote ----<br>
> > > > Hello Everyone,<br>
> > > ><br>
> > > > As per discussion over ML, Tempest started the JSON schema strict validation for Volume APIs response [1].<br>
> > > > Because it may affect the interop certification, it was explained to the Interop team as well as in the Board of Director meeting[2].<br>
> > > ><br>
> > > > In Train, Tempest started implementing the validation and found an API change where the new field was added in API response without versioning[3] (Cinder has API microversion mechanism). IMO, that was not the correct way to change the API and as per API-WG guidelines[4] any field added/modified/removed in API should be with microverison(means old versions/user should not be affected by that change) and must for API interoperability.<br>
> > > ><br>
> > > > With JSON schema validation, Tempest verifies the API interoperability recommended behaviour by API-WG. But as per IRC conversion with cinder team, we have different opinion on API interoperability and how API should be changed under microversion mechanism. I would like to have a conclusion on this so that Tempest can verify or leave the Volume API for strict validation.<br>
> > ><br>
> > > I found the same flow chart what Sean created in Nova about "when to bump microverison" in Cinder also which clearly say any addition to response need new microversion.<br>
> > > - <a href="https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html" rel="noreferrer" target="_blank">https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html</a><br>
> > ><br>
> > > -gmann<br>
> > ><br>
> ><br>
> > I don't believe that it is clear that a microversion bump was required<br>
> > for the "groups" response showing up in a GET quota-sets response, and<br>
> > here's why:<br>
> ><br>
> > This API has, since at least Havana, returned dynamic fields based on<br>
> > quotas that are assigned to volume types. i.e.:<br>
> ><br>
> > $ cinder --debug quota-show b73b1b7e82a247038cd01a441ec5a806<br>
> > DEBUG:keystoneauth:RESP BODY: {"quota_set": {"per_volume_gigabytes": -1,<br>
> > "volumes_ceph": -1, "groups": 10, "gigabytes": 1000, "backup_gigabytes":<br>
> > 1000, "snapshots": 10, "volumes_enc": -1, "snapshots_enc": -1,<br>
> > "snapshots_ceph": -1, "gigabytes_ceph": -1, "volumes": 10,<br>
> > "gigabytes_enc": -1, "backups": 10, "id":<br>
> > "b73b1b7e82a247038cd01a441ec5a806"}}<br>
> ><br>
> > "gigabytes_ceph" is in that response because there's a "ceph" volume<br>
> > type defined, same for "gigabytes_enc", etc.<br>
> ><br>
> > This puts this API alongside something more like listing volume types --<br>
> > you get a list of what's defined on the deployment, not a pre-baked list<br>
> > of defined fields.<br>
> ><br>
> > Complaints about the fact that "groups" being added without a<br>
> > microversion imply that these other dynamic fields shouldn't be in this<br>
> > response either -- but this is how this API works.<br>
> ><br>
> > There's a lot of talk here about interoperability problems... what are<br>
> > those problems, exactly? If we ignore Ocata and just look at Train --<br>
> > why is this API not problematic for interoperability there, when<br>
> > requests on different clouds would return different data, depending on<br>
> > how types are configured?<br>
> ><br>
> > It's not clear to me that rectifying the microversion concerns around<br>
> > the "groups" field is helpful without also understanding this piece,<br>
> > because if the concern is that different clouds return different fields<br>
> > for this API -- that will still happen. We need more detail to<br>
> > understand how to address this, and what the problem is that we are<br>
> > trying to solve exactly.<br>
> <br>
> There are two things here.<br>
> 1. API behaviour depends on backend. This has been discussed two years back also and Tempest team along with cinder team decided not to test the backend-specific behaviour in Tempest[1].<br>
<br>
This is wrong. Nothing about what is happening in this API is <br>
backend-specific.<br>
<br>
> 2. API is changed without versioning.<br>
> <br>
> The second one is the issue here. If any API is changed without versioning cause the interoperability issue here. New field is being added for older microversion also for same backend.<br>
> <br>
<br>
If the concern is that different fields can be returned as part of quota <br>
info, it's worth understanding that fixing the Ocata tempest failures <br>
won't fix your concern, because this API still returns dynamic fields <br>
when the deployment is using per-type quotas, even on master.<br>
<br>
Are those considered "changes"? Need concrete details here.<br></blockquote><div><br></div></div><div class="gmail_quote">It is not difficult to answer this question.</div><div class="gmail_quote">The Cinder official API document[1] says the field "groups" is always returned(not optional) in the API response.</div><div class="gmail_quote">IIUC the above dynamic fields are not written on the document, right?<br></div><div class="gmail_quote">In addition, Cinder implements microversions which clearly controls the addition of API field as [2].<br></div><div class="gmail_quote">But actually the field "groups" has been added without bumping a microversion against the above [2].</div><div class="gmail_quote">Then Ghanshyam raises the interoperability concern.</div><div class="gmail_quote"><br></div><div class="gmail_quote">What is the interoperability concern?</div><div class="gmail_quote">The concern is if writing an application based on the API official document, the application can work on newer clouds(Pike+ in this case) but it cannot work on older clouds(Ocata-).</div><div class="gmail_quote">Actually we can consider Tempest is one of applications by consuming OpenStack APIs and we implemented JSON-Schema validation based on the API official document. Then Tempest could not work on older clouds(stable/ocata) and it is clearly an interoperability issue.</div><div class="gmail_quote">(We Tempest reviewers read the API document carefully for reviewing JSON-Schema patches, then we found Cinder document issues and fixed them :-)<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">BTW IMO backwards compatibility is more important than interoperability.</div><div class="gmail_quote">So we should not remove
the field "groups" from the base microversion anyways.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks</div><div class="gmail_quote">Kenichi Omichi</div><div class="gmail_quote"><br></div><div class="gmail_quote">---</div><div class="gmail_quote"><br></div><div class="gmail_quote">[1]: <a href="https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=show-quotas-for-a-project-detail#show-quotas-for-a-project">https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=show-quotas-for-a-project-detail#show-quotas-for-a-project</a></div><div class="gmail_quote">[2]: <a href="https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html#when-do-i-need-a-new-microversion">https://docs.openstack.org/cinder/latest/contributor/api_microversion_dev.html#when-do-i-need-a-new-microversion</a> (the part of "
the list of attributes and data structures returned")</div><div class="gmail_quote"><br></div></div>