Open Stack

On Wed, May 29, 2013 at 9:56 PM, Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp
> wrote:

>
> Hi,
>
> I'd like to know should we apply Pecan/WSME to the existing projects
> (nova, cinder etc).
>
> IIUC, API URLs and API parameters should be on python naming rule if
> applying Pecan/WSME, because Pecan builds API URL by referring for a
> module path to API method. For example, the API URL of the following
> Pecan/WSME sample is "http://<hostname>:<port>/foo" for POST method.
>
> ===
>   app = pecan.make_app(RootController, ..)
>
>   class RootController(object):
>       foo = Foo()
>
>   class Foo(rest.RestController):
>       @wsexpose(..)
>       def post(self, data):
>           ..
> ===
>
> According to http://api.openstack.org/api-ref.html, current API URLs
> contains "-" such as "v2/{tenant_id}/os-floating-ips". We cannot create
> "os-floating-ips = Foo()" due to python naming rule, so I guess we need
> to change API URLs if applying Pecan/WSME. Now there are many APIs and
> Pecan/WSME will influence a lot of API design.
> Are there any workarounds?
>

We will need to make some changes to the APIs because of both Pecan and
WSME. That's why the proposal is to move to the tools as each project
builds a new version of its API, and not to go back and rebuild the old API
servers. We can establish new naming and design conventions that make life
easier with the new tools.

Doug


>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
> On Wed, 29 May 2013 20:07:12 -0400
> Doug Hellmann <doug.hellmann at dreamhost.com> wrote:
> >
> > I have -2ed several changes to the wsgi module in oslo-incubator in the
> > last few weeks, and I wanted to bring it up on the list to explain the
> > reasons more broadly.
> >
> > At the last summit we agreed that the goal was to start deprecating our
> > home-grown WSGI service implementation in favor of moving to a new set of
> > tools called Pecan and WSME (
> > https://etherpad.openstack.org/havana-common-wsgi). While I understand
> that
> > we can't just drop everything and build new API servers, I do feel
> strongly
> > that we should not continue developing new features for the module we are
> > deprecating.
> >
> > I don't see any other projects with "wsgi" in their
> openstack-common.conf,
> > nor did I find any copies of openstack/common/wsgi.py in any other
> > projects. I did find several wsgi.py files in different directories in
> the
> > projects. I take that to mean that we are/were still in the process of
> > unifying the various forked versions of the module, and I propose that we
> > just not bother doing more work on that. Since no project is already
> using
> > Oslo's wsgi module, I'm not sure it makes sense to bring bug fixes into
> > Oslo, either. If I've missed something, and projects are in fact using
> the
> > module, then we should continue to deal with bug fixes.
> >
> > To officially indicate the module as deprecated, Mark suggested moving it
> > to openstack/common/deprecated/wsgi.py. I have done that in changeset
> > https://review.openstack.org/#/c/30972/. As the commit log message
> > mentions, there is still some work to be done to remove the dependency
> > between one or two of the middleware classes and the now deprecated
> module.
> > I would appreciate any ideas about the best way to do that from folks who
> > know about those modules.
> >
> > As we move to the new tools, I am sure we will find new bits of code
> > related to setting up those projects that we can share. For example, the
> > code to configure the keystone middleware for an API service shouldn't
> need
> > to be repeated across all of the projects. We should start a new module
> to
> > hold those pieces, taken from the projects that are starting to use Pecan
> > and WSME already. I volunteer to be the primary maintainer for that new
> > module within Oslo.
> >
> > Doug
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130530/795de7bf/attachment.html>