On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbky...@gmail.com> wrote:
On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann <doug.hellm...@dreamhost.com>
wrote:
That covers routes. What about the properties of the inputs and outputs?
I think the best way for me to describe it is that as the V3 API core and all
the extensions
are written, both the routes and input and output parameters are from a
client's perspective fixed at application
startup time. Its not an inherent restriction of the framework (an extension
could for
example dynamically load another extension at runtime if it really wanted to),
but we just don't do that.
OK, good.
Note that values of parameters returned can be changed by an extension though.
For example os-hide-server-addresses
can based on a runtime policy check and the vm_state of the server, filter
whether the values in the
addresses field are filtered out or not when returning information about a
server. This isn't a new thing in the
V3 API though, it already existed in the V2 API.
OK, it seems like as long as the fields are still present that makes the API at
least consistent for a given deployment's configuration.
Doug
Chris
On Fri, Dec 13, 2013 at 4:43 PM, Ryan Petrello <ryan.petre...@dreamhost.com>
wrote:
Unless there’s some other trickiness going on that I’m unaware of, the routes
for the WSGI app are defined at application startup time (by methods called in
the WSGI app’s __init__).
---
Ryan Petrello
Senior Developer, DreamHost
ryan.petre...@dreamhost.com
On Dec 13, 2013, at 12:56 PM, Doug Hellmann <doug.hellm...@dreamhost.com> wrote:
On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <cbky...@gmail.com> wrote:
On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypi...@gmail.com> wrote:
On 12/11/2013 11:47 PM, Mike Perez wrote:
On 10:06 Thu 12 Dec , Christopher Yeoh wrote:
On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
<doug.hellm...@dreamhost.com
<mailto:doug.hellm...@dreamhost.com>>wrote:
On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
ryan.petre...@dreamhost.com
<mailto:ryan.petre...@dreamhost.com>>
wrote:
Hello,
I’ve spent the past week experimenting with using Pecan for
Nova’s
API
and have opened an experimental review:
https://review.openstack.org/#/c/61303/6
…which implements the `versions` v3 endpoint using pecan (and
paves the
way for other extensions to use pecan). This is a *potential*
approach
I've considered for gradually moving the V3 API, but I’m open
to other suggestions (and feedback on this approach). I’ve
also got a few open questions/general observations:
1. It looks like the Nova v3 API is composed *entirely* of
extensions (including “core” API calls), and that extensions
and their routes are discoverable and extensible via installed
software that registers
itself
via stevedore. This seems to lead to an API that’s composed of
installed
software, which in my opinion, makes it fairly hard to map out
the
API (as
opposed to how routes are manually defined in other WSGI
frameworks). I
assume at this time, this design decision has already been
solidified for
v3?
Yeah, I brought this up at the summit. I am still having some
trouble understanding how we are going to express a stable core
API for compatibility testing if the behavior of the API can be
varied so significantly by deployment decisions. Will we just
list each
"required"
extension, and forbid any extras for a compliant cloud?
Maybe the issue is caused by me misunderstanding the term
"extension," which (to me) implies an optional component but is
perhaps reflecting a technical implementation detail instead?
Yes and no :-) As Ryan mentions, all API code is a plugin in the V3
API. However, some must be loaded or the V3 API refuses to start
up. In nova/api/openstack/__init__.py we have
API_V3_CORE_EXTENSIONS which hard codes which extensions must be
loaded and there is no config option to override this (blacklisting
a core plugin will result in the V3 API not starting up).
So for compatibility testing I think what will probably happen is
that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that
must be implemented and clients can rely on that always being
present
on a compliant cloud. But clients can also then query through
/extensions what other functionality (which is backwards compatible
with respect to core) may also be present on that specific cloud.
This really seems similar to the idea of having a router class, some
controllers and you map them. From my observation at the summit,
calling everything an extension creates confusion. An extension
"extends" something. For example, Chrome has extensions, and they
extend the idea of the core features of a browser. If you want to do
more than back/forward, go to an address, stop, etc, that's an
extension. If you want it to play an audio clip "stop, hammer time"
after clicking the stop button, that's an example of an extension.
In OpenStack, we use extensions to extend core. Core are the
essential feature(s) of the project. In Cinder for example, core is
volume. In core you can create a volume, delete a volume, attach a
volume, detach a volume, etc. If you want to go beyond that, that's
an extension. If you want to do volume encryption, that's an example
of an extension.
I'm worried by the discrepancies this will create among the programs.
You mentioned maintainability being a plus for this. I don't think
it'll be great from the deployers perspective when you have one
program that thinks everything is an extension and some of them have
to be enabled that the deployer has to be mindful of, while the rest
of the programs consider all extensions to be optional.
+1. I agree with most of what Mike says above. The idea that there are core
"extensions" in Nova's v3 API doesn't make a whole lot of sense to me.
So would it help if we used the term "plugin" to talk about the framework that
the API is implemented with,
and extensions when talking about things which extend the core API? So the
whole of the API is implemented
using plugins, while the core plugins are not considered to be extensions.
That distinction does help.
Are the extensions enabled at startup time, or at runtime when an API call is
made? That is, could 2 different users of the same cloud service instance see
different fields in the value returned from the call because of some runtime
decision made inside either an extension (where the extension might not add
fields for some reason) or a bit of core code (by deciding not to call an
extension at all)?
Doug
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
