Open Stack

I replied on the review itself but here's what I know.

The v3 documentation is still underway, there's a long thread on the
openstack-docs list from October that should help explain the question's
base. Sounds like this patch does indeed affect the way docs are generated
potentially.

http://lists.openstack.org/pipermail/openstack-docs/2013-October/003081.html


On Wed, Dec 18, 2013 at 9:08 AM, Ryan Petrello
<ryan.petrello at dreamhost.com>wrote:

> Additionally, can anyone here summarize the current status of v3
> documentation?  Is there a process I can currently run against Nova to
> generate a WADL (I want to make sure the Pecan changes work with it)?
>
> ---
> Ryan Petrello
> Senior Developer, DreamHost
> ryan.petrello at dreamhost.com
>
> On Dec 18, 2013, at 9:46 AM, Ryan Petrello <ryan.petrello at dreamhost.com>
> wrote:
>
> > Sounds like what I’m hearing is “Let’s see something that uses this
> (that works)”?  I’ll work on that :)
> >
> > ---
> > Ryan Petrello
> > Senior Developer, DreamHost
> > ryan.petrello at dreamhost.com
> >
> > On Dec 18, 2013, at 9:45 AM, Ryan Petrello <ryan.petrello at dreamhost.com>
> wrote:
> >
> >> Jamie:
> >>
> >> Your approach makes sense, but it still uses both pecan and Routes.
>  One of the goals of my patch was to (eventually) be able to remove the use
> of Routes entirely in v3 for Nova once all of the extensions are
> re-implemented with pecan (so that we’re not defining a mix of object
> dispatch and regular-expression style routes).
> >>
> >> ---
> >> Ryan Petrello
> >> Senior Developer, DreamHost
> >> ryan.petrello at dreamhost.com
> >>
> >> On Dec 18, 2013, at 6:05 AM, Jamie Lennox <jamielennox at redhat.com>
> wrote:
> >>
> >>> I attempted this in keystone as part of a very simple extension [1]. I
> understand that it is a much simpler case but nesting the Pecan within the
> existing routing infrastructure, rather than have a single Pecan app was
> fairly simple (though there are some limiting situations).
> >>>
> >>> Any reason you decided to go this way rather than the one in my review?
> >>>
> >>> [1] https://review.openstack.org/#/c/62810/
> >>>
> >>> ----- Original Message -----
> >>>> From: "Ryan Petrello" <ryan.petrello at dreamhost.com>
> >>>> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> >>>> Sent: Wednesday, 18 December, 2013 7:08:09 AM
> >>>> Subject: Re: [openstack-dev] [Nova] Support for Pecan in Nova
> >>>>
> >>>> So any additional feedback on this patch?  I’d love to start working
> on
> >>>> porting some of the other extensions to pecan, but want to make sure
> I’ve
> >>>> got approval on this approach first.
> >>>>
> >>>> https://review.openstack.org/#/c/61303/7
> >>>>
> >>>> ---
> >>>> Ryan Petrello
> >>>> Senior Developer, DreamHost
> >>>> ryan.petrello at dreamhost.com
> >>>>
> >>>> On Dec 14, 2013, at 10:45 AM, Doug Hellmann <
> doug.hellmann at dreamhost.com>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Dec 14, 2013 at 7:55 AM, Christopher Yeoh <cbkyeoh at gmail.com
> >
> >>>>> wrote:
> >>>>>
> >>>>> On Sat, Dec 14, 2013 at 8:48 AM, Doug Hellmann
> >>>>> <doug.hellmann at 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.petrello at 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.petrello at dreamhost.com
> >>>>>
> >>>>> On Dec 13, 2013, at 12:56 PM, Doug Hellmann <
> doug.hellmann at dreamhost.com>
> >>>>> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Dec 12, 2013 at 9:22 PM, Christopher Yeoh <
> cbkyeoh at gmail.com>
> >>>>>> wrote:
> >>>>>> On Fri, Dec 13, 2013 at 4:12 AM, Jay Pipes <jaypipes at 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.hellmann at dreamhost.com
> >>>>>> <mailto:doug.hellmann at dreamhost.com>>wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> >>>>>> ryan.petrello at dreamhost.com
> >>>>>> <mailto:ryan.petrello at 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 at lists.openstack.org
> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> OpenStack-dev mailing list
> >>>>> OpenStack-dev at lists.openstack.org
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OpenStack-dev mailing list
> >>>> OpenStack-dev at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>
> >>> _______________________________________________
> >>> OpenStack-dev mailing list
> >>> OpenStack-dev at lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Anne Gentle
annegentle at justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131218/c3801a0e/attachment-0001.html>