[openstack-dev] [devstack] [neutron] How to tell a compute host the control host is running Neutron
mestery at noironetworks.com
Thu Mar 6 14:19:08 UTC 2014
On Tue, Mar 4, 2014 at 7:34 AM, Kyle Mestery <mestery at noironetworks.com>wrote:
> 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  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
>> > 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  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
> ODL MechanismDriver in Neutron, because it's one less agent running on the
> As an update here, I've reworked my devstack patch  for adding
support to make OpenDaylight a top-level service, per suggestion from Dean.
can now enable both "odl-server" and "odl-compute" in your local.conf with
Enabling "odl-server" will run OpenDaylight under devstack. Enabling
will configure the host's OVS to work with OpenDaylight.
Per discussion with Sean, I'd like to look at refactoring some other bits
of the Neutron
devstack code in the coming weeks as well.
>> Sean Dague
>> Samsung Research America
>> sean at dague.net / sean.dague at samsung.com
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev