<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 03/09/2015 06:04 PM, melanie witt
wrote:<br>
</div>
<blockquote
cite="mid:F4091990-B733-4A97-8D38-BBDA81FECE1D@gmail.com"
type="cite">
<pre wrap="">On Mar 9, 2015, at 13:14, Sean Dague <a class="moz-txt-link-rfc2396E" href="mailto:sean@dague.net"><sean@dague.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So possibly another way to think about this is our prior signaling of
what was supported by Nova was signaled by the extension list. Our code
was refactored into a way that supported optional loading by that unit.
As we're making things less optional it probably makes sense to evolve
the API code tree to look more like our REST resource tree. Yes, that
means servers.py ends up being big, but it is less confusing that all
servers related code is in that file vs all over a bunch of other files.
So I'd agree that in this case server tags probably should just be in
servers.py. I also think long term we should do some "plugin collapse"
for stuff that's all really just features on one resource tree so that
the local filesystem code structure looks a bit more like the REST url tree.
</pre>
</blockquote>
<pre wrap="">
I think this makes a lot of sense. When I read the question, "why is server tags being added as an extension" the answer that comes to mind first is, "because the extension framework is there and that's how things have been done so far."
I think the original thinking on extensions was, make everything optional so users can enable/disable as they please, operators can disable any feature by removing the extension. Another benefit is the ability for anyone to add a (non-useful to the community at-large) feature without having to patch in several places.
I used to be for extensions for the aforementioned benefits, but now I tend to think it's too flexible and complex. It's so flexible that you can easily get yourself into a situation where your deployment can't work with other useful tools/libraries/etc which expect a certain contract from the Nova API. It doesn't make sense to let the API we provide be so arbitrary. It's certainly not friendly to API users.
We still have the ability to disable or limit features based on policy -- I don't think we need to do it via extensions.
The only problem that seems to be left is, how can we allow people to add un-upstreamable features to the API in their internal deployments? I know the ideal answer is "don't do that" but the reality is some things will never be agreed upon upstream and I do see value in the extension framework for that. I don't think anything in-tree should be implemented as extensions, though.</pre>
</blockquote>
<br>
At the moment this is provided for by an experimental flag in the
response headers:
<a class="moz-txt-link-freetext" href="https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/kilo/approved/api-microversions.rst#n182">https://git.openstack.org/cgit/openstack/nova-specs/tree/specs/kilo/approved/api-microversions.rst#n182</a>
. It is intended to be used for transitioning from the current
state of extensions to a place where optional API extensions aren't
allowed, but that discussion can continue if there's a case for
allowing some optional components for deployers. I'm in favor of
having a mechanism for adding features to an deployment as long as
it's exposed in a way that makes it clear that it's separate from
the standard API, e.g. an entirely separate tree, not just resource
prefixes.<br>
<br>
<blockquote
cite="mid:F4091990-B733-4A97-8D38-BBDA81FECE1D@gmail.com"
type="cite">
<pre wrap="">
melanie (melwitt)
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>