On Fri, Mar 23, 2012 at 3:35 AM, Deepak Garg <deepakgarg.i...@gmail.com>wrote:
> 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. > The "nova-manage network create" commands will likely still be supported for use with legacy network managers (VLAN, Flat, and FlatDHCP), tough I believe in general the Nova team is looking to get rid of nova-manage in favor of admin APIs. For use with Quantum, I don't see why we'd create a Nova admin API that proxies to Quantum, as the admin can just contact Quantum API directly. > > > 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" > Yup :) > > > 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 ? > Yes, as you describe below. > > > 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 ) > ? > Yes, being able to specify via env would be nice. We also need to rework the client so you can specify username and tenant-id via env (unless someone did that recently). In general, I think we want the way this info is provided to quantum client to look exactly like other openstack clients. I know Maru was interested in working on some improvements to the client, so you may want to ping him to make sure you don't duplicate any work there. In general, my bias would be to only support v2, unless there's a strong need from the community for backward compatibility. Is anyone aware of use cases where v1 is needed? Since our main target for Quantum is Folsom, we should figure out what other services like nova are supporting for Folsom, and do our best to match. Thanks! Dan > > > 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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
