<div dir="ltr">I think the option 1) is a better choice. Since:<div>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.</div><div>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. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 9:15 PM, Giulio Fidente <span dir="ltr"><<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2017-04-06 at 13:07 +0200, Ricardo Noriega De Soto wrote:<br>
> Hi owls!<br>
><br>
> This is something that I've been discussing in the IRC channel but<br>
> still I<br>
> think we should define a consistent way of integrating services which<br>
> support different backends. In this case, I'm refering to BGPVPN and<br>
> L2GW<br>
> Neutron services, but it could be applied to any other type of<br>
> service.<br>
<br>
</span>yes indeed there is a similar issue with the storage services and thei<br>
supported backends<br>
<span class=""><br>
> These two Neutron service plugins support different backends such an<br>
> agent<br>
> and a SDN controller (OpenDaylight). Usually the reference<br>
> architecture<br>
> 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:<br>
> one<br>
> for the API and one for the agent. However, how many environment<br>
> files we<br>
> should have and which should be the content?<br>
<br>
</span>currently for cinder we use a tht service for each backend; multiple<br>
backends can be enabled at the same time; having multiple instances of<br>
the same backend is a bit trickier and requires some yaml editing<br>
<span class=""><br>
> i.e. L2GW project<br>
><br>
> Option 1:<br>
><br>
</span>>    - neutron-l2gw-api.yaml enabling the corresponding API composable<br>
>    service.<br>
>    - neutron-l2gw-agent.yaml enabling the corresponding agent<br>
<span class="">> composable<br>
>    service.<br>
><br>
> openstack overcloud deploy -e neutron-l2gw-api.yaml -e<br>
>  neutron-l2gw-agent.yaml (with agent)<br>
> openstack overcloud deploy -e neutron-l2gw-api.yaml -e<br>
>  neutron-opendaylight-l3.yaml (with ODL)<br>
><br>
> Option 2:<br>
><br>
</span>>    - neutron-l2gw.yaml enabling the API and the agent as a reference<br>
>    architecture scenario.<br>
>    - neutron-l2gw-odl.yaml enabling the API with OpenDaylight as<br>
<span class="">>    service_provider<br>
><br>
> openstack overcloud deploy -e neutron-l2gw.yaml (with agent)<br>
> openstack overcloud deploy -e neutron-l2gw-odl.yaml -e<br>
>  neutron-opendaylight-l3.yaml (with ODL)<br>
><br>
><br>
> I'm not really pushing for any option, but I'm just concern from the<br>
> user<br>
> experience point of view. As a user, which way is more friendly? or<br>
> understandable? Where in the documentation is this reflected?<br>
<br>
</span>I am not sure there is a single answer; option 2) seems to me more user<br>
friendly and easier to consume in the UI<br>
<br>
Yet when working on the integration of CephMDS and the Manila/CephFS<br>
backend, we decided to use two different environment files, one to<br>
enable CephMDS and one to enable the CephFS backend in Manila. This was<br>
so that operators could deploy CephMDS without Manila, to provide<br>
CephFS to the overcloud or connect the Manila/CephFS backend to an<br>
external unmanaged Ceph cluster and use only one or the other<br>
environment file.<br>
<br>
My conclusion, if there aren't reasons to deploy the two services<br>
indepedently, I'd probably go with option 2), if there are reasons to<br>
deploy only one of them, option 1) is the only one which seems to allow<br>
that avoiding yaml edits to the users.<br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><font face="arial, helvetica, sans-serif" size="2">Peng Liu | Senior Software Engineer</font><div><font face="arial, helvetica, sans-serif" size="2"><br>Tel: +</font><span style="font-size:12.8px">86 10 62608046</span><font face="arial, helvetica, sans-serif" size="2"> (direct)<br>Mobile: +86 13801193245</font></div><div><font face="arial, helvetica, sans-serif" size="2"><br>Red Hat Software (Beijing) Co., Ltd.<br><span style="color:rgb(0,0,0)">9/F, North Tower C, </span></font><div><font face="arial, helvetica, sans-serif" size="2"><span style="color:rgb(0,0,0)">Raycom Infotech Park, </span></font></div><div><font face="arial, helvetica, sans-serif" size="2"><span style="color:rgb(0,0,0)">No.2 Kexueyuan Nanlu, Haidian District, </span></font></div><div><font face="arial, helvetica, sans-serif" size="2"><span style="color:rgb(0,0,0)">Beijing, China, POC 100190</span></font><br></div></div></div></div></div></div>
</div>