openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

It's probably best to ask these sorts of questions on the email list, as
it gives an opportunity to others to answer them, as well as allowing
others who may have similar questions to see the answers in the first
place.

On Thu, 2012-12-06 at 23:24 +0530, Trinath Somanchi wrote:
> [1] In nova or quantum api,
> We can access the .conf params,
> 
> This way...
> 
> cfg.Conf.xxxxx as per the soutce code... We can get the
> api-paste-config too.. But i wonder how we can get the paste api confs
> values too accessible this way.... Like, admin_user .....

PasteDeploy passes configuration options as arguments to the
constructors/factories for the various applications and middleware.
But, as I say, we're trying to avoid relying on this data in nova; the
only consumer of it I am aware of is the Keystone auth_token middleware,
and it has the capability now of specifying its necessary configuration
in the [keystone_authtoken] section of the nova/glance/quantum/cinder
configuration files.  (I suspect the Keystone team is deprecating the
configuration through api-paste.ini.)  This should all be documented in
the PasteDeploy manual…

> [2] since nova/quantum run as services, how do webob and wsgi play a
> role to prepare the request dict?

At this point, we leave behind PasteDeploy.  To answer your second
question first, WSGI is an interface specification; it describes how a
web application can be called by the server which receives the HTTP
request.  You can find out more about WSGI from PEP-333, at:

        http://www.python.org/dev/peps/pep-0333/

As for webob, that is another package used by nova, etc., which changes
the interface we actually implement; that is, a WSGI application is a
callable taking a dictionary with the environment and a "start_response"
callback, but webob takes these two arguments and encapsulates them in a
Request class, which provides simplified access to the environment data
and some utility methods.  In essence, webob implements the
strange-looking parts of the WSGI interface spec for us, and we can
concentrate on getting the job done.

> [3] When does( at what level )keystone authentication happens for
> given RESTful request...

Keystone authentication happens, for most projects, in two separate
pieces of middleware.  The first is auth_token, contained in the
python-keystoneclient package (it was just moved from the keystone
package); this piece of middleware grabs the token out of the incoming
request, verifies that it is a valid and unexpired token, then inserts
various authentication data needed by the project (user and tenant IDs,
for instance).

The second piece of authentication is more or less a shim between the
Keystone auth_token and the project; it extracts the data that
auth_token injected into the request, then builds a project-specific
authentication context.  This context is how the various projects keep
track of what user made the request, and is used in authorization checks
("Does this user have permission to take this action on this
resource?").
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>