<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:SimSun;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@SimSun";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Chris,<o:p></o:p></p>
<p class="MsoNormal">If we add openstack config to refstack submission will that provide sufficient info for “interoperability” LOGO?<o:p></o:p></p>
<p class="MsoNormal">That includes version of APIs for each service.<o:p></o:p></p>
<p class="MsoNormal"><a href="https://review.openstack.org/#/c/300057/">https://review.openstack.org/#/c/300057/</a><b><o:p></o:p></b></p>
<p class="MsoNormal"><b><o:p> </o:p></b></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal">Arkady<o:p></o:p></p>
<p>-----Original Message-----<br>
From: Chris Hoge [mailto:chris@openstack.org] <br>
Sent: Wednesday, June 22, 2016 1:37 PM<br>
To: OpenStack Development Mailing List (not for usage questions) <br>
Subject: Re: [openstack-dev] [tempest][nova][defcore] Add option to disable some strict response checking for interop testing<br>
<br>
<br>
> On Jun 22, 2016, at 11:24 AM, Sean Dague wrote:<br>
> <br>
> On 06/22/2016 01:59 PM, Chris Hoge wrote:<br>
>> <br>
>>> On Jun 20, 2016, at 5:10 AM, Sean Dague <br>
>>> > wrote:<br>
>>> <br>
>>> On 06/14/2016 07:19 PM, Chris Hoge wrote:<br>
>>>> <br>
>>>>> On Jun 14, 2016, at 3:59 PM, Edward Leafe <br>
>>>>> > wrote:<br>
>>>>> <br>
>>>>> On Jun 14, 2016, at 5:50 PM, Matthew Treinish <br>
>>>>> > wrote:<br>
>>>>> <br>
>>>>>> But, if we add another possible state on the defcore side like <br>
>>>>>> conditional pass, warning, yellow, etc. (the name doesn't matter) <br>
>>>>>> which is used to indicate that things on product X could only <br>
>>>>>> pass when strict validation was disabled (and be clear about <br>
>>>>>> where and why) then my concerns would be alleviated.<br>
>>>>>> I just do<br>
>>>>>> not want this to end up not being visible to end users trying to <br>
>>>>>> evaluate interoperability of different clouds using the test <br>
>>>>>> results.<br>
>>>>> <br>
>>>>> +1<br>
>>>>> <br>
>>>>> Don't fail them, but don't cover up their incompatibility, either.<br>
>>>>> -- Ed Leafe<br>
>>>> <br>
>>>> That’s not my proposal. My requirement is that vendors who want to <br>
>>>> do this state exactly which APIs are sending back additional data, <br>
>>>> and that this information be published.<br>
>>>> <br>
>>>> There are different levels of incompatibility. A response with <br>
>>>> additional data that can be safely ignored is different from a <br>
>>>> changed response that would cause a client to fail.<br>
>>> <br>
>>> It's actually not different. It's really not.<br>
>>> <br>
>>> This idea that it's safe to add response data is based on an <br>
>>> assumption that software versions only move forward. If you have a <br>
>>> single deploy of software, that's fine.<br>
>>> <br>
>>> However as noted, we've got production clouds on Juno <-> Mitaka in <br>
>>> the wild. Which means if we want to support horizontal transfer <br>
>>> between clouds, the user experienced timeline might be start on a <br>
>>> Mitaka cloud, then try to move to Juno. So anything added from Juno <br>
>>> -> Mitaka without signaling has exactly the same client breaking <br>
>>> behavior as removing attributes.<br>
>>> <br>
>>> Which is why microversions are needed for attribute adds.<br>
>> <br>
>> I’d like to note that Nova v2.0 is still a supported API, which as <br>
>> far as I understand allows for additional attributes and extensions. <br>
>> That Tempest doesn’t allow for disabling strict checking when using a <br>
>> v2.0 endpoint is a problem.<br>
>> <br>
>> The reporting of v2.0 in the Marketplace (which is what we do right <br>
>> now) is also a signal to a user that there may be vendor additions to <br>
>> the API.<br>
>> <br>
>> DefCore doesn’t disallow the use of a 2.0 endpoint as part of the <br>
>> interoperability standard.<br>
> <br>
> This is a point of confusion.<br>
> <br>
> The API definition did not allow that. The implementation of the API <br>
> stack did.<br>
<br>
And downstream vendors took advantage of that. We may not like it, but it’s a reality in the current ecosystem.<br>
<br>
> In Liberty the v2.0 API is optionally provided by a different backend <br>
> stack that doesn't support extensions.<br>
> In Mitaka it is default v2.0 API on a non extensions backend In Newton <br>
> the old backend is deleted.<br>
> <br>
> From Newton forward there is still a v2.0 API, but all the code hooks <br>
> that provided facilities for extensions are gone.<br>
<br>
It’s really important that the current documentation reflect the code and intent of the dev team. As of writing this e-mail,
<br>
<br>
"• v2 (SUPPORTED) and v2 extensions (SUPPORTED) (Will be deprecated in the near future.)”[1]<br>
<br>
Even with this being removed in Newton, DefCore still has to allow for it in every supported version.<br>
<br>
-Chris<br>
<br>
[1] http://docs.openstack.org/developer/nova/<br>
<br>
> -Sean<br>
> <br>
> --<br>
> Sean Dague<br>
> http://dague.net<br>
> <br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <br>
> OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<o:p></o:p></p>
</div>
</body>
</html>