Open Stack

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
> 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?

-- 
Dan Sneddon         |  Principal OpenStack Engineer
dsneddon at redhat.com |  redhat.com/openstack
650.254.4025        |  dsneddon:irc   @dxs:twitter