This is my understanding as well. I reckon that removing the need for using nova-manage for Quantum networks should also make unnecessary moving network-related nova-manage operations to nova CLI.
The 'admin user' authentication for Nova <-> Quantum interactions should be good enough in many cases. A rather simple alternative could be forwarding the users' token between Nova and Quantum; however I'm not sure I would be comfortable knowing the API provider keeps my authentication token and forwards it to 3rd parties, unless explicitly authorized to do so. Another alternative I am considering is to have Nova authenticating as a 'service' rather than a 'real' user. 'Service' users might be preventing from operating on network objects; we might even think of having 'real' users explicitly delegating 'service' user to operate on their networks. For instance, service user 'nova' will be allowed to create ports and plug interface into user 'foo' networks only if 'foo' explicitly allows it. Salvatore From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 01 April 2012 10:26 To: Salvatore Orlando Cc: Deepak Garg; netstack@lists.launchpad.net Subject: Re: [Netstack] Enabling Quantum AuthN Ok, so to summarize, this is my understanding of how things will work moving forward: - it seems that all of nova-manage is going away in Folsom (this is a nova team decision). Many of the calls will be replaced with nova "admin API" calls. - in Folsom, we are removing the requirement that all quantum networks are created via nova using nova-manage. Instead, they will be created using the quantum cli tool directly hitting the Quantum API. This will be the case whether they are tenant specific networks, or service provider networks. - Nova will still need to be able to communicate with the Quantum API to create and delete ports when VMs are created and destroyed. Thus, it will need to act as an authenticated client of the Quantum API. My assumption has been that it would do so as some kind of admin user that would let it add ports even on service-provider networks as needed. Dan On Thu, Mar 22, 2012 at 4:58 AM, Salvatore Orlando <salvatore.orla...@eu.citrix.com<mailto:salvatore.orla...@eu.citrix.com>> wrote: Replies inline Cheers, Salvatore > -----Original Message----- > From: Deepak Garg > [mailto:deepakgarg.i...@gmail.com<mailto:deepakgarg.i...@gmail.com>] > Sent: 22 March 2012 10:43 > To: Salvatore Orlando > Cc: Jason Kölker; > netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> > Subject: Re: [Netstack] Enabling Quantum AuthN > > 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: The DB issue does not regard authentication at all. My point was that this implies that at the moment we need to issue the request to the Quantum Manager, and the Quantum manager will then have to authenticate with Quantum. Sorry I should have been more clear. > " 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. > And also the Quantum Manager which is invoked by nova-manage network create, does not pass the token to Quantum service (where authentication occurs). > > 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. Token exchange would not be for nova-manage network. It would be between the Quantum Manager and the Quantum API. > > > - 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. Our final goal is to support authentication in Quantum. It seems to me that we are instead discussing options for managing quantum networks through the CLI. I was probably expecting more of a discussion on Quantum integration with Keystone first, and after that a discussion about how tokens should be passed to the API by the various CLI tools. I am probably missing something here... can you help me? > c. administration and other tasks should be taken care of in authZ/quantum > contexts. I don't understand this. What do you mean by 'administration and other tasks'? > > The way we can go about implementing is: > a. To implement the reqd. nova cli We have a Quantum CLI too. Do you reckon we should migrate the commands in this CLI to nova? > 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. Earlier you said that nova-manage subcommands are already deprecated. I did not know that, but if that is the case, shouldn't nova-manage networks commands already be deprecated. > > Please share your views. > > Thanks, > Deepak > > > > > Salvatore > > > >> -----Original Message----- > >> From: netstack- > >> bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net<mailto:eu.citrix....@lists.launchpad.net> > >> [mailto:netstack-<mailto:netstack-> > >> bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net<mailto:eu.citrix....@lists.launchpad.net>] > >> On > >> bounces+Behalf Of > >> Deepak Garg > >> Sent: 22 March 2012 01:23 > >> To: Jason Kölker > >> Cc: netstack@lists.launchpad.net<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com<http://www.nicira.com> twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
