Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

2016-04-01 Thread Dan Sneddon 
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  > 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@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?
> >
> 
> I probably should have used TripleO in the above example to reduce
> confusion

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

2016-04-01 Thread Adam Lawson 
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  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@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?
> >
>
> 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
> dsned...@redhat.com |  redhat.com/openstack
> 650.254.4025|  dsneddon:irc   @dxs:twitter
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

2016-04-01 Thread Dan Sneddon 
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@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?
> 

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
dsned...@redhat.com |  redhat.com/openstack
650.254.4025|  dsneddon:irc   @dxs:twitter

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [neutron][ml2] Gutting ML2 from Neutron - possible?

2016-04-01 Thread Dan Sneddon 
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@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
dsned...@redhat.com |  redhat.com/openstack
650.254.4025|  dsneddon:irc   @dxs:twitter

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] OpenStack Developer Mailing List Digest March 26 – April 1

2016-04-01 Thread Mike Perez 
HTML version: 
http://www.openstack.org/blog/2016/04/openstack-developer-mailing-list-digest-20160401/

SuccessBot Says
===
* Tonyb: Dims fixed the Routes 2.3 API break :) 
* pabelanger: migration from devstack-trusty to ubuntu-trusty complete! 
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes


Voting for the Technical Committee Election Is Now Open
===
* We are selecting 7 TC members.
* Confirmed candidates [1]
* You are eligible to vote if you are a Foundation individual member [2] that
  also committed to one of the official projects [3] during the Liberty and
  Mitaka development.
* Important dates:
  - Election open: 2015-04-01 00:00 UTC
  - Election close: 2015-04-07 23:59 UTC
* More details on the election [4]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/091103.html


Release Process Changes For Official Projects
=
* The release team worked on automation for tagging and documenting [5]
  focusing on the projects with the release:managed tag.
* Second phase is to expand to all projects.
* The release team will be updating gerrit ACLs for projects to ensure they can
  handle releases and branching.
* Instead of tagging releases and then recording them in the release
  repository, all official teams can use the release repo to request new
  releases.
* If you're not familiar with the release process, review the README file in
  the openstack/releases repo [6].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090737.html


Service Catalog TNG Work in Mitaka … Next Steps
===
* Mitaka included fact finding
* public / admin / internal url
  - Notion of an internal url is used in many deployments because there is
a belief it means there is no change for data transfer.
  - Some deployments make these all the same and use the network to ensure that
internal connections hit internal interfaces.
  - Next steps:
+ We need a set of user stories built from what we currently have.
* project_id optional in projects – good progress
  - project_id is hard coded into many urls for projects without any useful
reason.
  - Nova demonstrated removing this in micro version 2.18.
  - A patch  [7] is up for devstack to enable this.
  - Next steps:
+ Get other projects to remove project_id from their urls.
* Service types authority
  - We agreed we needed a place to recognize service types [8].
  - The assumption that there might be a single URL which describes an API for
a service is not an assumption we fulfill even for most services.
  - This bump led to [9] some shifted effort on API reference to RST work.
  - Next steps:
+ Finish API documentation conversion work.
+ Review patches for service type authority repo [10].
* Service catalog TNG Schema
  - We have some early work setting up a schema based on the known knowns, and
leaving some holes for the known unknowns until we get a few of these
locked down (types / allowed urls).
  - Next steps:
+ Review current schema.
* Weekly Meetings
  - The team has been meeting weekly in #openstack-meeting-cp until release
crunch and people got swamped.
  - The meeting will be on hiatus for now until after Austin summit, and then
start back up after the week of getting back.
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090754.html


Oh Swagger, Where Art Thou?
===
* Previously it has been communicated of the move from WADL to Swagger for API
  reference information.
* It has been discovered that Swagger doesn't match all of our current API
  designs.
* There is a compute server reference documentation patch [11] using Sphinx,
  RST to do a near copy of the API reference page.
  - There is consensus with Nova-API team, API working group and others to go
forward with this.
* We can still find uses for Swagger for some projects that match the
  specification really well.
* Swagger for example doesn't support 
  - Showing the changes between micro versions.
  - Projects that have /actions resource allow multiple differing request
bodies.
* A new plan is coming, but for now the API reference and WADL files will
  remain in the api-site repository.
* There will be a specification and presentation in the upstream contributor's
  track about Swagger as a standard [12].
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090659.html


Cross-Project Summit Session Proposals Due
==
* When: April 2nd
* Where: etherpad [13]
* Full thread: 
http://lists.openstack.org/pipermail/openstack-dev/2016-March/091078.html


The Plan For the Final Week of the Mitaka Release
=
* We are approaching