[openstack-dev] [devstack] [neutron] How to tell a compute host the control host is running Neutron

Kyle Mestery mestery at noironetworks.com
Tue Mar 4 13:34:51 UTC 2014


On Tue, Mar 4, 2014 at 5:46 AM, Sean Dague <sean at dague.net> wrote:

> On 03/03/2014 11:32 PM, Dean Troyer wrote:
> > On Mon, Mar 3, 2014 at 8:36 PM, Kyle Mestery <mestery at noironetworks.com
> > <mailto:mestery at noironetworks.com>> wrote:
> >
> >     In all cases today with Open Source plugins, Neutron agents have run
> >     on the hosts. For OpenDaylight, this is not the case. OpenDaylight
> >     integrates with Neutron as a ML2 MechanismDriver. But it has no
> >     Neutron code on the compute hosts. OpenDaylight itself communicates
> >     directly to those compute hosts to program Open vSwitch.
> >
> >
> >
> >     devstack doesn't provide a way for me to express this today. On the
> >     compute hosts in the above scenario, there is no "q-*" services
> >     enabled, so the "is_neutron_enabled" function returns 1, meaning no
> >     neutron.
> >
> >
> > True and working as designed.
> >
> >
> >     And then devstack sets Nova up to use nova-networking, which fails.
> >
> >
> > This only happens if you have enabled nova-network.  Since it is on by
> > default you must disable it.
> >
> >
> >     The patch I have submitted [1] modifies "is_neutron_enabled" to
> >     check for the meta neutron service being enabled, which will then
> >     configure nova to use Neutron instead of nova-networking on the
> >     hosts. If this sounds wonky and incorrect, I'm open to suggestions
> >     on how to make this happen.
> >
> >
> > From the review:
> >
> > is_neutron_enabled() is doing exactly what it is expected to do, return
> > success if it finds any "q-*" service listed in ENABLED_SERVICES. If no
> > neutron services are configured on a compute host, then this must not
> > say they are.
> >
> > Putting 'neutron' in ENABLED_SERVICES does nothing and should do nothing.
> >
> > Since you are not implementing the ODS as a Neutron plugin (as far as
> > DevStack is concerned) you should then treat it as a system service and
> > configure it that way, adding 'opendaylight' to ENABLED_SERVICES
> > whenever you want something to know it is being used.
> >
> >
> >
> >     Note: I have another patch [2] which enables an OpenDaylight
> >     service, including configuration of OVS on hosts. But I cannot check
> >     if the "opendaylight" service is enabled, because this will only run
> >     on a single node, and again, not on each compute host.
> >
> >
> > I don't understand this conclusion. in multi-node each node gets its own
> > specific ENABLED_SERVICES list, you can check that on each node to
> > determine how to configure that node.  That is what I'm trying to
> > explain in that last paragraph above, maybe not too clearly.
>
> So in an Open Daylight environment... what's running on the compute host
> to coordinate host level networking?
>
> Nothing. OpenDaylight communicates to each host using OpenFlow and OVSDB
to manage networking on the host. In fact, this is one huge advantage for
the
ODL MechanismDriver in Neutron, because it's one less agent running on the
host.

Thanks,
Kyle

        -Sean
>
> --
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140304/edc6685d/attachment.html>


More information about the OpenStack-dev mailing list