Open Stack

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.