OpenStack - User contributions [en]

GroupBasedPolicy/InstallDevstack

2015-05-26T22:53:43Z

Ivar Lazzaro: /* Configuring and testing External Connectivity */

== Installing and Running GBP ==
The following are a set of instructions for installing and working with GBP:

=== Devstack Installation ===
0. Install Ubuntu 14.04

1. git clone http://github.com/group-policy/devstack -b kilo-gbp

or for stable/juno use:
git clone http://github.com/group-policy/devstack -b stable/juno-gbp

2. cd devstack

3. ./stack.sh

4. source openrc demo demo

5. Use the "gbp" CLI binary ("gbp --help" will give you the commands)

== GBP Basic CLI and Workflow ==
Example scenario: Modeling connectivity between Web and App Tiers using GBP:

# Create allow action that can used in several rules
gbp policy-action-create allow --action-type allow

# Create ICMP rule
gbp policy-classifier-create icmp-traffic --protocol icmp --direction bi
gbp policy-rule-create ping-policy-rule --classifier icmp-traffic --actions allow

# Create SSH Rule (Optional)
# gbp policy-classifier-create ssh-traffic --protocol tcp --port-range 22 --direction bi
# gbp policy-rule-create ssh-policy-rule --classifier ssh-traffic --actions allow

# Create HTTP Rule
gbp policy-classifier-create web-traffic --protocol tcp --port-range 80 --direction in
gbp policy-rule-create web-policy-rule --classifier web-traffic --actions allow

# Create HTTPs Rule
gbp policy-classifier-create secure-web-traffic --protocol tcp --port-range 443 --direction in
gbp policy-rule-create secure-web-policy-rule --classifier secure-web-traffic --actions allow

# ICMP policy-rule-set
gbp policy-rule-set-create icmp-policy-rule-set --policy-rules ping-policy-rule

# WEB policy-rule-set
gbp policy-rule-set-create web-policy-rule-set --policy-rules web-policy-rule

# Policy Target Group (PTG) creation
gbp group-create web
gbp group-create client-1
gbp group-create client-2

# Policy Target creation and launching VMs
WEB1=$(gbp policy-target-create web-ep-1 --policy-target-group web | awk "/port_id/ {print \$4}")
CLIENT1=$(gbp policy-target-create client-ep-1 --policy-target-group client-1 | awk "/port_id/ {print \$4}")
CLIENT2=$(gbp policy-target-create client-ep-2 --policy-target-group client-2 | awk "/port_id/ {print \$4}")

nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$WEB1 web-vm-1
nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$CLIENT1 client-vm-1
nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$CLIENT2 client-vm-2

####CHECKPOINT: No traffic flows

# policy-rule-set Association
gbp group-update client-1 --consumed-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"
gbp group-update client-2 --consumed-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"
gbp group-update web --provided-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"

####CHECKPOINT: ICMP and HTTP work from app to web and vice versa

gbp policy-rule-set-update web-policy-rule-set --policy-rules "secure-web-policy-rule"

####CHECKPOINT: HTTP stops working for both the client PTGs, HTTPs is now enabled

== Configuring and testing External Connectivity ==
Implicit workflow for RMD.

# ADMIN: create default external segment based on the name configured in "default_external_segment_name"
# NOTE: in Juno, the RMD requires the Neutron external subnet to pre-exist.

gbp external-segment-create default --subnet_id $EXT_SUB_ID --external-route destination=0.0.0.0/0,nexthop= --shared True

# USER (any tenant): create PTG with the normal workflow

gbp group-create group-with-external-access

# Create external PTG (called External Policy)

gbp external-policy-create [name]

# Provide and Consumes PRS on normal PTGs and EPs

gbp group-update group-with-external-access --consumed-policy-rule-sets "web-policy-rule-set=true"
gbp external-policy-update [name] --provided_policy_rule_sets "web-policy-rule-set=true"

###HTTP traffic is now enabled towards the external world

Explicit Workflow (old non-external workflow still assumed implicit here):

# ADMIN: create non-default external segment for a given tenant (or shared)
# NOTE: in Juno, the RMD requires the Neutron external subnet to pre-exist.

EXT_SEG_ID=$(gbp external-segment-create [not-default-name] --subnet_id $EXT_SUB_ID --external-route destination=0.0.0.0/0,nexthop= --shared True | awk "/ id / {print \$4}")

# USER: create PTG with the normal workflow

gbp group-create group-with-external-access

# Link the implicitly created L3P to the external segment

gbp l3policy-update [l3-policy-id] --external-segment $EXT_SEG_ID=

# Create external PTG (called External Policy) linked to the External Segment

gbp external-policy-create [name] --external-segments $EXT_SEG_ID

# Provide and Consumes PRS on normal PTGs and EPs

gbp group-update group-with-external-access --consumed-policy-rule-sets "web-policy-rule-set=true"
gbp external-policy-update [name] --provided_policy_rule_sets "web-policy-rule-set=true"

###HTTP traffic is now enabled towards the external world

GroupBasedPolicy

2015-03-26T18:12:38Z

Ivar Lazzaro:

** GBP Juno Release is now available, see below for details **
== Overview ==
* The Group-based Policy (GBP) abstractions for OpenStack provide a intent-driven declarative policy model that presents simplified application-oriented interfaces to the user.

