Hi, One of the differences between nova-manage and nova is that the former is a 'service provider' tool, whereas the latter is a 'tenant' tool. For several tasks, nova-manage does even use the API at all. For instance when it creates a network, it just imports the network manager class and invokes create_networks.
One of the main goals for Quantum is to enable tenants to build and configure their networks; hence we definitely want the Quantum CLI to be able to authenticate tenants with Keystone. Whether we use a single tool (nova CLI) or a distinct tool (quantum CLI) is another story, and there are pro and cons for both approaches. I personally lean towards to separate tools options. 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»! 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. 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; - 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! 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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
