Thanks Salvatore, Please find my answers inline. > > However, unfortunately, due to the way in which nova has been integrated with > quantum, we have to create networks with 'nova-manage network create'. Now > this is not on the top of my memory, but I recall the reason was that the > network had to be in the nova database in order for it to allocate IP > addresses, and Quantum clearly does not have access to the nova db. I don't > think this has been solved in Essex, as 'independence from nova DB' is still > one of our «community projects»!
[Deepak] Its not very clear to me how is db an issue here. The problem IMO arises when the api requests made from 'do_request' method in Quantum Manager, didn't include the token. The call looks something like: " Quantum Client Request: POST /v1.1/tenants/default/networks.json " and it is failed by Keystone because no token could be passed in the above api call as nova-manage does not accept tokens. > Still, not all networks are private. There are public networks, and they are > administered directly by the service provider. The way we decided to tackle > this issue was to have a 'service provider' tenant, avoiding adding > complexity by defining models in which networks could be shared by a set of > tenants or all tenants in the case of public networks. [Deepak] nova-manage is not necessary for public networks or administration of networks. This can still be done if the token has admin privileges. We may have to verify this but so far as I have learnt from some past discussions, Glance (and probably swift ) doesn't carry out any activities administrative or otherwise from the nova-manage cli. > Going back to your question, I think that: > - We definitely want to let tenants use a CLI tool which authenticates > request with Keystone, be it nova or quantum; > - We probably still want to use nova-manage for 'public' networks. The > Quantum manager should get a token before sending requests to Quantum in this > case; [Deepak] Implementing the token switch just for 'nova-manage network' doesn't seem a good idea to me. We need to have better solutions if we are thinking in this direction. > - If tenants cannot actively use the networks they create with CLI tools/APIs > as the service provider will still need to run nova-manage network create... > that would be something that needs to be fixed first IMHO! In summary, I think: a. the operations done by nova-manage network cli should be shifted to nova cli b. having two cli for whatever reasons will be confusing and difficult to maintain. c. administration and other tasks should be taken care of in authZ/quantum contexts. The way we can go about implementing is: a. To implement the reqd. nova cli b. declare nova-manage network cli as deprecated c. clean it up later in Folsom when authZ is completed and we are satisfied that we really dont need nova-manage cli any more. Please share your views. Thanks, Deepak > Salvatore > >> -----Original Message----- >> From: netstack- >> bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net >> [mailto:netstack- >> bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of >> Deepak Garg >> Sent: 22 March 2012 01:23 >> To: Jason Kölker >> Cc: netstack@lists.launchpad.net >> Subject: Re: [Netstack] Enabling Quantum AuthN >> >> 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 -- 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
