Open Stack

 I think the answer here should be if we want to define environment files
as a whole
“With all the information required to deploy something functional” or
composing them like
a LEGO (which might not work separately).

I don't have a strong opinion about it, but I'm inclined to use them as
functional blocks, i.e. if you want to deploy the pacemaker profiles you
just have to include puppet-pacemaker.yaml and that's all.

What IMHO would do is:

* -e neutron-l2gw-basic.yaml → Will install the API and the agent.
* -e neutron-l2gw-odl.yaml → Will install the API and ODL.

The API is a common factor here so we can add it into all envs using it.
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.

What do you think about it?

Cheers,
Carlos.




On Thu, Apr 6, 2017 at 1:07 PM, Ricardo Noriega De Soto <rnoriega at redhat.com>
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.
>
> 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170406/afa62e91/attachment.html>