Open Stack

Hi Kyle,

I am happy to hear OpenDaylight installation and startup are restored
to devstack.
It really helps openstack integration with other open source based software.

I have a question on a file location for non-OpenStack open source software.
when I refactored neutron related devstack code, we placed files related to
such files to lib/neutron_thirdparty directory.
I would like to know the new policy of file locations for such software.
I understand it is limited to neutron and it may happens to other projects.

Thanks,
Akihiro


On Thu, Mar 6, 2014 at 11:19 PM, Kyle Mestery <mestery at noironetworks.com> wrote:
> 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 [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
>>
> As an update here, I've reworked my devstack patch [1]  for adding
> OpenDaylight
> support to make OpenDaylight a top-level service, per suggestion from Dean.
> You
> can now enable both "odl-server" and "odl-compute" in your local.conf with
> my patch.
> Enabling "odl-server" will run OpenDaylight under devstack. Enabling
> "odl-compute"
> 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.
>
> Thanks!
> Kyle
>
> [1] https://review.openstack.org/#/c/69774/
>
>>>
>>>         -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
>>>
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>