<p>Thanks a lot kevin..</p>
<p>Your explanation has cleared my doubts..</p>
<p>Keeping togethor what i understand...</p>
<p>Suppose, we have a resquest to Nova..</p>
<p>The following steps are performed...</p>
<p>1. The request is captured by webob and is authenticated by keystone and is decorated to wsgi app<br>
2. Nova-api maps the url params to extensions<br>
3. Nova-api extensions return the data dict.. Which webob returns as response to the request in json/xml format...<br>
4. Paste-api helps the keystone and other modules for update of the request...<br></p>
<p>This the request is served... </p>
<p>In the above steps, i might be misunderstanding the concepts..</p>
<p>Kindly please help me by validating my understanding ...</p>
<p>-<br>
Trinath</p>
<div class="gmail_quote">On Dec 6, 2012 11:42 PM, "Kevin L. Mitchell" <<a href="mailto:kevin.mitchell@rackspace.com">kevin.mitchell@rackspace.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's probably best to ask these sorts of questions on the email list, as<br>
it gives an opportunity to others to answer them, as well as allowing<br>
others who may have similar questions to see the answers in the first<br>
place.<br>
<br>
On Thu, 2012-12-06 at 23:24 +0530, Trinath Somanchi wrote:<br>
> [1] In nova or quantum api,<br>
> We can access the .conf params,<br>
><br>
> This way...<br>
><br>
> cfg.Conf.xxxxx as per the soutce code... We can get the<br>
> api-paste-config too.. But i wonder how we can get the paste api confs<br>
> values too accessible this way.... Like, admin_user .....<br>
<br>
PasteDeploy passes configuration options as arguments to the<br>
constructors/factories for the various applications and middleware.<br>
But, as I say, we're trying to avoid relying on this data in nova; the<br>
only consumer of it I am aware of is the Keystone auth_token middleware,<br>
and it has the capability now of specifying its necessary configuration<br>
in the [keystone_authtoken] section of the nova/glance/quantum/cinder<br>
configuration files.  (I suspect the Keystone team is deprecating the<br>
configuration through api-paste.ini.)  This should all be documented in<br>
the PasteDeploy manual…<br>
<br>
> [2] since nova/quantum run as services, how do webob and wsgi play a<br>
> role to prepare the request dict?<br>
<br>
At this point, we leave behind PasteDeploy.  To answer your second<br>
question first, WSGI is an interface specification; it describes how a<br>
web application can be called by the server which receives the HTTP<br>
request.  You can find out more about WSGI from PEP-333, at:<br>
<br>
        <a href="http://www.python.org/dev/peps/pep-0333/" target="_blank">http://www.python.org/dev/peps/pep-0333/</a><br>
<br>
As for webob, that is another package used by nova, etc., which changes<br>
the interface we actually implement; that is, a WSGI application is a<br>
callable taking a dictionary with the environment and a "start_response"<br>
callback, but webob takes these two arguments and encapsulates them in a<br>
Request class, which provides simplified access to the environment data<br>
and some utility methods.  In essence, webob implements the<br>
strange-looking parts of the WSGI interface spec for us, and we can<br>
concentrate on getting the job done.<br>
<br>
> [3] When does( at what level )keystone authentication happens for<br>
> given RESTful request...<br>
<br>
Keystone authentication happens, for most projects, in two separate<br>
pieces of middleware.  The first is auth_token, contained in the<br>
python-keystoneclient package (it was just moved from the keystone<br>
package); this piece of middleware grabs the token out of the incoming<br>
request, verifies that it is a valid and unexpired token, then inserts<br>
various authentication data needed by the project (user and tenant IDs,<br>
for instance).<br>
<br>
The second piece of authentication is more or less a shim between the<br>
Keystone auth_token and the project; it extracts the data that<br>
auth_token injected into the request, then builds a project-specific<br>
authentication context.  This context is how the various projects keep<br>
track of what user made the request, and is used in authorization checks<br>
("Does this user have permission to take this action on this<br>
resource?").<br>
--<br>
Kevin L. Mitchell <<a href="mailto:kevin.mitchell@rackspace.com">kevin.mitchell@rackspace.com</a>><br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div>