Open Stack

> On Jun 21, 2016, at 4:51 PM, Van Lindberg <van.lindberg at RACKSPACE.COM> wrote:
> 
> 
> On Jun 21, 2016 6:30 PM, Chris Hoge <chris at openstack.org> wrote:
> >
> > * Should there be a short-term exception for additional properties?
> 
> Yes, absolutely.
> > This change has been harmful to vendors, users, and the OpenStack
> > Powered program, and there should be a facility in DefCore to handle
> > this. Existing companies, that passed early in the year last year, no
> > longer pass.
> 
> This is the crux of the issue; a cloud that passed in December stopped passing in January, not due to any change on the part of the product offered for sale.
> 
> Making this change even more egregious, this change is not part of any required capability - this was an extraneous change. Even if we want to make "does not return extra properties" a tested capability in the defcorish sense, we would need to put it through the standard process (widely deployed? Aligned with future direction? etc.) and then put in via the standard advisory/approved process.
> 
> > While there has been warning, product decisions move more
> > slowly.
> 
> There has been lots of warnings on lots of things. That doesn't mean that whatever makes it into upstream automatically is part of  Openstack(TM). The things that are part of the Openstack trademark are solely decided according to the defcore process - a process that was negotiated out for literally years.
> 
Yes, and microversions and strict API checking is a change that
we would be giving vendors more than two years to adopt.
> > * Should there a permanent exception for additional properties?
> 
> Yes, until such time as "Does not return additional properties" is an accepted defcore capability.
> 
I disagree that it’s a capability. It’s the API definition, and
part of testing that definition is checking for a well-formed
response on every call. By definition you’re not part of the
Nova 2.1+ API if you add extra properties, and 2.0 is
deprecated (and removed upstream).
> > However, upstream is moving in this
> > direction, and it's only a matter of time before more projects and tools
> > adopt strict response checking, making it a long-term interoperability
> > issue regardless of the position DefCore takes.
> 
> I would add that I oppose any restriction on the ability to provide extensions until such point as there is a workable alternative to migrate to, plus an appropriate time to migrate.
> 
> I believe that this whole issue is an inappropriate technical fix for what is really social problem.
> 
This is addressing a social and technical problem. It
forces vendors to make their additions discoverable and
interoperable. Every cloud sending extra data back
on what are well-defined responses harms interoperability.
> > * What is our guidance for vendors going forward?
> >
> > My suggestion to vendors is to use the next year to adjust their product
> > strategy and releases. The ideal solution is to work with upstream to
> > have additional properties rolled into a new micro-version [2], which
> > would force those properties to be adopted upstream into the Tempest
> > library.
> 
> I am generally supportive of this, but that presupposes that microversions actually provide a realistic alternative mechanism. This has not been shown yet.
> 
How has it not been shown? We’ve had 30 micro version
revisions to the API[1], much of it to add information that is similar
to what the RAX public cloud is returning.

I don’t like that this is painful, but at some point the painful step
has to be taken. That only two clouds are being significantly
impacted by this problem is an indication that micro-versions
and the API restrictions have been widely adopted. I’m 
looking for a solution that gives deployed products time to
align with the direction the community has clearly and loudly
said they want the Nova APIs to go in.

-Chris

[1] http://docs.openstack.org/developer/nova/api_microversion_history.html#id3

> Thanks,
> Van 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20160622/dea625ac/attachment.html>