On Thu, Mar 6, 2014 at 10:24 AM, Akihiro Motoki <amot...@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 > > So, OpenDaylight is unique in that it only runs on the service node with devstack, and there is no software running on the compute hosts at all. The way I have it setup now, it's a toplevel service. This was suggested by Dean and Sean. I think it may make sense to move some of the other things (like Trema, Ryu and Floodlight) into a similar model. Thanks, Kyle > > On Thu, Mar 6, 2014 at 11:19 PM, Kyle Mestery <mest...@noironetworks.com> > wrote: > > On Tue, Mar 4, 2014 at 7:34 AM, Kyle Mestery <mest...@noironetworks.com> > > wrote: > >> > >> On Tue, Mar 4, 2014 at 5:46 AM, Sean Dague <s...@dague.net> wrote: > >>> > >>> On 03/03/2014 11:32 PM, Dean Troyer wrote: > >>> > On Mon, Mar 3, 2014 at 8:36 PM, Kyle Mestery < > mest...@noironetworks.com > >>> > <mailto:mest...@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 > >>> s...@dague.net / sean.da...@samsung.com > >>> http://dague.net > >>> > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
