<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
<div class="moz-cite-prefix">On 06/21/2016 04:51 PM, Van Lindberg
wrote:<br>
</div>
<blockquote
cite="mid:8926a9cc-694c-4872-94fa-92e99c80c8db@email.android.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<p dir="ltr"><br>
On Jun 21, 2016 6:30 PM, Chris Hoge <a class="moz-txt-link-rfc2396E" href="mailto:chris@openstack.org"><chris@openstack.org></a>
wrote:<br>
><br>
> * Should there be a short-term exception for additional
properties?</p>
<p dir="ltr">Yes, absolutely.<br>
</p>
<p dir="ltr">> This change has been harmful to vendors, users,
and the OpenStack<br>
> Powered program, and there should be a facility in DefCore
to handle<br>
> this. Existing companies, that passed early in the year
last year, no<br>
> longer pass. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> While there has been warning, product decisions
move more<br>
> slowly. </p>
<p dir="ltr">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.<br>
<br>
</p>
<p dir="ltr">> * Should there a permanent exception for
additional properties?</p>
<p dir="ltr">Yes, until such time as "Does not return additional
properties" is an accepted defcore capability.</p>
<p dir="ltr">> However, upstream is moving in this<br>
> direction, and it's only a matter of time before more
projects and tools<br>
> adopt strict response checking, making it a long-term
interoperability<br>
> issue regardless of the position DefCore takes. </p>
<p dir="ltr">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.</p>
<p dir="ltr">I believe that this whole issue is an inappropriate
technical fix for what is really social problem.<br>
</p>
<p dir="ltr">> * What is our guidance for vendors going
forward?<br>
><br>
> My suggestion to vendors is to use the next year to adjust
their product<br>
> strategy and releases. The ideal solution is to work with
upstream to<br>
> have additional properties rolled into a new micro-version
[2], which<br>
> would force those properties to be adopted upstream into
the Tempest<br>
> library.</p>
<p dir="ltr">I am generally supportive of this, but that
presupposes that microversions actually provide a realistic
alternative mechanism. This has not been shown yet.</p>
<p dir="ltr">Thanks,<br>
Van <br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Defcore-committee mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Defcore-committee@lists.openstack.org">Defcore-committee@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee">http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Rob
____________________________
Rob Hirschfeld, 512-773-7522
I am in CENTRAL (-6) time
<a class="moz-txt-link-freetext" href="http://robhirschfeld.com">http://robhirschfeld.com</a>
twitter: @zehicle, github: zehicle & ravolt </pre>
</body>
</html>