<div dir="ltr">                 I think the answer here should be if we want to define environment files as a whole<div>“With all the information required to deploy something functional” or composing them like</div><div>a LEGO (which might not work separately).<div><br>I don't have a strong opinion about it, but I'm inclined to use them as</div><div>functional blocks, i.e. if you want to deploy the pacemaker profiles you</div><div>just have to include puppet-pacemaker.yaml and that's all.<br><br>What IMHO would do is:<br><br>* -e neutron-l2gw-basic.yaml → Will install the API and the agent.<br>* -e neutron-l2gw-odl.yaml → Will install the API and ODL.<br><br>The API is a common factor here so we can add it into all envs using it.<br>Also, I think will be easier from a user POV as they won't have to master how to compose their environment files to have it running.<br><br>What do you think about it?<br><br>Cheers,</div><div>Carlos.<br><br><br><br><br>On Thu, Apr 6, 2017 at 1:07 PM, Ricardo Noriega De Soto <<a href="mailto:rnoriega@redhat.com">rnoriega@redhat.com</a>> wrote:<br>><br>> Hi owls!<br>><br>> 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.<br>><br>> These two Neutron service plugins support different backends such an agent and a SDN controller (OpenDaylight). Usually the reference architecture will use the agents.<br>><br>> My main question is about how to model this into THT properly.<br>><br>> 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?<br>><br>> i.e. L2GW project<br>><br>> Option 1: <br>><br>> neutron-l2gw-api.yaml enabling the corresponding API composable service.<br>> neutron-l2gw-agent.yaml enabling the corresponding agent composable service.<br>><br>> openstack overcloud deploy -e neutron-l2gw-api.yaml -e  neutron-l2gw-agent.yaml (with agent)<br>> openstack overcloud deploy -e neutron-l2gw-api.yaml -e  neutron-opendaylight-l3.yaml (with ODL)<br>><br>> Option 2:<br>><br>> neutron-l2gw.yaml enabling the API and the agent as a reference architecture scenario.<br>> neutron-l2gw-odl.yaml enabling the API with OpenDaylight as service_provider<br>><br>> openstack overcloud deploy -e neutron-l2gw.yaml (with agent)<br>> openstack overcloud deploy -e neutron-l2gw-odl.yaml -e  neutron-opendaylight-l3.yaml (with ODL)<br>><br>><br>> 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?<br>><br>><br>> Some pointers of the L2GW service and agent services:<br>><br>> <a href="https://review.openstack.org/#/c/447429/">https://review.openstack.org/#/c/447429/</a><br>> <a href="https://review.openstack.org/#/c/451175/">https://review.openstack.org/#/c/451175/</a><br>><br>> Cheers<br>><br>> --<br>> Ricardo Noriega<br>><br>> Senior Software Engineer - NFV Partner Engineer | Office of Technology  | Red Hat<br>> irc: rnoriega @freenode<br>><br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>><br></div></div></div>