Deepak, the approach you outlined is perfect. I have been trying to tackle the issue from the Quantum Manager end (v/s the quantum client) when making api requests to Quantum using AuthN. Thought was the implementation mechanism could be reused if either is fixed.
I'm able to request a token from keystone (within Quantum manager using username/password) and then pass that along when a quantum api call is made. Keystone returns the token to QuantumManager, the token gets validated at the Quantum end and then the api request is executed to the plugin. (a quick test that I tried - I was able to create subsequent networks with nova-manage if authN is enabled in Quantum (it was failing earlier)). However, I still have some open design concerns. If possible, it would be great to coordinate and I can also provide inputs on the blueprint. Thanks Rohit >-----Original Message----- >From: Deepak Garg [mailto:deepakgarg.i...@gmail.com] >Sent: Friday, March 23, 2012 3:36 AM >To: Dan Wendlandt >Cc: Rohit Agarwalla (roagarwa); gkot...@redhat.com; >netstack@lists.launchpad.net >Subject: Re: [Netstack] Quantum and Keystone > >Thanx Dan. I had a __long__ fun chat with Salvatore regarding nova + >Quantum yesterday. Please find my >answers in-line > >> 1) network creation no longer happens via nova-manage. Networks are >created >> directly via Quantum API. > >[Deepak] We will have to take feedbacks from the broader community >about this. People using Flat networking might have concerns with it. > >> Because of #2, Quantum will need to authenticate to the Quantum API, >meaning >> it will need an auth token if the Quantum API is performing authn/authz. >> Its likely that this should be an "admin" token of sorts, as Nova is >> presumably an entity trusted by the cloud operation (this of course requires >> that Nova performs is own authn/authz checks). > >[Deepak} I guess above you meant "#2, Quantum Manager will need to" > >> In Folsom, we should shift over to using python-quantumclient as a nova >> dependency (rather than having the quantum client code embedded in >Nova). > >[Deepak] +1. In this case we will have to insert some code in >python-novaclient. Isn't it ? > >> As a result, we'll need to make sure we add keystone support to >> python-quantum client. This is already called out on the community projects >> page: http://wiki.openstack.org/QuantumStarterBugs > >[Deepak] I think, until we figure out nova + quantum issue, I can get >started with the python-quantumclient and keystone integration. I >looked at the code and here is a summary what needs to be done: > >a. enable fetching values from env variables >b. when token is not specified : > i. fetch values from env variables, make call for fetching token >and make api call with that token >c. when token is specified: > i. make the api call > >A no. of failure cases need to be handled here. If you say yes, I can >prepare a short bp on this and clarify a few >questions ( e.g. do we want to support both version 1 and v2 of keystone ) ? > > >Cheers, >Deepak > > >> >> Dan >> >> >> >>> >>> >>> Deepak >>> >>> On Thu, Mar 22, 2012 at 12:08 AM, Rohit Agarwalla (roagarwa) >>> <roaga...@cisco.com> wrote: >>> > I had tried to resolve this issue at my end just prior to RC1 period as >>> > well >>> > (had pointed it out to a limited group then). Couple of config changes >>> > in >>> > quantum.conf that worked for me are as follows - >>> > >>> > >>> > >>> > [filter:authN] >>> > >>> > #this is using the default auth_token.py in keystone middleware >>> > >>> > paste.filter_factory = keystone.middleware.auth_token:filter_factory >>> > >>> > #admin username/password for token validation >>> > >>> > admin_user = admin >>> > >>> > admin_password = nova >>> > >>> > >>> > >>> > $ quantum --token b4c8b3a1370e45e5b96483caa3430aad list_nets >default >>> > >>> > Virtual Networks for Tenant default >>> > >>> > Network ID: 6aad8883-e35d-402c-8d5c-480d8138ca32 >>> > >>> > >>> > >>> > $ quantum --token xxyyzz list_nets default >>> > >>> > An unexpected exception occured:401 Unauthorized >>> > >>> > >>> > >>> > This server could not verify that you are authorized to access the >>> > document >>> > you requested. Either you supplied the wrong credentials (e.g., bad >>> > password), or your browser does not understand how to supply the >>> > credentials >>> > required. >>> > >>> > >>> > >>> > (for the above error message to pop, a change in quantum is needed) >>> > >>> > >>> > >>> > Limited functionality - >>> > >>> > - A valid token works across all tenants using quantum api >>> > >>> > - devstack install errors out if keystone is enabled in quantum >>> > >>> > o work around - install quantum without keystone enabled, enable >>> > keystone, >>> > restart quantum >>> > >>> > >>> > >>> > Maybe Deepak can confirm if these changes are valid and if so we can >>> > update >>> > the documentation. >>> > >>> > >>> > >>> > Thanks >>> > >>> > Rohit >>> > >>> > >>> > >>> > From: netstack-bounces+roagarwa=cisco....@lists.launchpad.net >>> > [mailto:netstack-bounces+roagarwa=cisco....@lists.launchpad.net] On >>> > Behalf >>> > Of Dan Wendlandt >>> > Sent: Wednesday, March 21, 2012 11:01 AM >>> > To: gkot...@redhat.com >>> > Cc: netstack@lists.launchpad.net >>> > Subject: Re: [Netstack] Quantum and Keystone >>> > >>> > >>> > >>> > Hi Gary, >>> > >>> > >>> > >>> > The Quantum Administrator Guide has a section on Quantum + >>> > >>> > Keystone: http://docs.openstack.org/incubation/openstack- >network/admin/content/ch_quantum-keystone-authn-authz.html >>> > >>> > >>> > >>> > Unfortunately, it seems like these instructions are out of date, as the >>> > quantum middleware seems to have been removed from Keystone >(possibly as >>> > part of the keystone redux?). Deepak (on the ML) has been looking into >>> > this, and is best to comment in more detail. >>> > >>> > >>> > >>> > Dan >>> > >>> > >>> > >>> > On Mon, Mar 19, 2012 at 4:39 PM, Gary Kotton <gkot...@redhat.com> >wrote: >>> > >>> > Hi, >>> > Are there any guidelines in configuring Quantum to use Keystone? >>> > Thanks in advance >>> > Gary >>> > >>> > -- >>> > Mailing list: https://launchpad.net/~netstack >>> > Post to : netstack@lists.launchpad.net >>> > Unsubscribe : https://launchpad.net/~netstack >>> > More help : https://help.launchpad.net/ListHelp >>> > >>> > >>> > >>> > >>> > >>> > -- >>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> > Dan Wendlandt >>> > >>> > Nicira Networks: 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 >>> > >>> >>> >>> >>> -- >>> >>> Deepak Garg, >>> Data Center and Cloud Div. >>> Citrix R&D, India >>> Skype-id: deepakgarg.iit >> >> >> >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Dan Wendlandt >> Nicira Networks: www.nicira.com >> twitter: danwendlandt >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > > > >-- > >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
