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.mitch...@rackspace.com> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp