<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 6, 2014 at 10:24 AM, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kyle,<br>
<br>
I am happy to hear OpenDaylight installation and startup are restored<br>
to devstack.<br>
It really helps openstack integration with other open source based software.<br>
<br>
I have a question on a file location for non-OpenStack open source software.<br>
when I refactored neutron related devstack code, we placed files related to<br>
such files to lib/neutron_thirdparty directory.<br>
I would like to know the new policy of file locations for such software.<br>
I understand it is limited to neutron and it may happens to other projects.<br>
<br>
Thanks,<br>
Akihiro<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div>So, OpenDaylight is unique in that it only runs on the service node with devstack,</div><div>and there is no software running on the compute hosts at all. The way I have it</div>
<div>setup now, it's a toplevel service. This was suggested by Dean and Sean. I think</div><div>it may make sense to move some of the other things (like Trema, Ryu and Floodlight)</div><div>into a similar model.</div>
<div><br></div><div>Thanks,</div><div>Kyle</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
On Thu, Mar 6, 2014 at 11:19 PM, Kyle Mestery <<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>> wrote:<br>
> On Tue, Mar 4, 2014 at 7:34 AM, Kyle Mestery <<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Mar 4, 2014 at 5:46 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
>>><br>
>>> On 03/03/2014 11:32 PM, Dean Troyer wrote:<br>
>>> > On Mon, Mar 3, 2014 at 8:36 PM, Kyle Mestery <<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a><br>
>>> > <mailto:<a href="mailto:mestery@noironetworks.com">mestery@noironetworks.com</a>>> wrote:<br>
>>> ><br>
>>> > In all cases today with Open Source plugins, Neutron agents have<br>
>>> > run<br>
>>> > on the hosts. For OpenDaylight, this is not the case. OpenDaylight<br>
>>> > integrates with Neutron as a ML2 MechanismDriver. But it has no<br>
>>> > Neutron code on the compute hosts. OpenDaylight itself communicates<br>
>>> > directly to those compute hosts to program Open vSwitch.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > devstack doesn't provide a way for me to express this today. On the<br>
>>> > compute hosts in the above scenario, there is no "q-*" services<br>
>>> > enabled, so the "is_neutron_enabled" function returns 1, meaning no<br>
>>> > neutron.<br>
>>> ><br>
>>> ><br>
>>> > True and working as designed.<br>
>>> ><br>
>>> ><br>
>>> > And then devstack sets Nova up to use nova-networking, which fails.<br>
>>> ><br>
>>> ><br>
>>> > This only happens if you have enabled nova-network. Since it is on by<br>
>>> > default you must disable it.<br>
>>> ><br>
>>> ><br>
>>> > The patch I have submitted [1] modifies "is_neutron_enabled" to<br>
>>> > check for the meta neutron service being enabled, which will then<br>
>>> > configure nova to use Neutron instead of nova-networking on the<br>
>>> > hosts. If this sounds wonky and incorrect, I'm open to suggestions<br>
>>> > on how to make this happen.<br>
>>> ><br>
>>> ><br>
>>> > From the review:<br>
>>> ><br>
>>> > is_neutron_enabled() is doing exactly what it is expected to do, return<br>
>>> > success if it finds any "q-*" service listed in ENABLED_SERVICES. If no<br>
>>> > neutron services are configured on a compute host, then this must not<br>
>>> > say they are.<br>
>>> ><br>
>>> > Putting 'neutron' in ENABLED_SERVICES does nothing and should do<br>
>>> > nothing.<br>
>>> ><br>
>>> > Since you are not implementing the ODS as a Neutron plugin (as far as<br>
>>> > DevStack is concerned) you should then treat it as a system service and<br>
>>> > configure it that way, adding 'opendaylight' to ENABLED_SERVICES<br>
>>> > whenever you want something to know it is being used.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > Note: I have another patch [2] which enables an OpenDaylight<br>
>>> > service, including configuration of OVS on hosts. But I cannot<br>
>>> > check<br>
>>> > if the "opendaylight" service is enabled, because this will only<br>
>>> > run<br>
>>> > on a single node, and again, not on each compute host.<br>
>>> ><br>
>>> ><br>
>>> > I don't understand this conclusion. in multi-node each node gets its<br>
>>> > own<br>
>>> > specific ENABLED_SERVICES list, you can check that on each node to<br>
>>> > determine how to configure that node. That is what I'm trying to<br>
>>> > explain in that last paragraph above, maybe not too clearly.<br>
>>><br>
>>> So in an Open Daylight environment... what's running on the compute host<br>
>>> to coordinate host level networking?<br>
>>><br>
>> Nothing. OpenDaylight communicates to each host using OpenFlow and OVSDB<br>
>> to manage networking on the host. In fact, this is one huge advantage for<br>
>> the<br>
>> ODL MechanismDriver in Neutron, because it's one less agent running on the<br>
>> host.<br>
>><br>
>> Thanks,<br>
>> Kyle<br>
>><br>
> As an update here, I've reworked my devstack patch [1] for adding<br>
> OpenDaylight<br>
> support to make OpenDaylight a top-level service, per suggestion from Dean.<br>
> You<br>
> can now enable both "odl-server" and "odl-compute" in your local.conf with<br>
> my patch.<br>
> Enabling "odl-server" will run OpenDaylight under devstack. Enabling<br>
> "odl-compute"<br>
> will configure the host's OVS to work with OpenDaylight.<br>
><br>
> Per discussion with Sean, I'd like to look at refactoring some other bits of<br>
> the Neutron<br>
> devstack code in the coming weeks as well.<br>
><br>
> Thanks!<br>
> Kyle<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/69774/" target="_blank">https://review.openstack.org/#/c/69774/</a><br>
><br>
>>><br>
>>> -Sean<br>
>>><br>
>>> --<br>
>>> Sean Dague<br>
>>> Samsung Research America<br>
>>> <a href="mailto:sean@dague.net">sean@dague.net</a> / <a href="mailto:sean.dague@samsung.com">sean.dague@samsung.com</a><br>
>>> <a href="http://dague.net" target="_blank">http://dague.net</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>