Open Stack

Chris - I have a question about this... since this is upstream, will the
latest (v2) CLI start enforcing this?  If so, it seems like the cloud
providers should have a real motivation to make the migration since the
CLI failing would, IMHO, be a major issue.

On 06/21/2016 04:51 PM, Van Lindberg 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.
>
> > * Should there a permanent exception for additional properties?
>
> Yes, until such time as "Does not return additional properties" is an
> accepted defcore capability.
>
> > 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.
>
> > * 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.
>
> Thanks,
> Van
>
>
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-- 

Rob
____________________________
Rob Hirschfeld, 512-773-7522

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: zehicle & ravolt 

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