Open Stack

Hi David,

> -----Original Message-----
> From: David Kranz [mailto:dkranz at redhat.com]
> Sent: Wednesday, February 25, 2015 4:19 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Tempest] Tempest will deny extra properties on Nova v2/v2.1 API
> >
> > 2015-02-24 20:28 GMT+09:00 GHANSHYAM MANN <ghanshyammann at gmail.com>:
> >> On Tue, Feb 24, 2015 at 6:48 PM, Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
> >> wrote:
> >>> Hi
> >>>
> >>> Nova team is developing Nova v2.1 API + microversions in this cycle,
> >>> and the status of Nova v2.1 API has been changed to CURRENT from
> >>> EXPERIMENTAL.
> >>> That said new API properties should be added via microversions, and
> >>> v2/v2.1 API(*without* microversions) should return the same response
> >>> without any new properties.
> >>> Now Tempest allows extra properties of a Nova API response because we
> >>> thought Tempest should not block Nova API development.
> >>>
> >>> However, I think Tempest needs to deny extra properties in
> >>> non-microversions test cases because we need to block accidental
> >>> changes of v2/v2.1 API and encourage to use microversions for API
> >>> changes.
> >>> https://review.openstack.org/#/c/156130/ is trying to do that, but I'd
> >>> like to get opinions before that.
> >>>
> >>> If the above change is merged, we can not use Tempest on OpenStack
> >>> environments which provide the original properties.
> >>
> >> I think that will be nice to block additional properties.
> >>
> >> Do you mean OpenStack environment with micro-versions enabled?
> >> In those cases too tempest should run successfully as it requests on V2 or
> >> V2.1 endpoint not on microversion.
> > My previous words were unclear, sorry.
> > The above "OpenStack environment" means the environment which is
> > customized by a cloud service provider and it returns a response which
> > includes the provider original properties.
> >
> > On microversions discussion, we considered the customized API by
> > a cloud service provider for the design. Then I guess there are some
> > environments return extra properties and Tempest will deny them if
> > the patch is merged. I'd like to know the situation is acceptable or not
> > as Tempest purpose.
>
> Ken'ichi, can you please provide a pointer to the referenced
> microversions discussion and/or summarize the conclusion?

OK, Christopher Yeoh mentioned about future microversions on
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057390.html

Now there are two API versions in Nova: v2 and v2.1.
v2 is implemented with old framework and we will remove it in long term.
v2.1 is implemented with new framework and it is the same as v2 as API
behaviors for providing full v2 compatibility.
Microversions will be v2.2, v2.3, ... and we can change API behaviors which
are both backwards compatible and incompatible.
Clients need to specify the preferred microversion in the request header if
they want to use microversioned API.
If not specifying it, Nova works as default API version which is v2.1.
Tempest doesn't specifies it now. So Tempest should check the behavior which
is the same as v2 on default API(v2.1) tests.

As Chris said "no changes should be accepted to the old v2 api code" on the
above mail, that means backwards compatible changes also should not be applied
to v2 and v2.1.

> The commit message is saying that returning extra values without a new
> microversion is an incompatible (disallowed) change.
> This was already true, unless creating a new extension, according to
> https://wiki.openstack.org/wiki/APIChangeGuidelines.

Yeah, a nice point.
We added a new dummy extension when adding new extra properties for the
above guideline, and extension numbers increased. We can use microversions
instead of adding more dummy extensions.

> Seems to me that extra properties (unless using a syntax marking them as
> such), are either allowed or not. If not, tempest should fail on them.
> If service providers are allowed to add returned properties, and not
> required to use some special syntax to distinguish them, that is a bad
> api. If tempest can't tell the difference between a legitimate added
> property and some one misspelling while returning an optional property,
> I'm not sure how we test for the unintentional change case.

We had discussed *vendor* flag in Kilo summit, and we have decided drop
of the flag[1]. So we don't have a standard way to know the difference.
I feel now Tempest can deny extra properties as upstream development.

[1]: https://etherpad.openstack.org/p/kilo-nova-microversions


Thanks
Ken Ohmichi