On Wed, Mar 21, 2012 at 12:31 PM, Deepak Garg <deepakgarg.i...@gmail.com>wrote:

> Yes, Rohit these changes are valid. The thing you pointed out about
> making authentication working
> with Devstack and Quantum is also perfect. I didn't propose to update
> the documentation because
> things are not perfect and I needed to test everything.
>
> In the other email thread "Enabling Quantum Auth" I am discussing
> about the possible solutions.
> I was looking into Glance and Swift's implementation and had some
> discussion and Michael pointed out
> that we might start shifting to the 'nova' cli instead of using the
> 'nova-manage' cli for a permanent solution.
> Glance (and probably Swift ) doesn't manage resources using the
> nova-manage cmd at all. This makes
> sense because the use of nova-manage sub-commands seem to be deprecating.
>
> Can someone please update me where are we in terms of Nova + Quantum
> discussion ?
>

Hi Deepak,

We'll have a session @ the design summit on plans for Nova + Quantum
changes in Folsom, but here's a quick summary of what I expect:

1) network creation no longer happens via nova-manage.  Networks are
created directly via Quantum API.
2) Nova will still communicate with quantum as a client, in order to create
and plug ports when a VM is spun up (and possibly to view the set of
networks that exist for a particular tenant, in a read-only fashion).

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).

In Folsom, we should shift over to using python-quantumclient as a nova
dependency (rather than having the quantum client code embedded in Nova).
 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

Let me know if you have any other questions.  Great to see all of the
progress on this front!

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
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