<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 27, 2015 at 1:28 PM, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 03/24/2015 11:10 AM, Chris Friesen wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 03/24/2015 07:42 AM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 03/24/2015 09:11 AM, Jeremy Stanley wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
How would that be expected to work for things where it's<br>
fundamentally just a minor extension to an existing nova API?<br>
(Exposing additional information as part of "nova show", for<br>
example.)<br>
</blockquote>
<br>
Conversely, how do you recommend users of your environment reconcile<br>
the difference in nova show output compared to what they get from<br>
the other OpenStack environments they're using? How do you propose<br>
to address the need for client libraries to cater to your divergent<br>
API returning different numbers of parameters for certain methods?<br>
</blockquote></blockquote>
<br>
We had been trying to control things properly via the extensions mechanism so<br>
that the changes could be documented/controlled.<br>
<br>
As for clients, if the properties in the response are named, then simply adding<br>
a new property to a response message body shouldn't be a problem--clients could<br>
just ignore properties that they don't understand.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think these conversations work better in the concrete than the abstract.<br>
<br>
Chris, what additional attributes are you exposing on nova show which<br>
are critical for your installation? Can we figure out a way to<br>
generically support whatever that is?<br>
</blockquote>
<br>
In some cases it might be something that could conceivably go in upstream, but<br>
hasn't yet.  This might be something as simple as having "nova show" display the<br>
server group that an instance is in, or it might be a bugfix that hasn't been<br>
merged upstream yet (like "<a href="https://review.openstack.org/#/c/16306" target="_blank">https://review.openstack.org/<u></u>#/c/16306</a>" for example)<br>
or it might be per-instance control over things that upstream currently only<br>
allows control over at the image/flavor level.  Some of these might take a<br>
release or two to get merged (and there's no guarantee that they would ever be<br>
merged) but customers want the functionality in the meantime.<br>
<br>
In other cases the change is unlikely to ever be merged upstream, either because<br>
it's too domain-specific or the solution is messy or even proprietary.<br>
</blockquote>
<br></div></div>
Haven't seen any responses to this.<br>
<br>
As I see it, nova is really pushing for interoperability, but what is a vendor supposed to do when they have customers asking for extensions to the existing behaviour, and they want it in a month rather than the 6-9 months it might take to push upstream?  (Assuming its something that upstream is even interested in.)<br>
<br></blockquote><div><br></div><div>To quote John from an earlier email in this thread:</div><div><br></div><div><span style="font-size:12.8000001907349px">Its worth noting, we do have the "experimental" flag:</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">"</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">The first header specifies the version number of the API which was</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">executed. Experimental is only returned if the operator has made a</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">modification to the API behaviour that is non standard. This is only</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">intended to be a transitional mechanism while some functionality used</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">by cloud operators is upstreamed and it will be removed within a small</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">number of releases.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">"</span><br></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">So if you have an extension that gets accepted upstream you can use the experimental flag until you migrate to the upstream version of the extension.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I think it would be better to have an explicit method of declaring/versioning vendor-specific extensions (even if it's not used at all by the core Nova API) than to have each vendor winging it on their own. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
That way you would still get interoperability of the core Nova API (allowing customers to use multiple cloud vendors as long as they stick to the core API) while still giving a well-defined way to provide customized behaviour.</blockquote><div><br></div><div>That is *not* what I would call interoperability, this is exactly what we do not want.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
<br>
Chris<br>
<br>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>