Open Stack

On Thu, Mar 6, 2014 at 10: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
>
> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140306/dfe6be86/attachment.html>