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

Reply via email to