==== Launchpad Project ====
* https://launchpad.net/group-based-policy
* Join [https://launchpad.net/~group-based-policy-contributors group-based-policy-contributors] for notifications on blueprints, bugs, and questions.

== Documents ==
* [https://docs.google.com/a/noironetworks.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g1c910cf8b_038 The Group-based Policy Model]
* [https://wiki.openstack.org/w/images/a/aa/Group-BasedPolicyWhitePaper_v3.pdf White Paper]
* [https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/edit#heading=h.hyj8vcqqd6ib A represenative Use Case]
* [https://docs.google.com/a/noironetworks.com/document/d/134P7TJdiIfjPWbmstSTY4vp9E6oRYTFs64ON3thFxhI/edit?usp=sharing Group-based Policy to Classical Neutron Mapping]
* [https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin ODL GBP]
* [https://wiki.openstack.org/wiki/Neutron/GroupPolicy/PolicyDrivers OpenDaylight/Vendor Drivers]
* Presentations
** [https://www.youtube.com/watch?v=7p5I6mnOCts Paris Summit Conference Talk (video)]
** [https://www.youtube.com/watch?v=a3Ur1IDyALA Paris Summit (video)]

== Try Group-based Policy ==
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallDevstack Instructions] for installing and running GBP with devstack
* [https://openstack.redhat.com/Neutron_GBP Instructions] for installing and running GBP with [https://openstack.redhat.com/Main_Page RDO] (currently on Fedora 20)
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallUbuntu Instructions] for installing and running with GBP packages on Ubunutu 14.04
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallODLIntegrationDevstack Instructions] for installing and running GBP/ODL integration, with devstack
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallCiscoACI Instructions] for installing and running GBP with Cisco ACI
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallNuage Instructions] for installing and running GBP with Nuage VSP
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallOneConvergence Instructions] for installing and running GBP with One Convergence NVSD Controller

== GBP Juno Release ==

* [https://launchpad.net/group-based-policy/juno/2014.2 Package and Release Notes]

== How to Participate ==
==== Development ====
* This work is currently being pursued in StackForge and Neutron
* [https://etherpad.openstack.org/p/kilo-gbp-plan Current Kilo priorities]
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/Testing Testing]

===== StackForge =====
* Development in in StackForge spans multiple repositories, please click [https://wiki.openstack.org/wiki/GroupBasedPolicy/StackForge/repos this link] for more details.

===== Neutron =====
* Please click [https://wiki.openstack.org/wiki/GroupBasedPolicy/Neutron this link] for more details

===== Open Issues =====
* [https://bugs.launchpad.net/openstack/+bugs?field.searchtext=group_policy&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= All open Group Policy bugs across the projects, pick one and start hacking!]

==== Meetings ====
* [https://wiki.openstack.org/wiki/Meetings/GroupBasedPolicy Weekly IRC meetings]

==== IRC channel ====
* #openstack-gbp

==== Mailing List discussions ====
* Send emails to the OpenStack Development Mailing List <openstack-dev@lists.openstack.org>. Please use [Policy][Group-based-policy] in the subject line of your email when possible.

== GBP Cross Project Liaisons ==

* Keystone - Rukhsana Ansari (ransari)
* Nova - Robert Kukura (rkukura)
* Oslo - Robert Kukura (rkukura)

== Project Stats and Elections ==

* [http://stackalytics.com/?project_type=stackforge&module=group-based-policy-group&metric=commits&release=all Stackalytics]
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/PTL_Elections_Kilo_Liberty GBP PTL Elections]

== Team Activities ==
* Vancouver Summit Accepted Talks
** [https://openstacksummitmay2015vancouver.sched.org/event/fe712eb5f27186ffd64ed787244af4f3 Group Based Policy Hands-on Lab]
* Vancouver Summit Proposed Talks
** [https://www.openstack.org/vote-vancouver/presentation/panel-defining-policy-frameworks-for-openstack Panel: Defining Policy Frameworks for OpenStack]
** [http://www.openstack.org/vote-vancouver/presentation/meta-data-driven-cloud-running-openstack-scale-using-a-policy-framework-intel Meta-data Driven Cloud – Running OpenStack @ Scale Using a Policy Framework (Intel)]
** [https://www.openstack.org/vote-vancouver/presentation/group-based-policy-hands-on-lab Group Based Policy Hands-on Lab]
** [https://www.openstack.org/vote-vancouver/presentation/integrating-openstack-group-based-policy-with-opendaylight-group-based-policy Integrating OpenDayLight with OpenStack via Group-based Policy]
* [https://wiki.openstack.org/wiki/GroupBasedPolicy/kilo-bug-squash Kilo Bug Squash Day]
* [http://kilodesignsummit.sched.org/event/98dc4255384e340682137c8a7ee7e60d#.VEcllIt4r4x Kilo, Paris, Design Summit Session]
* [https://openstacksummitnovember2014paris.sched.org/event/3381db355f042c612c11960a588e31de Kilo, Paris, Conference Talk]
* [http://opennetworkingusergroup.com/group-based-policy-using-intent-to-manage-infrastructure/ ONUG]
* [https://wiki.openstack.org/wiki/Neutron/GroupPolicy/JunoCodeSprint Juno Code Sprint]
* [https://drive.google.com/file/d/0BzXAWQLtAkavWnpUU1pwWFBCRTA/edit Atlanta Summit Talk]

GroupBasedPolicy/ReleaseNotes/Juno

2015-01-06T23:00:15Z

Ivar Lazzaro:

== Juno Release Notes ==

This is the first OpenStack Group Based Policy release. The release comprises of our components/repositories (Service, Client, Heat automation, Horizon UI) and is designed to work
with OpenStack stable Juno. This release includes policy drivers for policy rendering using Neutron (with ML2 plugin and OVS driver), or OpenDaylight Controller. In addition, vendor-specifc policy drviers are for Cisco ACI, Nuage Virtual Services' Platform and One Convergence Network Virtualization and Service Delivery (NVSD) Controller.

When using the Neutron Resource Mapping driver in this release:
* Overlapping IP addresses are supported across tenants but not within the same tenant
* Policy Target Group association for Policy Target is immutable
* L2 Policy association for Policy Target Group is immutable
* L3 Policy association for L2 Policy is immutable
* ip_pool for L3 Policy is immutable
* Policy Rule Sets cannot be shared
* External Policy cannot be shared
* L2 Policy can't be associated to a different tenant's L3 Policy even if shared
* Policy Target Group can't be associated to a different tenant's L2 Policy even if shared

GroupBasedPolicy/InstallDevstack

2014-12-12T02:37:32Z

Ivar Lazzaro:

== Installing and Running GBP ==
The following are a set of instructions for installing and working with GBP:

=== Devstack Installation ===
0. Install Ubuntu 14.04

1. git clone http://github.com/group-policy/devstack -b juno-gbp-3

2. cd devstack

3. ./stack.sh

4. source openrc demo demo

5. Use the "gbp" CLI binary ("gbp --help" will give you the commands)

== GBP Basic CLI and Workflow ==
Example scenario: Modeling connectivity between Web and App Tiers using GBP:

# Create allow action that can used in several rules
gbp policy-action-create allow --action-type allow

# Create ICMP rule
gbp policy-classifier-create icmp-traffic --protocol icmp --direction bi
gbp policy-rule-create ping-policy-rule --classifier icmp-traffic --actions allow

# Create SSH Rule (Optional)
# gbp policy-classifier-create ssh-traffic --protocol tcp --port-range 22 --direction bi
# gbp policy-rule-create ssh-policy-rule --classifier ssh-traffic --actions allow

# Create HTTP Rule
gbp policy-classifier-create web-traffic --protocol tcp --port-range 80 --direction in
gbp policy-rule-create web-policy-rule --classifier web-traffic --actions allow

# Create HTTPs Rule
gbp policy-classifier-create secure-web-traffic --protocol tcp --port-range 443 --direction in
gbp policy-rule-create secure-web-policy-rule --classifier secure-web-traffic --actions allow

# ICMP policy-rule-set
gbp policy-rule-set-create icmp-policy-rule-set --policy-rules ping-policy-rule

# WEB policy-rule-set
gbp policy-rule-set-create web-policy-rule-set --policy-rules web-policy-rule

# Policy Target Group creation
gbp group-create web
gbp group-create client-1
gbp group-create client-2

# Policy Target ceation and launching VMs
WEB1=$(gbp policy-target-create web-ep-1 --policy-target-group web | awk "/port_id/ {print \$4}")
CLIENT1=$(gbp policy-target-create client-ep-1 --policy-target-group client-1 | awk "/port_id/ {print \$4}")
CLIENT2=$(gbp policy-target-create client-ep-2 --policy-target-group client-2 | awk "/port_id/ {print \$4}")

nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$WEB1 web-vm-1
nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$CLIENT1 client-vm-1
nova boot --flavor m1.nano --image cirros-0.3.2-x86_64-uec --nic port-id=$CLIENT2 client-vm-2

####CHECKPOINT: No traffic flows

# policy-rule-set Association
gbp group-update client-1 --consumed-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"
gbp group-update client-2 --consumed-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"
gbp group-update web --provided-policy-rule-sets "icmp-policy-rule-set=true,web-policy-rule-set=true"

####CHECKPOINT: ICMP and HTTP work from app to web and vice versa

gbp policy-rule-set-update web-policy-rule-set --policy-rules "secure-web-policy-rule"

####CHECKPOINT: HTTP stops working for both the client EPGs, HTTPs is now enabled

== Configuring and testing External Connecitiviy ==
Implicit workflow for RMD (high level constructs, CLI is not defined yet).

# ADMIN: create default external segment based on the name configured in "default_external_segment_name"
# NOTE: in Juno, the RMD requires the Neutron external subnet to pre-exist.

POST /grouppolicy/external_segments {"external_segment": {"name": <default-name>, "subnet_id":<neutron-external-subnet-id>, external_routes: [{"destination": "0.0.0.0/0", "nexthop":null }], "shared":true}}

# USER (any tenant): create PTG with the normal workflow

gbp group-create group-with-external-access

# Create external PTG (called External Policy)

POST /grouppolicy/external_policies {"external_policy": {"name": <choose-your-name>}}

# Provide and Consumes PRS on normal PTGs and EPs

gbp group-update group-with-external-access --consumed-policy-rule-sets "web-policy-rule-set=true"
PUT /grouppolicy/external_policies {"external_policy": {"provided_policy_target_groups": {<web-policy-rule-set-id>: <scope>}}}

###HTTP traffic is now enabled towards the external world

Explicit Workflow (old non-external workflow still assumed implicit here):

# ADMIN: create non-default external segment for a given tenant (or shared)
# NOTE: in Juno, the RMD requires the Neutron external subnet to pre-exist.

POST /grouppolicy/external_segments {"external_segment": {"name": <name>, "subnet_id":<neutron-external-subnet-id>, external_routes: [{"destination": "0.0.0.0/0", "nexthop":null }], "shared":true}}

# USER: create PTG with the normal workflow

gbp group-create group-with-external-access

# Link the implicitly created L3P to the external segment

PUT /grouppolicy/l3_policy {"l3_policy": {"external_segments": {<es_id>: [<list_of_ips_or_none>]}}}

# Create external PTG (called External Policy) linked to the External Segment

POST /grouppolicy/external_policies {"external_policy": {"name": <choose-your-name>}, "external_segments": [<es_id>]}

# Provide and Consumes PRS on normal PTGs and EPs

gbp group-update group-with-external-access --consumed-policy-rule-sets "web-policy-rule-set=true"
PUT /grouppolicy/external_policies {"external_policy": {"provided_policy_target_groups": {<web-policy-rule-set-id>: <scope>}}}

###HTTP traffic is now enabled towards the external world

Neutron/AdvancedServices/JunoPlan

2014-05-31T06:44:35Z

Ivar Lazzaro: /* Reviewers */

== Reviewers ==

Please add your name if you would like to be on the "assigned reviewers" team for Advanced Services:

Ryan Moats (regXboi), Louis F (LouisF), Marios Andreou (marios), Bob Kukura (rkukura), Ivar Lazzaro (ivar-lazzaro)

== Tasks ==

{| class="wikitable"
|-
! Task !! Gerrit Link !! Status !! Milestone !! Owner
|-
! Topic: Framework
|-
| Blueprint || https://review.openstack.org/#/c/92200 || Approved || Juno || Sumit
|-
! Topic: Neutron Flavor Framework
|-
| Blueprint || https://review.openstack.org/#/c/90070 || Pending || Not set || Eugene
|-
| Neutron || Pending || Pending || Not set || Eugene
|-
| CLI/Client || Pending || Pending || Not set || Eugene
|-
| Tempest || Pending || Pending || Not set || Eugene
|-
| Horizon || Pending || Pending || Not set || Eugene
|-
| Heat || Pending || Pending || Not set || Eugene
|-
| Documentation || Pending || Pending || Not set || Eugene
|-
! Topic: Service Insertion
|-
| Blueprint || https://review.openstack.org/#/c/93128 || Pending || J1 || Kanzhe
|-
| Neutron || Pending || Pending || J1 and J2 || Kanzhe
|-
| CLI/Client || Pending || Pending || J1 and J2 || Kanzhe
|-
| Tempest || Pending || Pending || J2 || Kanzhe
|-
| Horizon || Pending || Pending || J2 || Kanzhe
|-
| Heat || Pending || Pending || Not set || Kanzhe
|-
| Documentation || Pending || Pending || J2 || Kanzhe
|-
! Topic: Traffic Steering
|-
| Blueprint || https://review.openstack.org/#/c/92477 || Pending || J1 || Carlos
|-
| Neutron || Pending || Pending || J2 || Carlos
|-
| CLI/Client || Pending || Pending || J2 || Carlos
|-
| DevStack || Pending || Pending || J2 || Carlos
|-
| Tempest || Pending || Pending || Not set || Carlos
|-
| Horizon || Pending || Pending || Not set || Carlos
|-
| Heat || Pending || Pending || Not set || Carlos
|-
| Documentation || Pending || Pending || Not set || Carlos
|-
! Topic: Service Chaining
|-
| Blueprint || https://review.openstack.org/#/c/93524 || Pending || Not set || Mandeep
|-
| Neutron || Pending || Pending || Not set || Mandeep
|-
| CLI/Client || Pending || Pending || Not set || Mandeep
|-
| Tempest || Pending || Pending || Not set || Mandeep
|-
| Horizon || Pending || Pending || Not set || Mandeep
|-
| Heat || Pending || Pending || Not set || Mandeep
|-
| Documentation || Pending || Pending || Not set || Mandeep
|-
! Topic: L3 Agent consolidation
|-
| Blueprint || https://review.openstack.org/#/c/91532 || Pending || Not set || Toshihiro
|-
| Neutron || Pending || Pending || Not set || Toshihiro
|-
| CLI/Client || NA || NA || NA || NA
|-
| Tempest || Pending || Pending || Not set || Toshihiro
|-
| Horizon || NA || NA || NA || NA
|-
| Heat || NA || NA || NA || NA
|-
| Documentation || Pending || Pending || Not set || Toshihiro
|-
|}

Neutron

2014-02-15T01:52:32Z

Ivar Lazzaro:

= OpenStack Networking ("Neutron") =

{| border="1" cellpadding="2" cellspacing="0"
| [http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html Administrator Guide ]
|-
| [http://docs.openstack.org/user-guide/content/neutron_client_sample_commands.html Neutron CLI Guide ]
|-
| [http://docs.openstack.org/api/openstack-network/2.0/content/ API Developer Doc (v2) ]
|-
| [https://github.com/openstack/quantum Source code ]
|-
| [https://bugs.launchpad.net/quantum Bug tracker ]
|-
| [https://blueprints.launchpad.net/quantum Blueprints ]
|}

== Related projects ==
* [https://launchpad.net/python-quantumclient Python Neutron client]
* Neutron Admin and API documentation in [https://launchpad.net/openstack-manuals OpenStack Manuals]
* Tempest testing project [http://docs.openstack.org/developer/tempest/ Tempest Manuals]. For the Icehouse cycle, the community is undertaking a focused effort to strengthen the suite of Tempest tests for Neutron. If you are interested on contributing to this effort, please go to [https://etherpad.openstack.org/p/icehouse-summit-qa-neutron Icehouse Neutron Tempest push] to see what is being done and to [https://wiki.openstack.org/wiki/Neutron/TempestAPITests TempestAPITests] for HOWTO instructions. Helping to develop Tempest tests (particularly API tests) is an excellent way for new contributors to learn Neutron.

== What is Neutron? ==

Neutron is an [https://wiki.openstack.org OpenStack] project to provide "networking as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).

Starting in the Folsom release, Neutron is a core and supported part of the [https://wiki.openstack.org OpenStack] platform (for Essex, we were an "incubated" project, which means use is suggested only for those who really know what they're doing with Neutron).

If you're a networking geek and like to hack on [https://wiki.openstack.org OpenStack], please join!

More Info:
* [http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612 Overview of Neutron] (slides) (3/12)
* [https://www.youtube.com/watch?v=_I1SrO2QBpg Neutron Project Overview + Update from Grizzly Summit] (video) (10/12)
* [http://www.infoq.com/presentations/Quantum-Virtual-Networks-for-OpenStack Video Neutron Overview] (3/12)
* [http://sdrv.ms/YdnQYS Slides on Technical Architecture of Neutron] (2013-03-14)

== Why Neutron? ==

* Give cloud tenants an API to build rich networking topologies, and configure advanced network policies in the cloud.
** Example: create multi-tier web application topology
* Enable innovation plugins (open and closed source) that introduce advanced network capabilities
** Example: use L2-in-L3 tunneling to avoid VLAN limits, provide end-to-end QoS guarantees, used monitoring protocols like [[NetFlow]].
* Let anyone build advanced network services (open and closed source) that plug into Openstack tenant networks.
** Examples: LB-aaS, VPN-aaS, firewall-aaS, IDS-aaS, data-center-interconnect-aaS.
* Horizon GUI support for:
** Neutron L2 and L3 network and subnet creation/deletion
** Booting VMs on specific Neutron networks.
* API Extensibility Framework, including extensions for:
** "provider network", which maps Neutron L2 networks to a specific VLAN in the physical data center

== Using Neutron ==

Follow the instructions in the [http://docs.openstack.org/admin-guide-cloud/content/ch_networking.html Neutron Administrator Guide], or use the installation documentation at http://docs.openstack.org to use Neutron with OpenStack Nova.

Forget documentation, I just want to get the code!: [https://launchpad.net/quantum/+download Neutron Downloads]

Detailed information for programming against v2.0 of the Neutron web services API is available in the [http://docs.openstack.org/api/openstack-network/2.0/content/ Neutron API Guide]

If you are looking for information on using Neutron with devstack, please see: [[NeutronDevstack]] .

Neutron lets you use a set of different backends called "plugins" that work with a growing variety of networking technologies. These plugins may be distributed as part of the main Neutron release, or separately.

The set of plugins included in the main Neutron distribution and supported by the Neutron community include:

* [http://www.openvswitch.org Open vSwitch] Plugin
* [http://wiki.openstack.org/cisco-quantum Cisco UCS/Nexus] Plugin
* [http://wiki.openstack.org/Quantum-Linux-Bridge-Plugin Linux Bridge] Plugin
* [http://wiki.openstack.org/Neutron/ML2 Modular Layer 2] Plugin
* [http://www.nicira.com Nicira Network Virtualization Platform (NVP)] Plugin
* [http://www.osrg.net/ryu/using_with_openstack.html Ryu OpenFlow Controller] Plugin
* [[Neutron/NEC OpenFlow Plugin|NEC OpenFlow]] Plugin
* [http://docs.projectfloodlight.org/display/floodlightcontroller/Quantum+REST+Proxy+Plugin Big Switch Controller Plugin]
* [http://www.cloudbase.it/quantum-hyper-v-plugin/ Cloudbase Hyper-V] Plugin
* [http://www.midokura.com MidoNet] Plugin
* [https://github.com/brocade/brocade Brocade Neutron Plugin] Brocade Neutron Plugin
* [http://www.plumgrid.com/ PLUMgrid] Plugin
* [https://wiki.openstack.org/wiki/Mellanox-Neutron Mellanox Neutron Plugin] Mellanox Neutron Plugin
* [https://wiki.openstack.org/wiki/Neutron/EmbraneNeutronPlugin Embrane Neutron Plugin]

Additional plugins are available from other sources:
* [http://www.opencontrail.org OpenContrail] Plugin
* [http://www.extremenetworks.com Extreme Networks] Plugin
* [https://github.com/ruijie/rgos_quantum_plugin Ruijie Networks] Plugin
* [https://www.juniper.net/support/downloads/?p=qpluginopen#sw Juniper Networks] Neutron Plugin
If you have your own plugin, feel free to add it to this list.

== Havana Release and ML2 Plugin Update ==
Starting with Havana release, openvswitch and linuxbridge plugins are deprecated. Modular Layer 2 (ML2) plugin replaces these plugins.
L2 agents work with ML2 plugin and continue to work with the deprecated monolithic plugins.

ML2 plugin architecture facilitates the type drivers to support multiple networking technologies, and mechanism drivers to facilitate the access to the networking configuration in a transactional model. The details of these drivers is described [https://wiki.openstack.org/wiki/Neutron/ML2#ML2_Drivers here]. Long term goal is to transition all vendor specific plugins to the type and mechanism drivers.

Following [https://wiki.openstack.org/wiki/Neutron/ML2#Type_Drivers Type Drivers] are supported:
* Flat
* Local
* VLAN
* GRE
* VxLan

Following Vendor specific [https://wiki.openstack.org/wiki/Neutron/ML2#Mechanism_Drivers Mechanism Drivers] are supported:
* [https://wiki.openstack.org/wiki/Arista-neutron-ml2-driver Arista Driver]
* [https://wiki.openstack.org/wiki/Neutron/ML2/MechCiscoNexus Cisco Nexus Driver]
* [https://wiki.openstack.org/wiki/Neutron/ML2/Tail-f-NCS-neutron-ml2-driver Tail-f NCS Driver]

== Participate ==

To get code, ask questions, view blueprints, etc, see: [https://launchpad.net/quantum/ Neutron Launchpad Page]

See [[NeutronDevelopment]] for some (rough) guides on how to contribute code to Neutron, including how to add your own plugin.

If you would like to participate, please send mail to the main openstack-dev list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

You can also attend our regular IRC meetings, which start one hour after the main openstack meeting, on the same #openstack-meeting channel: http://wiki.openstack.org/Network/Meetings

Check out [[NeutronStarterBugs]] for ideas on easy bugs or starter projects you might tackle. Or just start playing with [[NeutronDevstack]] and come up with your own ideas!

== Related pages ==
=== Neutron/* ===
{{Special:PrefixIndex/Neutron}}

=== Network/* ===
{{Special:PrefixIndex/Network}}

Neutron Plugins and Drivers

2013-12-02T22:36:11Z

Ivar Lazzaro:

=== Introduction ===
Ensuring release quality through proper testing is an important tenant of the OpenStack community and Neutron team wants to do our part. We are introducing changes below provide more visibility into the quality and stability of vendor plugin and driver code. The policies described here are in effect immediately.

=== Rationale ===
Code proposals for third party plugins have always presented a review challenge for the Neutron core team. In the early days, code was often proposed by core project contributors and our review process only validated whether the requirements were met for community coding style and unit testing. As Neutron has added new resources via extensions, it has become more difficult for Neutron reviewers to ensure the proposed code is functional. Many of the plugins and/or drivers require proprietary hardware and/or software to conduct such testing.

In addition to testing changes, the Neutron team is revising the requirements for the point of contact for third party code. The changes bring the written expectations for contacts in line with current practice.

=== Point of Contact Requirements ===
Each third party plugin and/or driver shall designate a point of contact for each coordinated release cycle. The contact will serve as a liaison between the Neutron core team and the vendor or community supporting the plugin or driver. The contact shall:
- Attend weekly Neutron team IRC meetings
- Be an active reviewer and contributor
- Be an active participant on openstack-dev mailing list
- Assist the core team with triaging bugs specific to the plugin and/or driver
- Ensure OpenStack development deadlines are properly communicated back to their company and/or community

NOTE: The this information can be maintained here: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

=== Testing Requirements ===
To be designated as compatible, a third-party plugin and/or driver code must implement external third party testing. The testing should be Tempest executed against a Devstack build with the proposed code changes. The environment managed by the vendor should be configured to incorporate the plugin and/or driver solution. The OpenStack Infrastructure team has provided details on how to integrate 3rd party testing at:

http://ci.openstack.org/third_party.html

and Tempest can be found at:

https://github.com/openstack/tempest

The Neutron team expects that the third party testing will provide a +/-1 verify vote for all changes to a plugin or driver’s code. In addition, the Neutron team expects that the third party test will also vote on all code submissions by the jenkins user. The jenkins user regularly submits requirements changes and the Neutron team hopes to catch any possible regressions as early as possible.

=== Existing Plugin and Drivers ===
Plugins and drivers currently in the Neutron project repository will be given a grace period until the Icehouse-2 milestone to implement external third party testing. At that time, the Neutron team will release a list of the compatible plugins and drivers (i.e. those that meet the testing requirements). Plugins and drivers that do not have external testing will be deprecated at the Icehouse release and will be candidates for removal when the J-release cycle opens.

{| class="wikitable"
|-
! Plugin/Driver Name !! Contact Name !! IRC Nick
|-
| ML2 || Neutron Team || rkukura
|-
| Big Switch/Floodlight || Sumit Naiksatam || snaiksat
|-
| Arista Networks || Sukhdev Kapur || Sukhdev
|-
| Embrane || Ivar Lazzaro || ivar-lazzaro
|-
| Place Holder || Person 1 Name || irc_nick
|}

Neutron/LBaaS/EmbraneDriver

2013-10-28T20:40:08Z

Ivar Lazzaro:

= Embrane [[Neutron]] LBaaS Driver =

==Scope==

The present blueprint aims at the implementation of a Neutron LBaaS driver which allows users to provision heleos Load Balancers using Neutron LBaaS framework.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to provide load balancing through the Embrane heleos appliances still using the API and workflows they are comfortable with. 

== Implementation==

The new added files are the following:

<pre><nowiki>
neutron/services/loadbalancer/drivers/embrane/__init__.py
neutron/services/loadbalancer/drivers/embrane/agent/__init__.py
neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py
neutron/services/loadbalancer/drivers/embrane/agent/lb_operations.py
neutron/services/loadbalancer/drivers/embrane/config.py
neutron/services/loadbalancer/drivers/embrane/constants.py
neutron/services/loadbalancer/drivers/embrane/db.py
neutron/services/loadbalancer/drivers/embrane/driver.py
neutron/services/loadbalancer/drivers/embrane/models.py
neutron/services/loadbalancer/drivers/embrane/poller.py
</nowiki></pre>

=== The Provisioning ===

While using the Embrane Neutron LBaaS driver, any operation which doesn't involve an active VIP model object will be simply managed and written in the DB, without changing the current network state.
Whenever a VIP is associated to a pool, the heleos platform will create a Load Balancer appliance, taking care of establishing connectivity between it and the pool members, and configuring all the requested parameters.

=== Using existing plugins for L2 connectivity ===
The Embrane LBaaS driver and the core L2 plugin share information about the network implementation, which will be used by heleos to provide connectivity between the Load Balancer appliance and the existing pool members.
This can be done in 2 ways:

'''Using [[Neutron/EmbraneNeutronPlugin|Embrane's L3 Neutron Plugin]]''' 

This will automatically share the information with the Embrane's LBaaS driver, without any need for further configuration.

'''Plugin Support''' 

When the driver is used over any other core plugin implementation, the user shall configure "l2_support" from /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini
An L2 support is a module which, given a core plugin, returns all the information about the specific network implementation (e.g. VLAN id).
A list of the available supports can be found in neutron/plugins/embrane/l2_base 
At the time this wiki page was written, the support includes:

*'''neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport'''

'''-Instructions to build a new L2 plugin Support-'''

see examples from:

<pre><nowiki>
neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport
</nowiki></pre>

To build a new L2 support for the Embrane's Neutron plugin, you must first implement the specific l2base. 

Create a new package under:

<pre><nowiki>
neutron.plugins.embrane.l2base
</nowiki></pre>

And name it with the specific plugin technology. Create a python module, and a class which extends support_base.SupportBase, implementing all its abstract methods.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

Once the contract is fulfilled configure /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini as follows:
<pre><nowiki>
[heleoslb]
l2_support=neutron.plugins.embrane.l2_base.new_vendor.new_module.NewClass
</nowiki></pre>

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane LBaaS driver will be executed asynchronously and by a different thread "per VIP".
This means that each request will be sent to the dispatcher (' neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py') which will serve each Load Balancer using a different thread,
in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style).
Moreover, the LB models state attributes are used to tell the user when a lb is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the vip and the related models
in a 'PENDING_*' state. Subsequent GET operations will eventually reflect the current status of the virtual appliance itself.

=== State Synchronization ===

To keep consistency between the heleos state and the Neutron state, a poller has been defined within:
<pre><nowiki>
neutron/services/loadbalancer/drivers/embrane/poller.py
</nowiki></pre>

The poller has a configurable polling interval (default: 60 sec, 0 for no polling) and will make sure that the states between the two "worlds" are consistent
(some times fixing issues, some times just setting the actual state within the Neutron Model).

This approach has been preferred instead of the "sync on GET" to avoid long waiting times on multiple GET operations.

==Configuration==

The configuration file is stored in '/etc/neutron/services/loadbalancer/embrane/heleos-conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''esm_mgmt''': management address of the ESM, the Embrane heleos module that is installed separately and which will actually provision the load balancers inside the cloud environment;
*'''admin_username''': admin username for authenticating against the ESM api;
*'''admin_password''': admin password for authenticating against the ESM api;
*'''lb_image''': ID of the heleos load balancer image stored inside the ESM;
*'''*_id''': a series of product specific resources that can be specified inside the plugin, or alternatively, from the product itself.
*'''l2_support''': mandatory when the core plugin is NOT Embrane's, is the path to the plugin support as explained in the sections above.
*'''sync_interval''': defines the polling interval for state synchronization, defaults to 60 seconds, set to 0 or less if no polling is required.

 etc/neutron/neutron.conf example: 
<pre><nowiki>
[DEFAULT]
...
service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin
...
[service_providers]
...
service_provider=LOADBALANCER:Embrane:neutron.services.loadbalancer.drivers.embrane.driver.EmbraneLbaas:default
...
</nowiki></pre>
 

NOTE: Any mandatory parameter which is not overridden by this configuration file will be red from the existing Embrane's L3 plugin configuration files (if any).

Neutron/LBaaS/EmbraneDriver

2013-10-28T20:38:42Z

Ivar Lazzaro: This page covers Embrane's LBaaS Driver description and its implementation details.

= Embrane [[Neutron]] LBaaS Driver =

==Scope==

The present blueprint aims at the implementation of a Neutron LBaaS driver which allows users to provision heleos Load Balancers using Neutron LBaaS framework.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to provide load balancing through the Embrane heleos appliances still using the API and workflows they are comfortable with. 

== Implementation==

The new added files are the following:

<pre><nowiki>
neutron/services/loadbalancer/drivers/embrane/__init__.py
neutron/services/loadbalancer/drivers/embrane/agent/__init__.py
neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py
neutron/services/loadbalancer/drivers/embrane/agent/lb_operations.py
neutron/services/loadbalancer/drivers/embrane/config.py
neutron/services/loadbalancer/drivers/embrane/constants.py
neutron/services/loadbalancer/drivers/embrane/db.py
neutron/services/loadbalancer/drivers/embrane/driver.py
neutron/services/loadbalancer/drivers/embrane/models.py
neutron/services/loadbalancer/drivers/embrane/poller.py
</nowiki></pre>

=== The Provisioning ===

While using the Embrane Neutron LBaaS driver, any operation which doesn't involve an active VIP model object will be simply managed and written in the DB, without changing the current network state.
Whenever a VIP is associated to a pool, the heleos platform will create a Load Balancer appliance, taking care of establishing connectivity between it and the pool members, and configuring all the requested parameters.

=== Using existing plugins for L2 connectivity ===
The Embrane LBaaS driver and the core L2 plugin share information about the network implementation, which will be used by heleos to provide connectivity between the Load Balancer appliance and the existing pool members.
This can be done in 2 ways:

'''Using [[Neutron/EmbraneNeutronPlugin|Embrane's L3 Neutron Plugin]]''' 

This will automatically share the information with the Embrane's LBaaS driver, without any need for further configuration.

'''Plugin Support''' 

When the driver is used over any other core plugin implementation, the user shall configure "l2_support" from /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini
An L2 support is a module which, given a core plugin, returns all the information about the specific network implementation (e.g. VLAN id).
A list of the available supports can be found in neutron/plugins/embrane/l2_base 
At the time this wiki page was written, the support includes:

*'''neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport'''

'''-Instructions to build a new L2 plugin Support-'''

see examples from:

<pre><nowiki>
neutron.plugins.embrane.l2_base.openvswitch.openvswitch_support.OpenvswitchSupport
</nowiki></pre>

To build a new L2 support for the Embrane's Neutron plugin, you must first implement the specific l2base. 

Create a new package under:

<pre><nowiki>
neutron.plugins.embrane.l2base
</nowiki></pre>

And name it with the specific plugin technology. Create a python module, and a class which extends support_base.SupportBase, implementing all its abstract methods.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

Once the contract is fulfilled configure /etc/neutron/services/loadbalancer/embrane/heleos-conf.ini as follows:
<pre><nowiki>
[heleoslb]
l2_support=neutron.plugins.embrane.l2_base.new_vendor.new_module.NewClass
</nowiki></pre>

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane LBaaS driver will be executed asynchronously and by a different thread "per VIP".
This means that each request will be sent to the dispatcher (' neutron/services/loadbalancer/drivers/embrane/agent/dispatcher.py') which will serve each Load Balancer using a different thread,
in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style).
Moreover, the LB models state attributes are used to tell the user when a lb is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the vip and the related models
in a 'PENDING_*' state. Subsequent GET operations will eventually reflect the current status of the virtual appliance itself.

=== State Synchronization ===

To keep consistency between the heleos state and the Neutron state, a poller has been defined within:
<pre><nowiki>
neutron/services/loadbalancer/drivers/embrane/poller.py
</nowiki></pre>

The poller has a configurable polling interval (default: 60 sec, 0 for no polling) and will make sure that the states between the two "worlds" are consistent
(some times fixing issues, some times just setting the actual state within the Neutron Model).

This approach has been preferred instead of the "sync on GET" to avoid long waiting times on multiple GET operations.

==Configuration==

The configuration file is stored in '/etc/neutron/services/loadbalancer/embrane/heleos-conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''esm_mgmt''': management address of the ESM, the Embrane heleos module that is installed separately and which will actually provision the routers inside the cloud environment;
*'''admin_username''': admin username for authenticating against the ESM api;
*'''admin_password''': admin password for authenticating against the ESM api;
*'''lb_image''': ID of the router image stored inside the ESM, which will be used to create the routers;
*'''*_id''': a series of product specific resources that can be specified inside the plugin, or alternatively, from the product itself.
*'''l2_support''': mandatory when the core plugin is NOT Embrane's, is the path to the plugin support as explained in the sections above.
*'''sync_interval''': defines the polling interval for state synchronization, defaults to 60 seconds, set to 0 or less if no polling is required.

 etc/neutron/neutron.conf example: 
<pre><nowiki>
[DEFAULT]
...
service_plugins = neutron.services.loadbalancer.plugin.LoadBalancerPlugin
...
[service_providers]
...
service_provider=LOADBALANCER:Embrane:neutron.services.loadbalancer.drivers.embrane.driver.EmbraneLbaas:default
...
</nowiki></pre>
 

NOTE: Any mandatory parameter which is not overridden by this configuration file will be red from the existing Embrane's L3 plugin configuration files (if any).

Neutron/EmbraneNeutronPlugin

2013-08-30T20:32:27Z

Ivar Lazzaro:

= Embrane [[Neutron]] Plugin =

==Scope==

The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos platform.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to use Embrane's heleos platform with the API and workflows set they are comfortable with. 

Using the Embrane's plugin, the users can achieve any level of L2 isolation using the existing plugins (when supported), while leveraging L3 connectivity through Embrane's provisioning system, which can rapidly provide per tenant "core routers" in a pool of dedicated/shared physical hosts. These routers are configurable through both Neutron itself or their own REST APIs.

== Network Overview==
[TBD]

== Implementation==

This session discusses the plugin implementation, with special focus to the plugin specific features and configurations. 

The plugin file list is the following:

<pre><nowiki>
neutron/plugins/embrane/EmbraneInit.py
neutron/plugins/embrane/__init__.py
neutron/plugins/embrane/agent/__init__.py
neutron/plugins/embrane/agent/dispatcher.py
neutron/plugins/embrane/agent/operations/__init__.py
neutron/plugins/embrane/agent/operations/routerOperations.py
neutron/plugins/embrane/l2base/__init__.py
neutron/plugins/embrane/l2base/openvswitch/__init__.py
neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py
neutron/plugins/embrane/l2base/support_base.py
neutron/plugins/embrane/l2base/support_exceptions.py
neutron/plugins/embrane/plugin.py
</nowiki></pre>

Additionally, more packages are defined:

<pre><nowiki>
neutron/plugins/embrane/api/*
neutron/plugins/embrane/embranerest/*
</nowiki></pre>

The files inside these packages are backend-specific, and represent the set of tools used to interact with the Embrane's platform. They are a dependency for the plugin and may be distributed separately at first.

===Supported feature===
The plugin supports the following features:

*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_router.html Router];
*[http://docs.openstack.org/api/openstack-network/2.0/content/extraroute-ext.html ExtraRoute];
*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_floatingip.html FloatingIp].

=== Using existing plugins for L2 connectivity ===
The Embrane Neutron Plugin main goal is of course to interface OpenStack (specifically Neutron) with heleos, which provides L3-7 network services for cloud environments.
For this reason, the Embrane Plugin lends the leveraging of L2 connectivity to an existing Plugin chosen at configuration time.
The Embrane Plugin and the L2 plugin share information about the network implementation, which will be used to implement L3.
So any time a request is sent to Neutron, it will be directed to the Embrane Plugin if is part of the API set showed in the previous section, to the L2 plugin otherwise.

To achieve this, there are 2 main techniques that have been used:

'''Plugin Inheritance''' 

In 'neutron/plugins/embrane/plugins/*' (where the actual plugins resides) each plugin class (i.e. EmbraneOvsPlugin) is created using the base Embrane plugin (neutron/plugins/embrane/plugin.py.EmbranePlugin) and the specific L2 plugin as bases. This will ensure, provided that everything is done correctly, that the L2 networks will be provided by an existing L2 plugin, while L3 connectivity will be managed by Embrane's plugin. More details on how to create a specific Embrane plugin are provided below.

'''Plugin-in-Plugin''' 

In order to get all this to work, the 2 plugins (Embrane's and L2) need to share some information about the actual network implementation. At the present state, only plugins which implement network isolation through VLANs can be used together with Embrane's plugin. Support for different L2 isolation will be added in the future.
This "information sharing" is implemented through a plugin "inside the plugin", which means that for each L2 plugin that is to be supported, it's mandatory to create a new package inside 'neutron/plugins/embrane/l2base/' and a class that inherits from 'neutron/plugins/embrane/l2base/support_base.py'.
This abstract class only defines one simple method, which shall be implemented by the support class in order to fulfill the contract.

'''-Instructions to build a new Embrane plugin from a different base-'''

see examples from:

<pre><nowiki>
neutron.plugins.embrane.plugins.embrane_fake_plugin.EmbraneFakePlugin
neutron.plugins.embrane.plugins.embrane_ovs_plugin.EmbraneOvsPlugin
</nowiki></pre>

To build a new L2 support for the Embrane's Neutron plugin, you must first implement the specific l2base. 

Create a new package under:

<pre><nowiki>
neutron.plugins.embrane.l2base
</nowiki></pre>

And name it with the specific plugin technology. Create a python module, and a class which extends support_base.SupportBase, implementing all its abstract methods.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

An example of support class can be found in 'neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py'. 

Once the contract is fulfilled (see examples and comments in the code for more info) create a new module under:

<pre><nowiki>
neutron.plugins.embrane.plugins
</nowiki></pre>

Named referencing the specific plugin technology (see existing examples). Inside the module define a class built as follows:
of the plugin following the example below:

<pre><nowiki>
class EmbraneNewPlugin(base.EmbranePlugin, l2.NewL2Plugin):
_plugin_support = support.NewPluginSupport
def __init__(self):
'''First run plugin specific initialization, then Embrane's.'''
self.supported_extension_aliases += ["extraroute", "router"] #IF NEEDED
l2.NewL2Plugin.__init__(self)
self._run_embrane_config()
</nowiki></pre>

NOTE: The base order is very important!!! EmbranePlugin shall always be the first base of the built plugin, so the L3 requests can be correctly resolved (MRO) 
NOTE2: The plugin needs certain bases and extensions: 
*REQUIRED_EXTENSIONS = ["extraroute", "router"]
*REQUIRED_BASES = (ExtraRoute_db_mixin,)
Add them if needed (i.e. the L2 plugin doesn't natively support them).

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane Plugin will be executed asynchronously and by a different thread "per Router". This means that each request will be sent to the dispatcher ('neutron/plugins/embrane/agent/dispatcher.py') which will serve each Router using a different thread, in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style). Moreover, Router state attribute is used to tell the user when a Router is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the router in a 'PENDING_*' state. Subsequent GETs shall always reflect the current status of the virtual appliance itself.
When a Router is in a given state, only a subset of operations can be executed on it.

==Configuration==

The configuration file is stored in 'etc/neutron/plugins/embrane/heleos_conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''esm_mgmt''': management address of the ESM, the Embrane module that is installed separately and which will actually provision the routers inside the cloud environent;
*'''admin_username''': admin username for authenticating against the ESM;
*'''admin_password''': admin password for authenticating against the ESM;
*'''router_image''': ID to the router image stored inside the ESM, which will be used to create the routers;
*'''*_id''': a series of resources product specific that can be specified inside the plugin, or alternatively, from the product itself.

etc/neutron/neutron.conf example: 
*'''core_plugin =''' neutron.plugins.embrane.plugins.embrane_ovs_plugin.EmbraneOvsPlugin

Neutron/EmbraneNeutronPlugin

2013-08-02T23:49:13Z

Ivar Lazzaro: /* Implementation */

= Embrane [[Neutron]] Plugin =

==Scope==

The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos platform.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to use Embrane's heleos platform with the API and workflows set they are comfortable with. 

Using the Embrane's plugin, the users can achieve any level of L2 isolation using the existing plugins (when supported), while leveraging L3 connectivity through Embrane's provisioning system, which can rapidly provide per tenant "core routers" in a pool of dedicated/shared physical hosts. These routers are configurable through both Neutron itself or their own REST APIs.

== Network Overview==
[TBD]

== Implementation==

This session discusses the plugin implementation, with special focus to the plugin specific features and configurations. 

The plugin file list is the following:

<pre><nowiki>
neutron/plugins/embrane/EmbraneInit.py
neutron/plugins/embrane/__init__.py
neutron/plugins/embrane/agent/__init__.py
neutron/plugins/embrane/agent/dispatcher.py
neutron/plugins/embrane/agent/operations/__init__.py
neutron/plugins/embrane/agent/operations/routerOperations.py
neutron/plugins/embrane/l2base/__init__.py
neutron/plugins/embrane/l2base/openvswitch/__init__.py
neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py
neutron/plugins/embrane/l2base/support_base.py
neutron/plugins/embrane/l2base/support_exceptions.py
neutron/plugins/embrane/plugin.py
</nowiki></pre>

Additionally, more packages are defined:

<pre><nowiki>
neutron/plugins/embrane/api/*
neutron/plugins/embrane/embranerest/*
</nowiki></pre>

The files inside these packages are backend-specific, and represent the set of tools used to interact with the Embrane's platform. They are a dependency for the plugin and may be distributed separately at first.

===Supported feature===
The plugin supports the following features:

*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_router.html Router];
*[http://docs.openstack.org/api/openstack-network/2.0/content/extraroute-ext.html ExtraRoute];
*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_floatingip.html FloatingIp].

=== Using existing plugins for L2 connectivity ===
The Embrane Neutron Plugin main goal is of course to interface OpenStack (specifically Neutron) with heleos, which provides L3-7 network services for cloud environments.
For this reason, the Embrane Plugin lends the leveraging of L2 connectivity to an existing Plugin chosen at configuration time.
The Embrane Plugin and the L2 plugin share information about the network implementation, which will be used to implement L3.
So any time a request is sent to Neutron, it will be directed to the Embrane Plugin if is part of the API set showed in the previous section, to the L2 plugin otherwise.

To achieve this, there are 2 main techniques that have been used:

'''Plugin Inheritance''' 

In 'neutron/plugins/embrane/plugin.py' (plugin main module) the main class 'EmbranePlugin' is created at runtime starting from class '__EmbranePlugin'. This is done looking at the configuration file, assuring that the specified L2 plugin is a valid one, and creating a new class which attribute and methods (in general, the full dict) coincides with '__EmbranePlugin', but also inherits from the configured L2 plugin, from which 'EmbranePlugin' will get all the implemented methods overriding everything related with L3 connectivity.
Also, all the necessary inheritances are set unless already present on the base L2 plugin.

'''Plugin-in-Plugin''' 

In order to get all this to work, the 2 plugins (Embrane's and L2) need to share some information about the actual network implementation. At the present state, only plugins which implements network isolation through VLANs can be used together with Embrane's plugin. Support for different L2 isolation will be added in the future.
This "information sharing" is implemented through a "Plugin inside the Plugin", which means that for each L2 plugin that is to be supported, it's mandatory to create a new package inside 'neutron/plugins/embrane/l2base/' and a class that inherits from 'neutron/plugins/embrane/l2base/support_base.py'.
This abstract class only defines one simple method, which shall be implemented by the support class in order to fulfill the contract.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

An example of support class can be found in 'neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py'.

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane Plugin will be executed asynchronously and by a different thread "per Router". This means that each request will be sent to the dispatcher ('neutron/plugins/embrane/agent/dispatcher.py') which will serve each Router using a different thread, in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style). Moreover, Router state attribute is used to tell the user when a Router is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the router in a 'PENDING_*' state. Subsequent GETs shall always reflect the current status of the virtual appliance itself.
When a Router is in a given state, only a subset of operations can be executed on it.

==Configuration==

The configuration file is stored in 'etc/neutron/plugins/embrane/heleos_conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''l2_plugin''': path to one of the existing L2 plugins which will work together with the Embrane's plugin;
*'''l2_support''': path to one of the existing L2 support class (see the section above);
*'''esm_mgmt''': management address of the ESM, the Embrane module that is installed separately and which will actually provision the routers inside the cloud environent;
*'''admin_username''': admin username for authenticating against the ESM;
*'''admin_password''': admin password for authenticating against the ESM;
*'''router_image''': ID to the router image stored inside the ESM, which will be used to create the routers;
*'''*_id''': a series of resources product specific that can be specified inside the plugin, or alternatively, from the product itself.

Neutron/EmbraneNeutronPlugin

2013-08-02T21:35:40Z

Ivar Lazzaro: /* Network Overview */

= Embrane [[Neutron]] Plugin =

==Scope==

The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos platform.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to use Embrane's heleos platform with the API and workflows set they are comfortable with. 

Using the Embrane's plugin, the users can achieve any level of L2 isolation using the existing plugins (when supported), while leveraging L3 connectivity through Embrane's provisioning system, which can rapidly provide per tenant "core routers" in a pool of dedicated/shared physical hosts. These routers are configurable through both Neutron itself or their own REST APIs.

== Network Overview==
[TBD]

== Implementation==

This session discusses the plugin implementation, with special focus to the plugin specific features and configurations. 

The plugin file list is the following:

<pre><nowiki>
neutron/plugins/embrane/EmbraneInit.py
neutron/plugins/embrane/__init__.py
neutron/plugins/embrane/agent/__init__.py
neutron/plugins/embrane/agent/dispatcher.py
neutron/plugins/embrane/agent/operations/__init__.py
neutron/plugins/embrane/agent/operations/routerOperations.py
neutron/plugins/embrane/l2base/__init__.py
neutron/plugins/embrane/l2base/openvswitch/__init__.py
neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py
neutron/plugins/embrane/l2base/support_base.py
neutron/plugins/embrane/l2base/support_exceptions.py
neutron/plugins/embrane/plugin.py
</nowiki></pre>

Additionally, three more packages are defined:

<pre><nowiki>
neutron/plugins/embrane/api/*
neutron/plugins/embrane/common/*
neutron/plugins/embrane/embranerest/*
</nowiki></pre>

The files inside these packages are backend-specific, and represent the set of tools used to interact with the Embrane's platform. They are a dependency for the plugin and may be distributed separately at first.

===Supported feature===
The plugin supports the following features:

*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_router.html Router];
*[http://docs.openstack.org/api/openstack-network/2.0/content/extraroute-ext.html ExtraRoute];
*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_floatingip.html FloatingIp].

=== Using existing plugins for L2 connectivity ===
The Embrane Neutron Plugin main goal is of course to interface OpenStack (specifically Neutron) with heleos, which provides L3-7 network services for cloud environments.
For this reason, the Embrane Plugin lends the leveraging of L2 connectivity to an existing Plugin chosen at configuration time.
The Embrane Plugin and the L2 plugin share information about the network implementation, which will be used to implement L3.
So any time a request is sent to Neutron, it will be directed to the Embrane Plugin if is part of the API set showed in the previous section, to the L2 plugin otherwise.

To achieve this, there are 2 main techniques that have been used:

'''Plugin Inheritance''' 

In 'neutron/plugins/embrane/plugin.py' (plugin main module) the main class 'EmbranePlugin' is created at runtime starting from class '__EmbranePlugin'. This is done looking at the configuration file, assuring that the specified L2 plugin is a valid one, and creating a new class which attribute and methods (in general, the full dict) coincides with '__EmbranePlugin', but also inherits from the configured L2 plugin, from which 'EmbranePlugin' will get all the implemented methods overriding everything related with L3 connectivity.
Also, all the necessary inheritances are set unless already present on the base L2 plugin.

'''Plugin-in-Plugin''' 

In order to get all this to work, the 2 plugins (Embrane's and L2) need to share some information about the actual network implementation. At the present state, only plugins which implements network isolation through VLANs can be used together with Embrane's plugin. Support for different L2 isolation will be added in the future.
This "information sharing" is implemented through a "Plugin inside the Plugin", which means that for each L2 plugin that is to be supported, it's mandatory to create a new package inside 'neutron/plugins/embrane/l2base/' and a class that inherits from 'neutron/plugins/embrane/l2base/support_base.py'.
This abstract class only defines one simple method, which shall be implemented by the support class in order to fulfill the contract.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

An example of support class can be found in 'neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py'.

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane Plugin will be executed asynchronously and by a different thread "per Router". This means that each request will be sent to the dispatcher ('neutron/plugins/embrane/agent/dispatcher.py') which will serve each Router using a different thread, in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style). Moreover, Router state attribute is used to tell the user when a Router is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the router in a 'PENDING_*' state. Subsequent GETs shall always reflect the current status of the virtual appliance itself.
When a Router is in a given state, only a subset of operations can be executed on it.

==Configuration==

The configuration file is stored in 'etc/neutron/plugins/embrane/heleos_conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''l2_plugin''': path to one of the existing L2 plugins which will work together with the Embrane's plugin;
*'''l2_support''': path to one of the existing L2 support class (see the section above);
*'''esm_mgmt''': management address of the ESM, the Embrane module that is installed separately and which will actually provision the routers inside the cloud environent;
*'''admin_username''': admin username for authenticating against the ESM;
*'''admin_password''': admin password for authenticating against the ESM;
*'''router_image''': ID to the router image stored inside the ESM, which will be used to create the routers;
*'''*_id''': a series of resources product specific that can be specified inside the plugin, or alternatively, from the product itself.

Neutron/EmbraneNeutronPlugin

2013-08-02T21:34:34Z

Ivar Lazzaro: Created page with "= Embrane Neutron Plugin = ==Scope== The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos ..."

= Embrane [[Neutron]] Plugin =

==Scope==

The present blueprint aims at the implementation of a Neutron plugins which allows users to interface Neutron with Embrane's heleos platform.

==Use Cases==

Cloud service providers who choose to adopt [[OpenStack]] and [[Neutron]] for their cloud orchestration, will also be able to use Embrane's heleos platform with the API and workflows set they are comfortable with. 

Using the Embrane's plugin, the users can achieve any level of L2 isolation using the existing plugins (when supported), while leveraging L3 connectivity through Embrane's provisioning system, which can rapidly provide per tenant "core routers" in a pool of dedicated/shared physical hosts. These routers are configurable through both Neutron itself or their own REST APIs.

== Network Overview==

In order to work, the Embrane's Plugin requires Embrane's heleos platform to be in place.
The platform controller, called ESM, will use a pool of compute resources (which can be dedicated, or shared with the OpenStack environment) to provision virtual network services (in this specific case, routers).

This means that, for example, every time a tenant requests a Router creation to the plugin, the latter will ask to the ESM to spawn a virtual network service inside the specific hardware pool, and to configure it as a Router.
Then the tenant may ask to attach a Router interface to an existing network; In this case the plugin will gather all the information needed about the specified L2 netwotk, and communicate them to the ESM which will make the structural and configuration changes on the Router accordingly (e.g. If a gateway interface is set in the router, the plugin will both ask to the ESM to place a new interface, and to the Router itself to configure the default gateway inside the specified subnet).

== Implementation==

This session discusses the plugin implementation, with special focus to the plugin specific features and configurations. 

The plugin file list is the following:

<pre><nowiki>
neutron/plugins/embrane/EmbraneInit.py
neutron/plugins/embrane/__init__.py
neutron/plugins/embrane/agent/__init__.py
neutron/plugins/embrane/agent/dispatcher.py
neutron/plugins/embrane/agent/operations/__init__.py
neutron/plugins/embrane/agent/operations/routerOperations.py
neutron/plugins/embrane/l2base/__init__.py
neutron/plugins/embrane/l2base/openvswitch/__init__.py
neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py
neutron/plugins/embrane/l2base/support_base.py
neutron/plugins/embrane/l2base/support_exceptions.py
neutron/plugins/embrane/plugin.py
</nowiki></pre>

Additionally, three more packages are defined:

<pre><nowiki>
neutron/plugins/embrane/api/*
neutron/plugins/embrane/common/*
neutron/plugins/embrane/embranerest/*
</nowiki></pre>

The files inside these packages are backend-specific, and represent the set of tools used to interact with the Embrane's platform. They are a dependency for the plugin and may be distributed separately at first.

===Supported feature===
The plugin supports the following features:

*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_router.html Router];
*[http://docs.openstack.org/api/openstack-network/2.0/content/extraroute-ext.html ExtraRoute];
*[http://docs.openstack.org/api/openstack-network/2.0/content/router_ext_ops_floatingip.html FloatingIp].

=== Using existing plugins for L2 connectivity ===
The Embrane Neutron Plugin main goal is of course to interface OpenStack (specifically Neutron) with heleos, which provides L3-7 network services for cloud environments.
For this reason, the Embrane Plugin lends the leveraging of L2 connectivity to an existing Plugin chosen at configuration time.
The Embrane Plugin and the L2 plugin share information about the network implementation, which will be used to implement L3.
So any time a request is sent to Neutron, it will be directed to the Embrane Plugin if is part of the API set showed in the previous section, to the L2 plugin otherwise.

To achieve this, there are 2 main techniques that have been used:

'''Plugin Inheritance''' 

In 'neutron/plugins/embrane/plugin.py' (plugin main module) the main class 'EmbranePlugin' is created at runtime starting from class '__EmbranePlugin'. This is done looking at the configuration file, assuring that the specified L2 plugin is a valid one, and creating a new class which attribute and methods (in general, the full dict) coincides with '__EmbranePlugin', but also inherits from the configured L2 plugin, from which 'EmbranePlugin' will get all the implemented methods overriding everything related with L3 connectivity.
Also, all the necessary inheritances are set unless already present on the base L2 plugin.

'''Plugin-in-Plugin''' 

In order to get all this to work, the 2 plugins (Embrane's and L2) need to share some information about the actual network implementation. At the present state, only plugins which implements network isolation through VLANs can be used together with Embrane's plugin. Support for different L2 isolation will be added in the future.
This "information sharing" is implemented through a "Plugin inside the Plugin", which means that for each L2 plugin that is to be supported, it's mandatory to create a new package inside 'neutron/plugins/embrane/l2base/' and a class that inherits from 'neutron/plugins/embrane/l2base/support_base.py'.
This abstract class only defines one simple method, which shall be implemented by the support class in order to fulfill the contract.

<pre><nowiki>
@abstractmethod
def retrieve_utif_info(self, context, neutron_port=None, network=None):
</nowiki></pre>

An example of support class can be found in 'neutron/plugins/embrane/l2base/openvswitch/openvswitch_support.py'.

=== Asynchronous Calls===

To avoid too much wait time on long operations, the calls to the Embrane Plugin will be executed asynchronously and by a different thread "per Router". This means that each request will be sent to the dispatcher ('neutron/plugins/embrane/agent/dispatcher.py') which will serve each Router using a different thread, in which all the operations will be queued and executed sequentially, while the available database information on the specific resource will be returned to the user ([[Nova]] style). Moreover, Router state attribute is used to tell the user when a Router is busy with an operation:

'''Table 1. Status Values '''
{| border="1" cellpadding="2" cellspacing="0"
| '''Name'''
|-
| ACTIVE
|-
| PENDING_CREATE
|-
| PENDING_UPDATE
|-
| PENDING_DELETE
|-
| INACTIVE
|-
| ERROR
|}

So when the model is changed (via POST, PUT or DELETE for example) the call may return before the actual operation is executed on the virtual system, putting the router in a 'PENDING_*' state. Subsequent GETs shall always reflect the current status of the virtual appliance itself.
When a Router is in a given state, only a subset of operations can be executed on it.

==Configuration==

The configuration file is stored in 'etc/neutron/plugins/embrane/heleos_conf.ini', this section explains the meaning of each field (example are provided in the configuration class itself).
*'''l2_plugin''': path to one of the existing L2 plugins which will work together with the Embrane's plugin;
*'''l2_support''': path to one of the existing L2 support class (see the section above);
*'''esm_mgmt''': management address of the ESM, the Embrane module that is installed separately and which will actually provision the routers inside the cloud environent;
*'''admin_username''': admin username for authenticating against the ESM;
*'''admin_password''': admin password for authenticating against the ESM;
*'''router_image''': ID to the router image stored inside the ESM, which will be used to create the routers;
*'''*_id''': a series of resources product specific that can be specified inside the plugin, or alternatively, from the product itself.