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 <[email protected]> wrote: > On Tue, Mar 4, 2014 at 7:34 AM, Kyle Mestery <[email protected]> > wrote: >> >> On Tue, Mar 4, 2014 at 5:46 AM, Sean Dague <[email protected]> wrote: >>> >>> On 03/03/2014 11:32 PM, Dean Troyer wrote: >>> > On Mon, Mar 3, 2014 at 8:36 PM, Kyle Mestery <[email protected] >>> > <mailto:[email protected]>> 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 >>> [email protected] / [email protected] >>> http://dague.net >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
