Sure and thanks. Dan, please share your thoughts before I start preparing the bp.
Deepak On Fri, Mar 23, 2012 at 7:12 PM, Rohit Agarwalla (roagarwa) <roaga...@cisco.com> wrote: > 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 -- 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
