Open Stack

Kyle,

Please, point me to the wiki with the documentation for testing the
devstack patch!
This work seems to be very interesting. Yeah!!! I love to have one more
agent less but let's have all agents gone once for all.  :-)

Edgar

On 3/6/14 8:24 AM, "Akihiro Motoki" <amotoki at gmail.com> wrote:

>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
>>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev