I now think the right approach is to move to shift the implementation of network operations to 'nova' cli and giving up 'nova-manage' cli for a permanent solution because: a. use of nova-manage sub-cmds seems to be deprecated. b. nova cli accepts tokens and have caching options c. other projects seem to have done the same.
Please share your views regarding the same. Thanks, Deepak On Wed, Mar 21, 2012 at 2:22 PM, Deepak Garg <deepakgarg.i...@gmail.com> wrote: > Thanks Jason for the idea. > > I am not sure how good is an idea of running two endpoints for quantum > - one with 'noauth' and one with 'keystone'. > If you have seen any such use case with other services please let me know. > > Nova defines two piplines: 'noauth' and 'keystone' and it chooses > between them using the 'auth_strategy' flag > in nova.conf. > So a similar approach in our case could be to change the " > composite:quantum" and route the requests made from 'do_request' to a > different url. Currently the call looks something like: > " Quantum Client Request: POST /v1.1/tenants/default/networks.json " > > So the calls made from client.py could be changed to something like > " Quantum Client Request: POST > /nova-manage/v1.1/tenants/default/networks.json" > and in "composite:quantum" the requests to "/nova-manage/" could be > routed to an app with "noauth" in the front. > > This is not perfect but I think this will get the ball rolling and > enable authN so that we can proceed with authZ until we > figure out the Nova + Quantum issue. > > Please share your views. > > > Thanks, > Deepak > > > On Mon, Mar 19, 2012 at 11:47 PM, Jason Kölker <jkoel...@rackspace.com> wrote: >> On Mon, 2012-03-19 at 22:41 +0530, Deepak Garg wrote: >>> HI All, >>> >>> Basic AuthZ + AuthN was implemented at >>> https://review.openstack.org/#change,1322 but was lost in the Keystone >>> redux baseline. >>> However most of the work is included in the generic auth_token.py in >>> the keystone tree which is used by all projects for token >>> verification. >>> Enabling AuthN in Quantum needs simple changes in the conf file. >>> But when $ nova-manage network cmds are used, it fails because of >>> authorization error: http://paste.openstack.org/show/10961/ >>> Its because nova-manage doesn't accepts tokens, probably because its >>> only meant to be only on the server side and not client side. >>> One solution to this is to write a middleware to be included before authN. >>> >>> Glance doesn't run into this issue because there are no image related >>> nova-manage cmds. >>> Please post any other solution/suggestions. >> >> Yea this is all going to have to change soon. Right now the only option >> is to run another quantum endpoint for nova to hit that is running >> without keystone in front of it. Essentially in "noauth" mode. >> >> At the summit I think we are going to talk about the integration pieces >> of Nove + Quantum + (Melange being merged with quantum). >> >> Happy Hacking! >> >> 7-11 >> >> >> -- >> Mailing list: https://launchpad.net/~netstack >> Post to : netstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~netstack >> More help : https://help.launchpad.net/ListHelp > > > > -- > > Deepak Garg, > Data Center and Cloud Div. > Citrix R&D, India > Skype-id: deepakgarg.iit -- Deepak Garg, Data Center and Cloud Div. Citrix R&D, India Skype-id: deepakgarg.iit -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
