Open Stack

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.

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?

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?


Some pointers of the L2GW service and agent services:

https://review.openstack.org/#/c/447429/
https://review.openstack.org/#/c/451175/

Cheers

-- 
Ricardo Noriega

Senior Software Engineer - NFV Partner Engineer | Office of Technology  |
Red Hat
irc: rnoriega @freenode
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170406/2b892251/attachment.html>