Open Stack

I think the option 1) is a better choice. Since:
1. The api and agent talk through RPC. So it is unnecessarily to have both
the api and agent service on the same node. Separate composable service is
more appropriate here.
2. In the l2gw_plugin.ini file, it suggests that the service_provider could
have more than one line. which means the odl and ovs agent might coexisted.

On Thu, Apr 6, 2017 at 9:15 PM, Giulio Fidente <gfidente at redhat.com> wrote:

> On Thu, 2017-04-06 at 13:07 +0200, Ricardo Noriega De Soto wrote:
> > Hi owls!
> >
> > This is something that I've been discussing in the IRC channel but
> > still I
> > think we should define a consistent way of integrating services which
> > support different backends. In this case, I'm refering to BGPVPN and
> > L2GW
> > Neutron services, but it could be applied to any other type of
> > service.
>
> yes indeed there is a similar issue with the storage services and thei
> supported backends
>
> > These two Neutron service plugins support different backends such an
> > agent
> > and a SDN controller (OpenDaylight). Usually the reference
> > architecture
> > will use the agents.
> >
> > My main question is about how to model this into THT properly.
> >
> > It is clear that we have to create two different composable services:
> > one
> > for the API and one for the agent. However, how many environment
> > files we
> > should have and which should be the content?
>
> currently for cinder we use a tht service for each backend; multiple
> backends can be enabled at the same time; having multiple instances of
> the same backend is a bit trickier and requires some yaml editing
>
> > i.e. L2GW project
> >
> > Option 1:
> >
> >    - neutron-l2gw-api.yaml enabling the corresponding API composable
> >    service.
> >    - neutron-l2gw-agent.yaml enabling the corresponding agent
> > composable
> >    service.
> >
> > openstack overcloud deploy -e neutron-l2gw-api.yaml -e
> >  neutron-l2gw-agent.yaml (with agent)
> > openstack overcloud deploy -e neutron-l2gw-api.yaml -e
> >  neutron-opendaylight-l3.yaml (with ODL)
> >
> > Option 2:
> >
> >    - neutron-l2gw.yaml enabling the API and the agent as a reference
> >    architecture scenario.
> >    - neutron-l2gw-odl.yaml enabling the API with OpenDaylight as
> >    service_provider
> >
> > openstack overcloud deploy -e neutron-l2gw.yaml (with agent)
> > openstack overcloud deploy -e neutron-l2gw-odl.yaml -e
> >  neutron-opendaylight-l3.yaml (with ODL)
> >
> >
> > I'm not really pushing for any option, but I'm just concern from the
> > user
> > experience point of view. As a user, which way is more friendly? or
> > understandable? Where in the documentation is this reflected?
>
> I am not sure there is a single answer; option 2) seems to me more user
> friendly and easier to consume in the UI
>
> Yet when working on the integration of CephMDS and the Manila/CephFS
> backend, we decided to use two different environment files, one to
> enable CephMDS and one to enable the CephFS backend in Manila. This was
> so that operators could deploy CephMDS without Manila, to provide
> CephFS to the overcloud or connect the Manila/CephFS backend to an
> external unmanaged Ceph cluster and use only one or the other
> environment file.
>
> My conclusion, if there aren't reasons to deploy the two services
> indepedently, I'd probably go with option 2), if there are reasons to
> deploy only one of them, option 1) is the only one which seems to allow
> that avoiding yaml edits to the users.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Peng Liu | Senior Software Engineer

Tel: +86 10 62608046 (direct)
Mobile: +86 13801193245

Red Hat Software (Beijing) Co., Ltd.
9/F, North Tower C,
Raycom Infotech Park,
No.2 Kexueyuan Nanlu, Haidian District,
Beijing, China, POC 100190
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170406/e6a6e1ef/attachment.html>