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