Open Stack

We are looking at contrail now and it does have some downsides to their
arhitecture. Because it overrides most of the APIs it lags behind the more
recent branches. In addition it assumes control over many functions that
sometimes lag behind. However the compelling reason for us was the ability
to use L3 functionality to "bridge" networks between different sites. If
this could be implement from an L3 perspective (API as well), that would be
best.

On Friday, April 1, 2016, Dan Sneddon <dsneddon at redhat.com> wrote:

> On 04/01/2016 03:18 PM, Adam Lawson wrote:
> > Hi Dan - thanks I think that answers the core plugin question. What is
> > Contrail doing with the Neutron service plugin? Are there two plugins?
> >
> > //adam
> >
> > */
> > Adam Lawson/*
> >
> > AQORN, Inc.
> > 427 North Tatnall Street
> > Ste. 58461
> > Wilmington, Delaware 19801-2230
> > Toll-free: (844) 4-AQORN-NOW ext. 101
> > International: +1 302-387-4660
> > Direct: +1 916-246-2072
> >
> > On Fri, Apr 1, 2016 at 2:13 PM, Dan Sneddon <dsneddon at redhat.com
> <javascript:;>
> > <mailto:dsneddon at redhat.com <javascript:;>>> wrote:
> >
> >     On 04/01/2016 02:07 PM, Dan Sneddon wrote:
> >     > On 04/01/2016 01:07 PM, Adam Lawson wrote:
> >     >> The Contrail team that said they are using their network product
> >     with
> >     >> OpenStack without requiring a mechanism driver with the ML2
> plugin.
> >     >> More specifically, they said they don't use or need ML2. I
> >     didn't have
> >     >> a chance to ask them to clarify so I'm wondering how that works
> and
> >     >> what is current best practice? I think the individual misspoke
> but I
> >     >> wanted to see if this is actually being done today.
> >     >>
> >     >> Perhaps they replaced ML2 with something - exactly what though?
> >     >>
> >     >> //adam
> >     >>
> >     >> */
> >     >> Adam Lawson/*
> >     >>
> >     >> AQORN, Inc.
> >     >> 427 North Tatnall Street
> >     >> Ste. 58461
> >     >> Wilmington, Delaware 19801-2230
> >     >> Toll-free: (844) 4-AQORN-NOW ext. 101
> >     >> International: +1 302-387-4660
> >     >> Direct: +1 916-246-2072
> >     >>
> >     >>
> >     >> _______________________________________________
> >     >> OpenStack-operators mailing list
> >     >> OpenStack-operators at lists.openstack.org <javascript:;>
> >     <mailto:OpenStack-operators at lists.openstack.org <javascript:;>>
> >     >>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >     >>
> >     >
> >     > ML2 is what's known as a "core driver" for Neutron. This means
> >     that the
> >     > main API implementation is done inside this driver. The ML2 driver
> is
> >     > modular, and can load sub-drivers (mechanism and type drivers) to
> >     > implement the specific actions such as creating virtual ethernet
> >     ports.
> >     >
> >     > Contrail replaces this driver with the NeutronPluginContrailCoreV2,
> >     > which implements the main API itself, without subdrivers. There is
> no
> >     > support planned for ML2 mechanism or type drivers within the
> Contrail
> >     > plugin. Contrail implements its own intelligent virtual ethernet
> >     ports,
> >     > each of which is routing-aware, and the routing is made redundant
> >     using
> >     > dynamic multipath routing. This replaces the Open vSwitch
> >     > bridge/patch/port mechanism.
> >     >
> >     > The current documentation [1] for Contrail/RDO covers Packstack.
> The
> >     > initial installation is done with ML2+OVS, then the Neutron
> >     > configuration is modified to load the Contrail driver instead.
> >     >
> >     > In OSP-Director 8, it is possible to load the Contrail driver
> during
> >     > installation instead of ML2. This is done by including the
> >     environment
> >     > file:
> >     >
> >     > openstack overcloud deploy --templates /path/to/templates \
> >     > -e /path/to/templates/environments/neutron-opencontrail.yaml \
> >     > [...]
> >     >
> >     > This environment file will set the following:
> >     >
> >     > ###########
> >     > resource_registry:
> >     >   OS::TripleO::ControllerExtraConfigPre:
> >     >
> ../puppet/extraconfig/pre_deploy/controller/neutron-opencontrail.yaml
> >     >   OS::TripleO::ComputeExtraConfigPre:
> >     > ../puppet/extraconfig/pre_deploy/compute/neutron-opencontrail.yaml
> >     >
> >     > parameter_defaults:
> >     >   NeutronCorePlugin:
> >     >
> >
>  neutron_plugin_contrail.plugins.opencontrail.contrail_plugin.NeutronPluginContrailCoreV2
> >     >   NeutronServicePlugins:
> >     >
> >
>  neutron_plugin_contrail.plugins.opencontrail.loadbalancer.plugin.LoadBalancerPlugin
> >     >   NeutronEnableDHCPAgent: false
> >     >   NeutronEnableL3Agent: false
> >     >   NeutronEnableMetadataAgent: false
> >     >   NeutronEnableOVSAgent: false
> >     >   NeutronEnableTunnelling: false
> >     > ############
> >     >
> >     > The files in the resource_registry section contain configuration
> >     > settings such as the IP address of the Contrail API server, and the
> >     > authentication credentials.
> >     >
> >     > In the parameter_defaults section, the NeutronCorePlugin is changed
> >     > from ML2 to the Contrail core plugin. The loadbalancer plugin is
> also
> >     > relegated to the Contrail load balancer plugin.
> >     >
> >     > [1] -
> >     http://www.opencontrail.org/rdo-openstack-opencontrail-integration/
> >     >
> >     > The same kind of approach applies to some other 3rd-party Neutron
> >     > plugin providers, although there are also some that use ML2 and
> >     do the
> >     > customization at the mechanism and type driver layer. Does that
> >     answer
> >     > your questions?
> >     >
> >
> >     I probably should have used TripleO in the above example to reduce
> >     confusion (OSP-Director is Red Hat's name for the supported version
> of
> >     TripleO, which uses the same source code).
> >
> >     In any case, it was just an example of how Contrail completely
> replaces
> >     ML2 when you install it in any OpenStack deployment.
> >
> >     --
> >     Dan Sneddon         |  Principal OpenStack Engineer
> >     dsneddon at redhat.com <javascript:;> <mailto:dsneddon at redhat.com
> <javascript:;>> |
> >     redhat.com/openstack <http://redhat.com/openstack>
> >     650.254.4025 <tel:650.254.4025>        |  dsneddon:irc   @dxs:twitter
> >
> >     _______________________________________________
> >     OpenStack-operators mailing list
> >     OpenStack-operators at lists.openstack.org <javascript:;>
> >     <mailto:OpenStack-operators at lists.openstack.org <javascript:;>>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
>
> Yes, there is a core Neutron plugin, and a separate plugin which
> handles LBaaS. The Contrail load balancer plugin adds L7 load
> balancing, so you can use the content of the request to determine the
> server handling the request. More info here [1].
>
> Contrail have a unique solution that I find very interesting and
> compelling. I don't have any opinion on whether it works better than
> any other Neutron plugin, because that depends on which plugin meets
> your specific needs.
>
> [1] - http://www.opencontrail.org/load-balancer-as-a-service-in-contrail/
>
> --
> Dan Sneddon         |  Principal OpenStack Engineer
> dsneddon at redhat.com <javascript:;> |  redhat.com/openstack
> 650.254.4025        |  dsneddon:irc   @dxs:twitter
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org <javascript:;>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160401/98394724/attachment.html>