OpenStack - User contributions [en]

Tacker

2016-03-18T23:54:22Z

Karthik Natarajan:

__NOTOC__

Tacker is OpenStack project building an Open NFV Orchestrator with in-built general purpose VNF Manager to deploy and operate Virtual Network Functions (VNFs) on an NFV Platform. It is based on ETSI MANO Architectural Framework and provides full functional stack to Orchestrate VNFs end-to-end.

[[File:ETSI_MANO_TackerPhase1.JPG]]

'''IRC Channel:''' <code><nowiki>#tacker</nowiki></code>

'''Meetings:''' Tuesday 1700 UTC [Weekly] @ <code><nowiki>#openstack-meeting-4</nowiki></code>

'''Tags:''' [NFV] [Tacker]<br />

__TOC__

= High Level Functionality =

== VNFM ==

# VNF Catalog
# Basic life-cycle of VNF (define/start/stop/undefine)
# Performance and Health monitoring of deployed VNFs
# Auto Healing VNFs based on Policy
# Facilitate initial configuration of VNF

== NFVO ==

# Templatized end-to-end Network Service deployment using decomposed VNFs
# VNF placement policy – ensure efficient placement of VNFs
# VNFs connected using a SFC - described in a VNF Forwarding Graph Descriptor
# VIM Resource Checks and Resource Allocation
# Ability to orchestrate VNFs across Multiple VIMs

= Installation =

[[ Tacker/Installation ]]

= Documentation =

http://tacker-docs.readthedocs.org/en/latest/index.html

= Use Cases =

=== vCE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs in SP's network to deliver agile network services for remote Customer networks

=== vCPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to manage OpenStack enabled remote CPE devices to deploy VNFs to locally provide network services at customer site.

=== vPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs within SP's network to virtualize existing network services into a Virtual Function.

= TOSCA for NFV =

Tacker uses TOSCA for VNF meda-data definition. Within TOSCA Tacker used NFV profile schema,

* TOSCA NFV Profile:
** Latest spec is available here: https://www.oasis-open.org/committees/document.php?document_id=56577&wg_abbrev=tosca
** Current latest (as of Oct 2015) is: https://www.oasis-open.org/committees/download.php/56577/tosca-nfv-v1.0-wd02-rev03.doc

= Tacker + SFC (Service Function Chaining) =

The proposal to enable SFC for Tacker is captured in these slides,

https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit?usp=sharing

= Meeting Minutes =

http://eavesdrop.openstack.org/meetings/tacker/

= Repos =
{| class="wikitable"
|-
! colspan="2"| Git
|-
| Tacker || http://git.openstack.org/cgit/openstack/tacker/
|-
| Tacker Specs || http://git.openstack.org/cgit/openstack/tacker-specs/
|-
| Tacker Python Client || http://git.openstack.org/cgit/openstack/python-tackerclient/
|-
! colspan="2" | Gerrit
|-
| Tacker || https://review.openstack.org/#/q/status:open+project:openstack/tacker,n,z
|-
| Tacker Specs || https://review.openstack.org/#/q/status:open+project:openstack/tacker-specs,n,z
|-
| Tacker Python client || https://review.openstack.org/#/q/status:open+project:openstack/python-tackerclient,n,z
|-
|}

= Reviews =

[https://review.openstack.org/#/q/project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs+AND+status:open,n,z Tacker Code and Spec Reviews ]

[https://review.openstack.org/#/q/(project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs)+AND+status:open,n,z Tacker Open Code and Spec Reviews]

= Bugs =

https://bugs.launchpad.net/tacker

[https://bugs.launchpad.net/tacker/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search Unassigned Bugs]
= Points of contact =

* Launchpad project page: https://launchpad.net/tacker
* IRC meeting information: https://wiki.openstack.org/wiki/Meetings/Tacker
* IRC channel on Freenode: <code><nowiki>#tacker</nowiki></code>

= Quick Links =

{| class="wikitable"

|-
| Design & Documentation || [[Tacker/Design]]
|-
| Resources || [[Tacker/Resources]]
|-
| Action Items || [[Tacker/ActionItems]]
|-
| Dependencies & Wish List || [[Tacker/Dependencies]]
|-
| Spec/Patch Tracking || [https://wiki.openstack.org/wiki/Tracking_ServiceVM_Reviews Spec & Patch Tracking ]
|-
| Liberty Summit Tacker Talk || [http://sched.co/2qik Sched Link]
|-
| Juno Design Summit || [[Tacker/JunoSummit]]
|-
| Team || [https://wiki.openstack.org/wiki/Tacker/Incubation#Team_Members Team Members ]
|}

= Wiki Pages =
{{Special:PrefixIndex/ServiceVM}}

Tacker

2016-03-18T23:28:20Z

Karthik Natarajan:

__NOTOC__

Tacker is OpenStack project building an Open NFV Orchestrator with in-built general purpose VNF Manager to deploy and operate Virtual Network Functions (VNFs) on an NFV Platform. It is based on ETSI MANO Architectural Framework and provides full functional stack to Orchestrate VNFs end-to-end.
[[File:Tacker multicolor.png|frameless|left]]
[[File:ETSI_MANO_TackerPhase1.JPG]]

'''IRC Channel:''' <code><nowiki>#tacker</nowiki></code>

'''Meetings:''' Tuesday 1700 UTC [Weekly] @ <code><nowiki>#openstack-meeting-4</nowiki></code>

'''Tags:''' [NFV] [Tacker]<br />

__TOC__

= High Level Functionality =

== VNFM ==

# VNF Catalog
# Basic life-cycle of VNF (define/start/stop/undefine)
# Performance and Health monitoring of deployed VNFs
# Auto Healing VNFs based on Policy
# Facilitate initial configuration of VNF

== NFVO ==

# Templatized end-to-end Network Service deployment using decomposed VNFs
# VNF placement policy – ensure efficient placement of VNFs
# VNFs connected using a SFC - described in a VNF Forwarding Graph Descriptor
# VIM Resource Checks and Resource Allocation
# Ability to orchestrate VNFs across Multiple VIMs

= Installation =

[[ Tacker/Installation ]]

= Documentation =

http://tacker-docs.readthedocs.org/en/latest/index.html

= Use Cases =

=== vCE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs in SP's network to deliver agile network services for remote Customer networks

=== vCPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to manage OpenStack enabled remote CPE devices to deploy VNFs to locally provide network services at customer site.

=== vPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs within SP's network to virtualize existing network services into a Virtual Function.

= TOSCA for NFV =

Tacker uses TOSCA for VNF meda-data definition. Within TOSCA Tacker used NFV profile schema,

* TOSCA NFV Profile:
** Latest spec is available here: https://www.oasis-open.org/committees/document.php?document_id=56577&wg_abbrev=tosca
** Current latest (as of Oct 2015) is: https://www.oasis-open.org/committees/download.php/56577/tosca-nfv-v1.0-wd02-rev03.doc

= Tacker + SFC (Service Function Chaining) =

The proposal to enable SFC for Tacker is captured in these slides,

https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit?usp=sharing

= Meeting Minutes =

http://eavesdrop.openstack.org/meetings/tacker/

= Repos =
{| class="wikitable"
|-
! colspan="2"| Git
|-
| Tacker || http://git.openstack.org/cgit/openstack/tacker/
|-
| Tacker Specs || http://git.openstack.org/cgit/openstack/tacker-specs/
|-
| Tacker Python Client || http://git.openstack.org/cgit/openstack/python-tackerclient/
|-
! colspan="2" | Gerrit
|-
| Tacker || https://review.openstack.org/#/q/status:open+project:openstack/tacker,n,z
|-
| Tacker Specs || https://review.openstack.org/#/q/status:open+project:openstack/tacker-specs,n,z
|-
| Tacker Python client || https://review.openstack.org/#/q/status:open+project:openstack/python-tackerclient,n,z
|-
|}

= Reviews =

[https://review.openstack.org/#/q/project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs+AND+status:open,n,z Tacker Code and Spec Reviews ]

[https://review.openstack.org/#/q/(project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs)+AND+status:open,n,z Tacker Open Code and Spec Reviews]

= Bugs =

https://bugs.launchpad.net/tacker

[https://bugs.launchpad.net/tacker/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search Unassigned Bugs]
= Points of contact =

* Launchpad project page: https://launchpad.net/tacker
* IRC meeting information: https://wiki.openstack.org/wiki/Meetings/Tacker
* IRC channel on Freenode: <code><nowiki>#tacker</nowiki></code>

= Quick Links =

{| class="wikitable"

|-
| Design & Documentation || [[Tacker/Design]]
|-
| Resources || [[Tacker/Resources]]
|-
| Action Items || [[Tacker/ActionItems]]
|-
| Dependencies & Wish List || [[Tacker/Dependencies]]
|-
| Spec/Patch Tracking || [https://wiki.openstack.org/wiki/Tracking_ServiceVM_Reviews Spec & Patch Tracking ]
|-
| Liberty Summit Tacker Talk || [http://sched.co/2qik Sched Link]
|-
| Juno Design Summit || [[Tacker/JunoSummit]]
|-
| Team || [https://wiki.openstack.org/wiki/Tacker/Incubation#Team_Members Team Members ]
|}

= Wiki Pages =
{{Special:PrefixIndex/ServiceVM}}

Tacker

2016-03-18T23:27:46Z

Karthik Natarajan:

__NOTOC__

Tacker is OpenStack project building an Open NFV Orchestrator with in-built general purpose VNF Manager to deploy and operate Virtual Network Functions (VNFs) on an NFV Platform. It is based on ETSI MANO Architectural Framework and provides full functional stack to Orchestrate VNFs end-to-end.
[[File:Tacker multicolor.png|frameless|right]]
[[File:ETSI_MANO_TackerPhase1.JPG]]

'''IRC Channel:''' <code><nowiki>#tacker</nowiki></code>

'''Meetings:''' Tuesday 1700 UTC [Weekly] @ <code><nowiki>#openstack-meeting-4</nowiki></code>

'''Tags:''' [NFV] [Tacker]<br />

__TOC__

= High Level Functionality =

== VNFM ==

# VNF Catalog
# Basic life-cycle of VNF (define/start/stop/undefine)
# Performance and Health monitoring of deployed VNFs
# Auto Healing VNFs based on Policy
# Facilitate initial configuration of VNF

== NFVO ==

# Templatized end-to-end Network Service deployment using decomposed VNFs
# VNF placement policy – ensure efficient placement of VNFs
# VNFs connected using a SFC - described in a VNF Forwarding Graph Descriptor
# VIM Resource Checks and Resource Allocation
# Ability to orchestrate VNFs across Multiple VIMs

= Installation =

[[ Tacker/Installation ]]

= Documentation =

http://tacker-docs.readthedocs.org/en/latest/index.html

= Use Cases =

=== vCE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs in SP's network to deliver agile network services for remote Customer networks

=== vCPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to manage OpenStack enabled remote CPE devices to deploy VNFs to locally provide network services at customer site.

=== vPE ===

Tacker API can be used by SP's OSS / BSS or a NFV Orchestrator to deploy VNFs within SP's network to virtualize existing network services into a Virtual Function.

= TOSCA for NFV =

Tacker uses TOSCA for VNF meda-data definition. Within TOSCA Tacker used NFV profile schema,

* TOSCA NFV Profile:
** Latest spec is available here: https://www.oasis-open.org/committees/document.php?document_id=56577&wg_abbrev=tosca
** Current latest (as of Oct 2015) is: https://www.oasis-open.org/committees/download.php/56577/tosca-nfv-v1.0-wd02-rev03.doc

= Tacker + SFC (Service Function Chaining) =

The proposal to enable SFC for Tacker is captured in these slides,

https://docs.google.com/presentation/d/18AGaiysVgHOd_fIHVpObMO7zUkMjJGOQ98CUwkxU1xo/edit?usp=sharing

= Meeting Minutes =

http://eavesdrop.openstack.org/meetings/tacker/

= Repos =
{| class="wikitable"
|-
! colspan="2"| Git
|-
| Tacker || http://git.openstack.org/cgit/openstack/tacker/
|-
| Tacker Specs || http://git.openstack.org/cgit/openstack/tacker-specs/
|-
| Tacker Python Client || http://git.openstack.org/cgit/openstack/python-tackerclient/
|-
! colspan="2" | Gerrit
|-
| Tacker || https://review.openstack.org/#/q/status:open+project:openstack/tacker,n,z
|-
| Tacker Specs || https://review.openstack.org/#/q/status:open+project:openstack/tacker-specs,n,z
|-
| Tacker Python client || https://review.openstack.org/#/q/status:open+project:openstack/python-tackerclient,n,z
|-
|}

= Reviews =

[https://review.openstack.org/#/q/project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs+AND+status:open,n,z Tacker Code and Spec Reviews ]

[https://review.openstack.org/#/q/(project:openstack/tacker+OR+project:openstack/python-tackerclient+OR+project:openstack/tacker-horizon+OR+project:openstack/tacker-specs)+AND+status:open,n,z Tacker Open Code and Spec Reviews]

= Bugs =

https://bugs.launchpad.net/tacker

[https://bugs.launchpad.net/tacker/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&search=Search Unassigned Bugs]
= Points of contact =

* Launchpad project page: https://launchpad.net/tacker
* IRC meeting information: https://wiki.openstack.org/wiki/Meetings/Tacker
* IRC channel on Freenode: <code><nowiki>#tacker</nowiki></code>

= Quick Links =

{| class="wikitable"

|-
| Design & Documentation || [[Tacker/Design]]
|-
| Resources || [[Tacker/Resources]]
|-
| Action Items || [[Tacker/ActionItems]]
|-
| Dependencies & Wish List || [[Tacker/Dependencies]]
|-
| Spec/Patch Tracking || [https://wiki.openstack.org/wiki/Tracking_ServiceVM_Reviews Spec & Patch Tracking ]
|-
| Liberty Summit Tacker Talk || [http://sched.co/2qik Sched Link]
|-
| Juno Design Summit || [[Tacker/JunoSummit]]
|-
| Team || [https://wiki.openstack.org/wiki/Tacker/Incubation#Team_Members Team Members ]
|}

= Wiki Pages =
{{Special:PrefixIndex/ServiceVM}}

File:Tacker multicolor.png

2016-03-18T23:21:36Z

Karthik Natarajan:

ReleaseNotes/Kilo

2015-04-20T23:46:23Z

Karthik Natarajan: /* Key New Features */

{| style="color:#000000; border:solid 1px #A8A8A8; padding:0.5em; margin:0.5em 0; background-color:#FFFFFF;font-size:95%; vertical-align:middle;"
| style="padding:1em;width: 40px" | [[Image:Warning.svg|40px]]
| '''Release Under Development'''
This release of OpenStack is under development and has yet to be completed. It will be released on April 30, 2015

The information on this page may not accurately reflect the state of release at the current point in time.
|}

= OpenStack 2015.1 (Kilo) Release Notes =

<div style="column-count:3;-moz-column-count:3;-webkit-column-count:3">
__TOC__
</div>

== General Upgrade Notes ==

* TBD

== OpenStack Object Storage (Swift) ==

=== Key New Features ===

=== Known Issues ===
None

=== Upgrade Notes ===

== OpenStack Compute (Nova) ==

=== Key New Features ===

==== Upgrade Support ====

* Change https://review.openstack.org/#/c/97946/ adds database migration 267 which scans for null instances.uuid records and will fail if any are found since the migrate ultimately needs to make instances.uuid non-nullable and adds a UniqueConstraint on that column. A helper script is provided to search for null instances.uuid records before running the database migrations. Before running 'nova-manage db sync', run the helper script 'nova-manage db null_instance_uuid_scan' which, by default, will just search and dump results, it does not change anything. Pass the --delete option to the null_instance_uuid_scan command to automatically remove any null records were instances.uuid is null.

==== Cells v2 ====
* TBD
* new 'nova-manage api_db sync' and 'nova-manage api_db version' commands for working with the new api database for cells.

==== Compute Drivers ====

===== Hyper-V =====

* TBD

===== Libvirt (KVM) =====

* TBD

===== VMware =====

* TBD

===== XenServer =====

* TBD

===== Ironic =====

* Add config drive support ( https://review.openstack.org/#/c/144792/ )

==== API ====

* TBD

==== Scheduler ====

* TBD

==== Other Features ====

* TBD

=== Known Issues ===

* Evacuate recovery code has the potential to destroy data. On nova-compute startup, instances reported by the hypervisor are examined to see if they have moved (i.e. been evacuated) from the current host during the outage. If the determination is made that they were, then they are destroyed locally. This has the potential to choose incorrectly and destroy instances unexpectedly. On libvirt-like nodes, this can be triggered by changing the system hostname. On vmware-like nodes, this can be triggered by attempting to manage a single vcenter deployment from two different hosts (with different hostnames). This will be fixed properly in Liberty, but for now deployments that wish to disable this behavior as a preventive measure can set workarounds.destroy_after_evacuate=False.

=== Upgrade Notes ===

* After fully upgrading to kilo (i.e. all nodes are running kilo code), you should start a background migration of flavor information from its old home to its new home. Kilo conductor nodes will do this on the fly when necessary, but the rest of the idle data needs to be migrated in the the background. This is critical to complete before the Liberty release, where support for the old location will be dropped. Use "nova-manage migrate-flavor-data" to perform this transition.

== OpenStack Image Service (Glance) ==
=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Dashboard (Horizon) ==

=== Key New Features ===
* TBD

=== Known Issues ===

=== Upgrade Notes ===

== OpenStack Identity (Keystone) ==

=== Key New Features ===

* TBD

=== Known Issues ===

* TBD

=== Upgrade Notes ===

* XML support in Keystone has been removed as of Kilo. When upgrading from Juno to Kilo, it is recommended that references to XML and XmlBodyMiddleware be removed from the [https://github.com/openstack/keystone/blob/master/etc/keystone-paste.ini Keystone Paste configuration]. This includes removing the XML middleware filters and there references from the public_api, admin_api, api_v3, public_version_api, admin_version_api and any other pipelines that may contain the XML filters.

== OpenStack Network Service (Neutron) ==
=== Key New Features ===
* New Plugins supported in Kilo include the following:
** Brocade ML2 driver for MLX and ICX switches
** Brocade L3 routing plugin for MLX switch
** Brocade Vyatta vRouter L3 Plugin
** Brocade Vyatta vRouter Firewall Driver
** Brocade Vyatta vRouter VPN Driver

=== Known Issues ===
None yet.

=== Upgrade Notes ===

From Havana, Neutron no longer supported an explicit lease database (https://bugs.launchpad.net/bugs/1202392). This left dead code including unused environment variable. In order to remove the dead code (https://review.openstack.org/#/c/152398/), a change to the dhcp.filter is required, so that line:

'''dnsmasq: EnvFilter, dnsmasq, root, NEUTRON_NETWORK_ID='''

Be replaced by:

'''dnsmasq: CommandFilter, dnsmasq, root'''

After advanced services were split into separate packages and received their own service configuration files (specifically, etc/neutron/neutron_lbaas.conf, etc/neutron/neutron_fwaas.conf and etc/neutron/neutron_vpnaas.conf), active service provider configuration can be different after upgrade (specifically, default load balancer (haproxy) and vpn (openswan) providers can be enabled for you even though you previously disabled them in neutron.conf). Please make sure you review configuration after upgrade so that it reflects the desired state of service providers.

Note: this will have no effect if the related service plugin is not loaded in neutron.conf.

* The default value of api_workers is now equal to the number of CPUs in the host. If you currently use the default, ensure you set api_workers to a reasonable number for your installation. (https://review.openstack.org/#/c/140493/)
* The neutron.allow_duplicate_networks config option is deprecated in Kilo and will be removed in Liberty where the default behavior will be to just allow multiple ports attached to an instance on the same network in Neutron. (https://review.openstack.org/163581)
* The linuxbridge agent now enables VXLAN by default (https://review.openstack.org/160826)
* neutron-ns-metadata-proxy can now be run as non-root (https://review.openstack.org/147437)

== OpenStack Block Storage (Cinder) ==
=== Key New Features ===
* From this point forward any new database schema upgrades will not require restarting Cinder services right away. The services are now independent of schema upgrades. This is part one to Cinder supporting rolling upgrades!
* Ability to add/remove volumes from an existing consistency group. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Ability to create a consistency group from an existing consistency group snapshot. [http://docs.openstack.org/admin-guide-cloud/content/consistency-groups.html Read docs for more info].
* Create more fine tuned filters/weighers to set how the scheduler will choose a volume backend. [http://docs.openstack.org/admin-guide-cloud/content/driver_filter_weighing.html Read the docs for more info].
* Encrypted volumes can now be backed up using the Cinder backup service. [http://docs.openstack.org/admin-guide-cloud/content/volume-backup-restore.html Read the docs for more info].
* Ability to create private volume types. This is perfect when you want to make volume types available to only a specific tenant or to test it before making available to your cloud. To do so use the ''cinder type-create <name> --is-public''.
* Ability to add descriptions to volume types. To do so use ''cinder type-create <name> <description>
* Cinder now can return multiple iSCSI paths information so that the connector can attach volumes even when the primary path is down ([https://review.openstack.org/#/c/134681/ when connector's multipath feature is enabled] or [https://review.openstack.org/#/c/140877/ not enabled]).

=== Known Issues ===
None yet

=== Upgrade Notes ===
* The 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis. If you use this option, please ensure your configuration files are updated.

== OpenStack Telemetry (Ceilometer) ==
=== Key New Features ===
* Support to add jitter to polling cycles to ensure pollsters are not querying service's api at the same time
* Ceilometer API RBAC support
* Improved Event support:
** Multi-pipeline support to enable unique processing and publishing of events
** Enabled ability to capture raw notification messages for auditing and postmortem analysis
** Support for persisting events into ElasticSearch
** Publishing support to database, http, file, kafa and oslo.messaging supported message queues
** Option to split off the events persistence into a separate database
** Telemetry now supports to collect and store all the event type meters as events. A new option, ''disable_non_metric_meters'', was added to the configuration in order to provide the possibility to turn off storing these events as samples. For further information please see the [http://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-telemetry.html Telemetry Configuration Reference]
** The Administrator Guide in OpenStack Manuals was updated with a new [http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-events.html Events section], where you can find further information about this functionality.
* Improved pipeline publishing support:
** Support to publish events and samples to Kafka or HTTP targets
** Publish data to multiple queues
* Additional meters
** memory and disk meters for Hyper-V
** disk meters for LibVirt
** power and thermal related IPMI meters, more meters from NodeManager
** ability to meter Ceph
* IPv6 support enabled in Ceilometer udp publisher and collector
* [http://launchpad.net/gnocchi Gnocchi] dispatch support for ceilometer-collector
* Self-disabled pollster mechanism

=== Known Issues ===
* TBD

=== Upgrade Notes ===
* Deprecated meters:
** The instance:<flavor> meter is deprecated in the Kilo release. In order to retrieve samples or statistics based on flavor you can use the following queries:
statistics:
ceilometer statistics -m instance -g resource_metadata.instance_type

samples:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
* Middleware used to meter Swift was previously packaged in Ceilometer and is now deprecated. It is now separated into it's own library: ceilometermiddleware.
** Juno configuration: http://docs.openstack.org/juno/install-guide/install/apt/content/ceilometer-swift.html
** Kilo configuration: http://docs.openstack.org/kilo/install-guide/install/apt/content/ceilometer-swift.html

== OpenStack Orchestration (Heat) ==

WIP (will move here) https://etherpad.openstack.org/p/heat-kilo-releasenotes

=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Database service (Trove) ==
=== Key New Features ===

=== Known Issues ===
None yet

=== Upgrade Notes ===
None yet

== OpenStack Data Processing service (Sahara) ==
=== Key New Features ===
TBD

=== Known Issues ===
TBD

=== Upgrade Notes ===
TBD

== OpenStack Documentation ==

=== Key New Features ===

* TBD

=== Known Issues ===

=== Upgrade Notes ===
None yet

TelcoWorkingGroup

2014-10-28T00:38:23Z

Karthik Natarajan: /* Who we are */

= What is NFV? =

NFV stands for Network Functions Virtualization. It defines the replacement of usually stand alone appliances used for high and low level network functions, such as firewalls, network address translation, intrusion detection, caching, gateways, accelerators, etc, into virtual instance or set of virtual instances, which are called Virtual Network Functions (VNF). In other words, it could be seen as replacing some of the hardware network appliances with high-performance software taking advantage of high performance para-virtual devices, other acceleration mechanisms, and smart placement of instances. The origin of NFV comes from a working group from the [http://www.etsi.org/ European Telecommunications Standards Institute (ETSI)] whose work is the basis of most current implementations. The main consumers of NFV are Service providers (telecommunication providers and the like) who are looking to accelerate the deployment of new network services, and to do that, need to eliminate the constraint of slow renewal cycle of hardware appliances, which do not autoscale and limit their innovation.

NFV support for OpenStack aims to provide the best possible infrastructure for such workloads to be deployed in, while respecting the design principles of a IaaS cloud. In order for VNF to perform correctly in a cloud world, the underlying infrastructure needs to provide a certain number of functionalities which range from scheduling to networking and from orchestration to monitoring capacities. This means that to correctly support NFV use cases in OpenStack, implementations may be required across most, if not all, main OpenStack projects, starting with Neutron and Nova.

For more details on NFV, the following references may be useful:
* [http://www.etsi.org/technologies-clusters/technologies/nfv Definition of NFV by ETSI]
* [http://en.wikipedia.org/wiki/Network_Functions_Virtualization Definition of NFV on Wikipedia]

= Who we are =

''' Add your name here if you're joining the meetings - IRC nicks are pretty anonymous unless you give us a clue! Please keep the list in alphabetical order by IRC nick. '''
{| class="wikitable"
|-

| adrian-hoban || Adrian Hoban || Intel OpenStack team || NFV & SDN extensions across OpenStack projects
|-
| akhila-chetlapalle || Akhila Chetlapalle || TCS Openstack Team || NFV & SDN Test Framework with Openstack
|-
| alank35 || Alan Kavanagh || Ericsson Inc || NFV & SDN & Neutron and ODL
|-
| aleksandr_null || Aleksandr Shaposhnikov || Mirantis Inc || NFV, SDN, Core Networking, Neutron, Virtualization, Storage
|-
| Ali_Kafel || Ali Kafel || Stratus Technologies || State-full OpenStack, Cloud Orchestration with High Availability and Fault Tolerance for NFV / SDN
|-
| andrews || Andrew Sergeev || ADVA Optical Networking || NFV, Openstack
|-
| andrewv || Andrew Veitch || BTI Systems || NFV, SDN, Openstack
|-
| armax || Armando Migliaccio || HP || Neutron, NFV, SDN
|-
| arosen || Aaron Rosen || nicira/vmware || Automation, SDN/Neutron/NFV, Openstack
|-
| atylee || Andy Tylee || Metaswitch Networks || NFV, SR-IOV, data plane acceleration, orchestration
|-
| balajip || Balaji Padnala || Freescale OpenStack Team || NFV, SDN, SRIOV, Libvirt, Neutron, Nova, Service VMs and Service Chaining
|-
| banix || Mohammad Banikazemi || IBM || NFV, SDN, Neutron, OpenStack
|-
| bauzas || Sylvain Bauza || Red Hat || SLA and Scheduling in Nova
|-
| bertys || Bertrand Souville || DOCOMO Euro-Labs || NFV, SDN, OpenStack
|-
| cdub || Chris Wright || Red Hat || NFV and SDN work between OpenStack and OpenDaylight
|-
| cgoncalves || Carlos Goncalves || Instituto de Telecomunicacoes || Service Function Chaining, Traffic Steering
|-
| choonho || Choonho Son || Samsung || KVM, OpenStack & DPDK
|-
| cliljenstolpe || Christopher Liljenstolpe || Metaswitch Networks || Neutron, orchestration, network architecture
|-
| cloudon || Calum Loudon || Metaswitch Networks || Neutron, data plane acceleration, orchestration
|-
| ctlmcb || Kevin McBride || CenturyLink || OpenStack for NFV, SDN tech, Programmable Hardware/integrated circuits, etc.
|-
| dandrushko || Dmitriy Andrushko || Mirantis || SDN, NFV, OpenDaylight, network architecture
|-
| danpb || Daniel Berrange || Red Hat || Libvirt, KVM & Nova performance & enablement for NFV
|-
| davej || Dave Johnston|| Openwave Mobility || NFV on Openstack for the Telco industry
|-
| davidmck || David McKinley|| Oracle || OpenStack support for NFV
|-
| diga || Digambar Patil || Persistent System Ltd. || Neutron, Nova, SDN, NFV
|-
| djhunt || Jason Hunt || IBM || Orchestration, SDN, NFV
|-
| dmitry_huawei || Dmitry Meytin || Huawei || MANO integration with OpenStack
|-
| eranb || Eran Bello || ASOCS || NFV compute and accelerator resources integration with OpenStack
|-
| fjramons || Francisco-Javier Ramon Salguero || Telefonica || Libvirt, KVM & Nova performance & enablement for NFV
|-
| ggarcia || Gerardo Garcia || Telefonica || Libvirt, KVM & Nova performance & enablement for NFV
|-
| gc4rella || Giuseppe Carella || Fraunhofer FOKUS || NFV MANO, Service Function Chaining, SDN
|-
| heyongli || Yongli He || Intel Openstack team || nova enabling NFV SRIOV PCI passthrough
|-
| HiteshW || Hitesh Wadekar || Graduate Student at Clarkson University || SDN/Neutron/NFV, Openstack
|-
| ian_ott || Ian Jolliffe || Wind River || Openstack, NFV, Networking
|-
| ijw || Ian Wells || Cisco's Openstack team || Vendor neutral NFV infrastructure, Cisco NFV appliances
|-
| imendel || Itai Mendelsohn || Alcatel-Lucent || NFV in general and how OpenStack can enable it
|-
| irenab || Irena Berezovsky || Mellanox || NFV, SDN, NFV SRIOV PCI passthrough
|-
| JeremyLiu || Jeremy Liu || Huawei || NFV & OpenStack
|-
| jjstevensjj || Joe Stevens || HP Helion || NFV & Neutron
|-
| jmsoares || Joao Soares || Portugal Telecom || Service Function Chaining, Traffic Steering
|-
| kalyan || Kalyanjeet Gogoi || Juniper Networks || NFV integration with OpenStack
|-
| kranthi || Kranthi Molleti || Tech Mahindra || Neutron, NFV and Virtual Networking
|-
| KyleMacDonald || Kyle MacDonald || OpenNile || NFV / OpenStack / Carrier & Telco Deployment
|-
| LouisF || Louis Fourie || Huawei || NFV-MANO, Service Function chaining, Traffic steering
|-
| lukego || Luke Gorrie || Snabb || Making open source NFV work for Deutsche Telekom's TeraStream project
|-
| malini1 || Malini Bhandaru || Intel || NFV, Adv. Service VMs, compute node capabilities, security
|-
| martin_t || Martin Taylor || Metaswitch Networks || Neutron networking and data plane acceleration
|-
| matrohon || Mathieu Rohon || Orange || NFV, SDN, Neutron
|-
| mjbright || Mike Bright || HP || Openstack, NFV/SDN
|-
| mkashyap || Madhu Kashyap || Brocade || OpenStack, NFV / SDN
|-
| mpaolino || Michele Paolino || Virtual Open Systems || ARM, KVM, libvirt, Nova and Neutron
|-
| mpetrus || Margaret Petrus || VMware || NFV-MANO, OpenStack for Service Orchestration
|-
| natarajk|| Karthik Natarajan || Brocade || NFV integration with OpenStack
|-
| nbal || Nuri Bal || Cyan || OpenStack support of NFV, MANO in particular
|-
| nbouthors || Nicolas Bouthors || Qosmos || Service Chaining, Classifier VNFC
|-
| nijaba || Nick Barcet || eNovance || NFV support on OpenStack
|-
| nnikolaev || Nikolay Nikolaev || Virtual Open Systems || vhost-user maintainer, Snabbswitch, Nova and Neutron
|-
| prabhu-nk || Prabhuling Kalyani || Global Edge || NFV, Service Chaining
|-
| PushkarU || Pushkar Umaranikar || Graduate student at San Jose State University || SDN/Neutron/NFV, Openstack
|-
| radek ||Radoslaw Smigielski||Alcatel-Lucent||OpenStack+NFV, SR-IOV, PCI passthrough, KVM performance
|-
| Rajesh|| R || HP || NFV MANO and Helion
|-
| ravirik || Ravi Virik || AT&T || Neutron and Flowspace for NFV
|-
| r-mibu || Ryota Mibu || NEC || Nova enhancement for NFV
|-
| ricky.bo || ricky.bo || Huawei || Help better support NFV
|-
| rohit404 ||Rohit Agarwalla||Cisco's OpenStack team||OpenStack+NFV
|-
| rseth|| Rajeev Seth || Sonus Networks || NFV integration with OpenStack
|-
| runarut|| Larry Pearson || AT&T || OpenStack as NFVI, VNF Service Chaining
|-
| russellb || Russell Bryant || Project: OpenStack TC, Nova. Corporate: Red Hat || Nova. Ensuring requirements and designs are consumable by OpenStack developers. Reviewing designs and implementations.
|-
| timmer || Tim Reddin || HP Cloud || NFV, Kernel , OpenStack
|-
| s3wong || Stephen Wong || Midokura || NFV support on OpenStack
|-
| safchain || Sylvain Afchain || eNovance || NFV, SDN, Neutron
|-
| sasud || S Sud || Intel || NFV and SDN use case PoCs
|-
| sean-k-mooney || Sean Mooney || Intel OpenStack team || NFV & SDN enabling
|-
| sgordon || Steve Gordon || Red Hat || NFV and SDN enablement across OpenStack projects but particularly Nova and the Libvirt driver.
|-
| shane-wang || Shane Wang || Intel || NFV support on OpenStack, VM QoS in Nova, PCI/SR-IOV support
|-
| smazziotta || Sandro Mazziotta || eNovance || OpenStack extensions required to meet NFV requirements
|-
| tapiotallgren || Tapio Tallgren || Nokia Networks || OpenStack enhancements for NFV
|-
| tcroteau || Tammy Croteau || HP Cloud || Neutron and NFV
|-
| thomnico || Nicolas Thomas || Canonical || Allowing OpenStack to be gradually used in NFV type of deployments ETSI NFV IG participant.
|-
| tidwellr || Ryan Tidwell || HP || NFV, Neutron, SDN
|-
| Torsten || Torsten Bottjer || Swisscom || Orchestrating VNFs on Openstack
|-
| tvvcox || Tomas Von Veschler || Red Hat || Openstack enablement for NFVi and VIM
|-
| ulikleber || Ulrich Kleber || Huawei || Help better support NFV
|-
| vikasd || Vikas Deolaliker || ... || NFV & SDN extenstions across Openstack projects
|-
| vpandari || Vinod Pandarinathan || Cisco Systems || NFV Framework, Service Chaining and Neutron
|-
| vjardin || Vincent JARDIN || 6WIND || Help using DPDK applications efficiently and ivshmem to start with (memnic)
|-
| Venkatesh || Venkatesh || Wipro Technologies || NFV & SDN extenstions across Openstack projects
|-
| wenjing || Wenjing Chu || Dell || NFV, Openstack for NFV, OPNFV
|-
| yamahata || Isaku Yamahata || Intel || Neutron, servicevm, service chaining, traffic steering
|-
| yjiang5 || Yunhong Jiang || Intel || Nova enablement for NFV
|-
| yukiarbel || Yuki Arbel || Alcatel Lucent || NFV, Openstack for NFV
|-
| zeddii || Bruce Ashfield || Wind River || KVM, libvirt, nova and platform awareness for NFV
|-
| zhyu || Yu Zhang || Huawei || OpenStack enhancement for enabling NFV
|-
| zhipengh || Zhipeng Huang || Huawei || OpenStack enhancement for enabling NFV
|-
| zuqiang || Zu Qiang || Ericsson || NFV support in OpenStack
|}

= Mission statement =

<blockquote>The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV.</blockquote>

<blockquote>The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against.</blockquote>

[[IRC|OpenStack IRC details]]

Chair: Russell Bryant (russellb)

== Agenda for next meeting ==

Alternating between Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC] in #openstack-meeting-alt and Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0&p1=0 1600 UTC] in #openstack-meeting. See schedule below.

Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]

{| class="wikitable"
|-
! Date !! Time !! IRC Channel
|-
| Wednesday 22th October 2014 || 1400 UTC || #openstack-meeting-alt
|-
| Thursday 30th October 2014 || 1600 UTC || #openstack-meeting
|-
| Wednesday 5th November 2014 || 1400 UTC || No meeting, OpenStack Summit
|-
|}

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]

=Use Cases=

{| class="wikitable"
|-
! Workload Type !! Description || Characteristics !! Examples !! Requirements
|-
| Data plane || Tasks related to packet handing in an end-to-end communication between edge applications. ||
* Intensive I/O requirements - potentially millions of small VoIP packets per second per core
* Intensive memory R/W requirements
||
* CDN cache node
* Router
* IPSec tunneller
* Session Border Controller - media relay function
|| -
|-
| Control plane || Any other communication between network functions that is not directly related to the end-to-end data communication between edge applications. ||
* Less intensive I/O and R/W requirements than data plane, due to lower packets per second
* More complicated transactions resulting in (potentially) higher CPU load per packet.
||
* PPP session management
* Border Gateway Protocol (BGP) routing
* Remote Authentication Dial In User Service (RADIUS) authentication in a Broadband Remote Access Server (BRAS) network function
* Session Border Controller - SIP signaling function
* IMS core functions (S-CSCF / I-CSCF / BGCF)
|| -
|-
| Signal processing || All network function tasks related to digital processing
||
* Very sensitive to CPU processing capacity.
* Delay sensitive.
||
* Fast Fourier Transform (FFT) decoding
* Encoding in a Cloud-Radio Access Network (C-RAN) Base Band Unit (BBU)
* Audio transcoding in a Session Border Controller
|| -
|-
| Storage || All tasks related to disk storage.
||
* Varying disk, SAN, or NAS, I/O requirements based on applications, ranging from low to extremely high intensity.
||
* Logger
* Network probe
|| -
|-
|}

== ETSI-NFV Use Cases - High Level Description ==

ETSI NFV gap analysis document: https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf

===Use Case #1: Network Functions Virtualisation Infrastructure as a Service===

This is a reasonably generic IaaS requirement.

===Use Case #2: Virtual Network Function as a Service (VNFaaS)===
This primarily targets Customer Premise Equipment (CPE) devices such as access routers, enterprise firewall, WAN optimizers etc. with some Provider Edge devices possible at a later date. ETSI-NFV Performance & portability considerations will apply to deployments that strive to meet high performance and low latency considerations.

===Use Case #3: Virtual Network Platform as a Service (VNPaaS)===
This is similar to #2 but at the service level. At larger scale and not at the "app" level only.

===Use Case #4: VNF Forwarding Graphs===
Dynamic connectivity between apps in a "service chain".

===Use Case #5: Virtualisation of Mobile Core Network and IMS===
Primarily focusing on Evolved Packet Core appliances such as the Mobility Management Entity (MME), Serving Gateway (S-GW), etc. and the IP Multimedia Subsystem (IMS).

===Use Case #6: Virtualisation of Mobile base station===
Focusing on parts of the Radio Access Network such as eNodeB's, Radio Link Control and Packet Data Convergence Protocol, etc..

===Use Case #7: Virtualisation of the Home Environment===
Similar to Use Case 2, but with a focus on virtualising residential devices instead of enterprise devices. Covers DHCP, NAT, PPPoE, Firewall devices, etc.

===Use Case #8: Virtualisation of CDNs===
Content Delivery Networks focusing on video traffic delivery.

===Use Case #9: Fixed Access Network Functions Virtualisation===
Wireline related access technologies.

==Contributed Use Cases==

===Session Border Controller===

Contributed by: Calum Loudon

====Description====

Perimeta Session Border Controller, Metaswitch Networks. Sits on the edge of a service provider's network and polices SIP and RTP (i.e. VoIP) control and media traffic passing over the access network between end-users and the core network or the trunk network between the core and another SP.

====Characteristics====

* Fast and guaranteed performance:
** Performance in the order of several million VoIP packets (~64-220 bytes depending on codec) per second per core (achievable on COTS hardware).
** Guarantees provided via SLAs.
* Fully high availability
** No single point of failure, service continuity over both software and hardware failures.
* Elastically scalable
** NFV orchestrator adds and removes instances in response to network demands.
* Traffic segregation (ideally)
** Separate traffic from different customers via VLANs.

====Requirements====

* Fast & guaranteed performance (network)
** Packets per second target -> either SR-IOV or an accelerated DPDK-like data plane:
*** "SR-IOV Networking Support" (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)
*** "Open vSwitch to use patch ports" (https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)
*** "userspace vhost in ovd vif bindings" (https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)
*** "Snabb NFV driver" (https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)
*** "VIF_VHOSTUSER" (https://blueprints.launchpad.net/nova/+spec/vif-vhostuser)

* Fast & guaranteed performance (compute):
** To optimize data rate we need to keep all working data in L3 cache:
***"Virt driver pinning guest vCPUs to host pCPUs" (https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)
** To optimize data rate need to bind to NIC on host CPU's bus:
*** "I/O (PCIe) Based NUMA Scheduling" (https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)
**To offer guaranteed performance as opposed to 'best efforts' we need:
** To control placement of cores, minimise TLB misses and get accurate info about core topology (threads vs. hyperthreads etc.); maps to the remaining blueprints on NUMA & vCPU topology:
*** "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)
*** "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)
*** "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)
** May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.

* High availability:
** Requires anti-affinity rules to prevent active/passive being instantiated on same host - already supported, so no gap.

* Elastic scaling:
** Readily achievable using existing features - no gap.

* VLAN trunking:
** "VLAN trunking networks for NFV" (https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).

* Other:
** Being able to offer apparent traffic separation (e.g. service traffic vs. application management) over single network is also useful in some cases.
*** "Support two interfaces from one VM attached to the same network" (https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net)

===Virtual IMS Core===

Contributed by: Calum Loudon

====Description====

Project Clearwater, http://www.projectclearwater.org/. An open source implementation of an IMS core designed to run in the cloud and be massively scalable. It provides SIP-based call control for voice and video as well as SIP-based messaging apps. As an IMS core it provides P/I/S-CSCF function together with a BGCF and an HSS cache, and includes
a WebRTC gateway providing interworking between WebRTC & SIP clients.

====Characteristics relevant to NFV/OpenStack====

* Mainly a compute application: modest demands on storage and networking.
* Fully HA, with no SPOFs and service continuity over software and hardware failures; must be able to offer SLAs.
* Elastically scalable by adding/removing instances under the control of the NFV orchestrator.

====Requirements====

* Compute application:
** OpenStack already provides everything needed; in particular, there are no requirements for an accelerated data plane, nor for core pinning nor NUMA

*HA:
** implemented as a series of N+k compute pools; meeting a given SLA requires being able to limit the impact of a single host failure
** potentially a scheduler gap here: affinity/anti-affinity can be expressed pair-wise between VMs, which is sufficient for a 1:1 active/passive architecture, but an N+k pool needs a concept equivalent to "group anti-affinity" i.e. allowing the NFV orchestrator to assign each VM in a pool to one of X buckets, and requesting OpenStack to ensure no single host failure can affect more than one bucket
** (there are other approaches which achieve the same end e.g. defining a group where the scheduler ensures every pair of VMs within that group are not instantiated on the same host)
** for study whether this can be implemented using current scheduler hints

* Elastic scaling:
** as for compute requirements there is no gap - OpenStack already provides everything needed.

== References: ==
* [http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20&%20Portability%20Best%20Practises.pdf Network Functions Virtualization NFV Performance & Portability Best Practices - DRAFT]
* ETSI-NFV Use Cases V1.1.1 [http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf]

== Related Teams and Projects ==
* OpenStack Congress - Policy as a Service [https://wiki.openstack.org/wiki/Congress]

= Development Efforts =

== Active Bugs ==

Add the "nfv" tag to bugs to have them appear in these queries:

* Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
* Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv

== Active Blueprints ==
The NFV use case mappings identified below are from the perspective of higher performing use cases. Please note that there are many possible configurations of devices for each of these use cases and it is not implied that they will all need the proposed capability in the relevant blueprint.

There is an automatically updated gerrit dashboard for all specs and code under review here: http://nfv.russellbryant.net

PRIORITY - repeatedly mentioned at the BOF as blockers:

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
| VLAN trunking networks for NFV
This line item now confuses various requirements together:
VLAN tagged traffic transmissible over a tenant network is the most important (even if Openstack is otherwise VLAN unaware)
decomposition of VLAN trunks to virtual networks
VLAN tagged traffic to a physical appliance
management of VLANs on ports as sub-ports (nice to have, not a blocker)
| Neutron
| New
| https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (tenant trunking)
https://blueprints.launchpad.net/neutron/+spec/l2-gateway (physical appliance-specific decomposition)
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms (VLAN port management)
| https://review.openstack.org/#/c/100278/ (physical appliance-specific decomposition)
https://review.openstack.org/97714 (tenant trunking)
https://review.openstack.org/#/c/94612/ (subports)
https://review.openstack.org/#/c/92541/ (patch for subports)
| * #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Permit unaddressed interfaces for NFV use cases || Neutron || New
| https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity
| https://review.openstack.org/97715 https://review.openstack.org/#/c/99873/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
|}

The rest:

neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
|
Virt driver guest NUMA node placement & topology
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
Virt driver large page allocation for guest RAM [[#dupe|*]]
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages || https://review.openstack.org/93653 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
Virt driver pinning guest vCPUs to host pCPUs
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning || https://review.openstack.org/93652 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
: I/O (PCIe) Based NUMA Scheduling
|| Nova || Design Approved / Needs Code Review|| https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling || https://review.openstack.org/#/c/100871/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
| Soft affinity support for server groups || Nova || Abandoned || https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group || https://review.openstack.org/91328 ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/89712 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 vSwitch configuration may be needed to complete the forwarding graph (service chain).
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| Framework for Advanced Services in Virtual Machines || Neutron || Under Discussion || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms || ||
* #1 is a broadly applicable IaaS requirement.
* #2 Potential lifecycle management support
* #3 TBD?
* #4 TBD?
* #5 Potential lifecycle management support
* #6 Potential lifecycle management support
* #7 Potential lifecycle management support
* #8 Potential lifecycle management support
* #9 Potential lifecycle management support
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Design Approved / Needs Code Review || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524 ||
NOTE: this service chaining BP is all about chaining aaS services, not chaining tenant NFVs. Is this the one we want or do we require a new BP?
* #1 is a broadly applicable IaaS requirement.
* #2 May need to chain multiple functions to deliver a service.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 May need to chain multiple functions to deliver a service.
* #6 May need to chain multiple functions to deliver a service.
* #7 May need to chain multiple functions to deliver a service.
* #8 May need to chain multiple functions to deliver a service.
* #9 May need to chain multiple functions to deliver a service.
|-
| OVF Meta-Data Import via Glance || Glance || New || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || https://review.openstack.org/#/c/104904/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #3 TBD?
* #4 TBD?
* #5 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #6 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #7 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #8 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #9Needed as one optional path to auto import platform feature requests to meet performance targets.
|-
| colspan="6" | ''Support for high performance Intel(R) Data Plane Development Kit based vSwitches''
|-
|
: Open vSwitch to use patch ports in place of veth pairs for vlan n/w
|| Neutron || Superseded / Unknown || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use ||
* https://review.openstack.org/96183
* https://bugs.launchpad.net/neutron/+bug/1331569
*https://bugs.launchpad.net/neutron/+bug/1331569 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
|
: Support userspace vhost in ovs vif bindings
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost || https://review.openstack.org/95805 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| [http://snabb.co/nfv.html Snabb NFV] mechanism driver || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver || https://review.openstack.org/95711 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 TBD?
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| VIF_VHOSTUSER (qemu vhost-user) support || Nova || Approved || https://blueprints.launchpad.net/nova/+spec/vif-vhostuser || https://review.openstack.org/96138 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 TBD?
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
|Solver Scheduler - complex constraints scheduler with NFV use cases || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/solver-scheduler || https://review.openstack.org/#/c/96543/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Possibly needed for smarter scheduling decision making to help with performance.
* #3 TBD?
* #4 TBD?
* #5 Possibly needed for smarter scheduling decision making to help with performance.
* #6 Possibly needed for smarter scheduling decision making to help with performance.
* #7 Possibly needed for smarter scheduling decision making to help with performance.
* #8 Possibly needed for smarter scheduling decision making to help with performance.
* #9 Possibly needed for smarter scheduling decision making to help with performance.
|-
| Discless VM || Nova || Under discussion || https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe || ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Network QoS API || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api || https://review.openstack.org/#/c/88599 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons
* #3 TBD?
* #4 Needed to capture network QoS aspects of forwarding graph.
* #5 Needed for performance reasons
* #6 Needed for performance reasons
* #7 Needed for performance reasons
* #8 Needed for performance reasons
* #9 Needed for performance reasons
|-
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring || ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for some specialized use cases.
* #3 TBD?
* #4 Needed based on forwarding graph for specialized use cases.
* #5 Needed for some specialized use cases.
* #6 Needed for some specialized use cases.
* #7 Needed for some specialized use cases.
* #8 TBD?
* #9 Needed for some specialized use cases.
|-
| Traffic Steering Abstraction || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction || https://review.openstack.org/92477/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #6 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #7 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #8 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #9 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
|-
|}

=== Implemented (Juno) ===

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
| Support two interfaces from one VM attached to the same network || Nova || Design Approved / Implemented || https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net ||
* Spec: https://review.openstack.org/97716
* Patch: https://review.openstack.org/98488
||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| SR-IOV Networking Support || Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov || https://review.openstack.org/#/c/86606/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 _Potential_ intersect if forwarding graph makes any particular request about the port connectivity.
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 TBD?
* #9 Needed for performance reasons.
|-
| Virt driver guest vCPU topology configuration
|| Nova || Design Approved / Implemented || https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology || https://review.openstack.org/93510 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
| Evacuate instance to scheduled host || Nova || Approved / Implemented (juno-2) || https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance || https://review.openstack.org/84429 ||
|-
|}

== Needed Development Not Yet Started ==

TelcoWorkingGroup

2014-10-28T00:36:35Z

Karthik Natarajan: /* Who we are */

= What is NFV? =

NFV stands for Network Functions Virtualization. It defines the replacement of usually stand alone appliances used for high and low level network functions, such as firewalls, network address translation, intrusion detection, caching, gateways, accelerators, etc, into virtual instance or set of virtual instances, which are called Virtual Network Functions (VNF). In other words, it could be seen as replacing some of the hardware network appliances with high-performance software taking advantage of high performance para-virtual devices, other acceleration mechanisms, and smart placement of instances. The origin of NFV comes from a working group from the [http://www.etsi.org/ European Telecommunications Standards Institute (ETSI)] whose work is the basis of most current implementations. The main consumers of NFV are Service providers (telecommunication providers and the like) who are looking to accelerate the deployment of new network services, and to do that, need to eliminate the constraint of slow renewal cycle of hardware appliances, which do not autoscale and limit their innovation.

NFV support for OpenStack aims to provide the best possible infrastructure for such workloads to be deployed in, while respecting the design principles of a IaaS cloud. In order for VNF to perform correctly in a cloud world, the underlying infrastructure needs to provide a certain number of functionalities which range from scheduling to networking and from orchestration to monitoring capacities. This means that to correctly support NFV use cases in OpenStack, implementations may be required across most, if not all, main OpenStack projects, starting with Neutron and Nova.

For more details on NFV, the following references may be useful:
* [http://www.etsi.org/technologies-clusters/technologies/nfv Definition of NFV by ETSI]
* [http://en.wikipedia.org/wiki/Network_Functions_Virtualization Definition of NFV on Wikipedia]

= Who we are =

''' Add your name here if you're joining the meetings - IRC nicks are pretty anonymous unless you give us a clue! Please keep the list in alphabetical order by IRC nick. '''
{| class="wikitable"
|-

| adrian-hoban || Adrian Hoban || Intel OpenStack team || NFV & SDN extensions across OpenStack projects
|-
| akhila-chetlapalle || Akhila Chetlapalle || TCS Openstack Team || NFV & SDN Test Framework with Openstack
|-
| alank35 || Alan Kavanagh || Ericsson Inc || NFV & SDN & Neutron and ODL
|-
| aleksandr_null || Aleksandr Shaposhnikov || Mirantis Inc || NFV, SDN, Core Networking, Neutron, Virtualization, Storage
|-
| Ali_Kafel || Ali Kafel || Stratus Technologies || State-full OpenStack, Cloud Orchestration with High Availability and Fault Tolerance for NFV / SDN
|-
| andrews || Andrew Sergeev || ADVA Optical Networking || NFV, Openstack
|-
| andrewv || Andrew Veitch || BTI Systems || NFV, SDN, Openstack
|-
| armax || Armando Migliaccio || HP || Neutron, NFV, SDN
|-
| arosen || Aaron Rosen || nicira/vmware || Automation, SDN/Neutron/NFV, Openstack
|-
| atylee || Andy Tylee || Metaswitch Networks || NFV, SR-IOV, data plane acceleration, orchestration
|-
| balajip || Balaji Padnala || Freescale OpenStack Team || NFV, SDN, SRIOV, Libvirt, Neutron, Nova, Service VMs and Service Chaining
|-
| banix || Mohammad Banikazemi || IBM || NFV, SDN, Neutron, OpenStack
|-
| bauzas || Sylvain Bauza || Red Hat || SLA and Scheduling in Nova
|-
| bertys || Bertrand Souville || DOCOMO Euro-Labs || NFV, SDN, OpenStack
|-
| cdub || Chris Wright || Red Hat || NFV and SDN work between OpenStack and OpenDaylight
|-
| cgoncalves || Carlos Goncalves || Instituto de Telecomunicacoes || Service Function Chaining, Traffic Steering
|-
| choonho || Choonho Son || Samsung || KVM, OpenStack & DPDK
|-
| cliljenstolpe || Christopher Liljenstolpe || Metaswitch Networks || Neutron, orchestration, network architecture
|-
| cloudon || Calum Loudon || Metaswitch Networks || Neutron, data plane acceleration, orchestration
|-
| ctlmcb || Kevin McBride || CenturyLink || OpenStack for NFV, SDN tech, Programmable Hardware/integrated circuits, etc.
|-
| dandrushko || Dmitriy Andrushko || Mirantis || SDN, NFV, OpenDaylight, network architecture
|-
| danpb || Daniel Berrange || Red Hat || Libvirt, KVM & Nova performance & enablement for NFV
|-
| davej || Dave Johnston|| Openwave Mobility || NFV on Openstack for the Telco industry
|-
| davidmck || David McKinley|| Oracle || OpenStack support for NFV
|-
| diga || Digambar Patil || Persistent System Ltd. || Neutron, Nova, SDN, NFV
|-
| djhunt || Jason Hunt || IBM || Orchestration, SDN, NFV
|-
| dmitry_huawei || Dmitry Meytin || Huawei || MANO integration with OpenStack
|-
| eranb || Eran Bello || ASOCS || NFV compute and accelerator resources integration with OpenStack
|-
| fjramons || Francisco-Javier Ramon Salguero || Telefonica || Libvirt, KVM & Nova performance & enablement for NFV
|-
| ggarcia || Gerardo Garcia || Telefonica || Libvirt, KVM & Nova performance & enablement for NFV
|-
| gc4rella || Giuseppe Carella || Fraunhofer FOKUS || NFV MANO, Service Function Chaining, SDN
|-
| heyongli || Yongli He || Intel Openstack team || nova enabling NFV SRIOV PCI passthrough
|-
| HiteshW || Hitesh Wadekar || Graduate Student at Clarkson University || SDN/Neutron/NFV, Openstack
|-
| ian_ott || Ian Jolliffe || Wind River || Openstack, NFV, Networking
|-
| ijw || Ian Wells || Cisco's Openstack team || Vendor neutral NFV infrastructure, Cisco NFV appliances
|-
| imendel || Itai Mendelsohn || Alcatel-Lucent || NFV in general and how OpenStack can enable it
|-
| irenab || Irena Berezovsky || Mellanox || NFV, SDN, NFV SRIOV PCI passthrough
|-
| JeremyLiu || Jeremy Liu || Huawei || NFV & OpenStack
|-
| jjstevensjj || Joe Stevens || HP Helion || NFV & Neutron
|-
| jmsoares || Joao Soares || Portugal Telecom || Service Function Chaining, Traffic Steering
|-
| kalyan || Kalyanjeet Gogoi || Juniper Networks || NFV integration with OpenStack
|-
| natarajk|| Karthik Natarajan || Brocade || NFV integration with OpenStack
|-
| kranthi || Kranthi Molleti || Tech Mahindra || Neutron, NFV and Virtual Networking
|-
| KyleMacDonald || Kyle MacDonald || OpenNile || NFV / OpenStack / Carrier & Telco Deployment
|-
| LouisF || Louis Fourie || Huawei || NFV-MANO, Service Function chaining, Traffic steering
|-
| lukego || Luke Gorrie || Snabb || Making open source NFV work for Deutsche Telekom's TeraStream project
|-
| malini1 || Malini Bhandaru || Intel || NFV, Adv. Service VMs, compute node capabilities, security
|-
| martin_t || Martin Taylor || Metaswitch Networks || Neutron networking and data plane acceleration
|-
| matrohon || Mathieu Rohon || Orange || NFV, SDN, Neutron
|-
| mjbright || Mike Bright || HP || Openstack, NFV/SDN
|-
| mkashyap || Madhu Kashyap || Brocade || OpenStack, NFV / SDN
|-
| mpaolino || Michele Paolino || Virtual Open Systems || ARM, KVM, libvirt, Nova and Neutron
|-
| mpetrus || Margaret Petrus || VMware || NFV-MANO, OpenStack for Service Orchestration
|-
| nbal || Nuri Bal || Cyan || OpenStack support of NFV, MANO in particular
|-
| nbouthors || Nicolas Bouthors || Qosmos || Service Chaining, Classifier VNFC
|-
| nijaba || Nick Barcet || eNovance || NFV support on OpenStack
|-
| nnikolaev || Nikolay Nikolaev || Virtual Open Systems || vhost-user maintainer, Snabbswitch, Nova and Neutron
|-
| prabhu-nk || Prabhuling Kalyani || Global Edge || NFV, Service Chaining
|-
| PushkarU || Pushkar Umaranikar || Graduate student at San Jose State University || SDN/Neutron/NFV, Openstack
|-
| radek ||Radoslaw Smigielski||Alcatel-Lucent||OpenStack+NFV, SR-IOV, PCI passthrough, KVM performance
|-
| Rajesh|| R || HP || NFV MANO and Helion
|-
| ravirik || Ravi Virik || AT&T || Neutron and Flowspace for NFV
|-
| r-mibu || Ryota Mibu || NEC || Nova enhancement for NFV
|-
| ricky.bo || ricky.bo || Huawei || Help better support NFV
|-
| rohit404 ||Rohit Agarwalla||Cisco's OpenStack team||OpenStack+NFV
|-
| rseth|| Rajeev Seth || Sonus Networks || NFV integration with OpenStack
|-
| runarut|| Larry Pearson || AT&T || OpenStack as NFVI, VNF Service Chaining
|-
| russellb || Russell Bryant || Project: OpenStack TC, Nova. Corporate: Red Hat || Nova. Ensuring requirements and designs are consumable by OpenStack developers. Reviewing designs and implementations.
|-
| timmer || Tim Reddin || HP Cloud || NFV, Kernel , OpenStack
|-
| s3wong || Stephen Wong || Midokura || NFV support on OpenStack
|-
| safchain || Sylvain Afchain || eNovance || NFV, SDN, Neutron
|-
| sasud || S Sud || Intel || NFV and SDN use case PoCs
|-
| sean-k-mooney || Sean Mooney || Intel OpenStack team || NFV & SDN enabling
|-
| sgordon || Steve Gordon || Red Hat || NFV and SDN enablement across OpenStack projects but particularly Nova and the Libvirt driver.
|-
| shane-wang || Shane Wang || Intel || NFV support on OpenStack, VM QoS in Nova, PCI/SR-IOV support
|-
| smazziotta || Sandro Mazziotta || eNovance || OpenStack extensions required to meet NFV requirements
|-
| tapiotallgren || Tapio Tallgren || Nokia Networks || OpenStack enhancements for NFV
|-
| tcroteau || Tammy Croteau || HP Cloud || Neutron and NFV
|-
| thomnico || Nicolas Thomas || Canonical || Allowing OpenStack to be gradually used in NFV type of deployments ETSI NFV IG participant.
|-
| tidwellr || Ryan Tidwell || HP || NFV, Neutron, SDN
|-
| Torsten || Torsten Bottjer || Swisscom || Orchestrating VNFs on Openstack
|-
| tvvcox || Tomas Von Veschler || Red Hat || Openstack enablement for NFVi and VIM
|-
| ulikleber || Ulrich Kleber || Huawei || Help better support NFV
|-
| vikasd || Vikas Deolaliker || ... || NFV & SDN extenstions across Openstack projects
|-
| vpandari || Vinod Pandarinathan || Cisco Systems || NFV Framework, Service Chaining and Neutron
|-
| vjardin || Vincent JARDIN || 6WIND || Help using DPDK applications efficiently and ivshmem to start with (memnic)
|-
| Venkatesh || Venkatesh || Wipro Technologies || NFV & SDN extenstions across Openstack projects
|-
| wenjing || Wenjing Chu || Dell || NFV, Openstack for NFV, OPNFV
|-
| yamahata || Isaku Yamahata || Intel || Neutron, servicevm, service chaining, traffic steering
|-
| yjiang5 || Yunhong Jiang || Intel || Nova enablement for NFV
|-
| yukiarbel || Yuki Arbel || Alcatel Lucent || NFV, Openstack for NFV
|-
| zeddii || Bruce Ashfield || Wind River || KVM, libvirt, nova and platform awareness for NFV
|-
| zhyu || Yu Zhang || Huawei || OpenStack enhancement for enabling NFV
|-
| zhipengh || Zhipeng Huang || Huawei || OpenStack enhancement for enabling NFV
|-
| zuqiang || Zu Qiang || Ericsson || NFV support in OpenStack
|}

= Mission statement =

<blockquote>The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV.</blockquote>

<blockquote>The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against.</blockquote>

[[IRC|OpenStack IRC details]]

Chair: Russell Bryant (russellb)

== Agenda for next meeting ==

Alternating between Wednesdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=14&min=0&sec=0&p1=0 1400 UTC] in #openstack-meeting-alt and Thursdays at [http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=0&sec=0&p1=0 1600 UTC] in #openstack-meeting. See schedule below.

Agenda: [https://etherpad.openstack.org/p/nfv-meeting-agenda]

{| class="wikitable"
|-
! Date !! Time !! IRC Channel
|-
| Wednesday 22th October 2014 || 1400 UTC || #openstack-meeting-alt
|-
| Thursday 30th October 2014 || 1600 UTC || #openstack-meeting
|-
| Wednesday 5th November 2014 || 1400 UTC || No meeting, OpenStack Summit
|-
|}

== Previous meetings ==

* [http://eavesdrop.openstack.org/meetings/nfv/ Meeting logs]
* [https://etherpad.openstack.org/p/juno-nfv-bof Juno Design Summit NFV BoF]

=Use Cases=

{| class="wikitable"
|-
! Workload Type !! Description || Characteristics !! Examples !! Requirements
|-
| Data plane || Tasks related to packet handing in an end-to-end communication between edge applications. ||
* Intensive I/O requirements - potentially millions of small VoIP packets per second per core
* Intensive memory R/W requirements
||
* CDN cache node
* Router
* IPSec tunneller
* Session Border Controller - media relay function
|| -
|-
| Control plane || Any other communication between network functions that is not directly related to the end-to-end data communication between edge applications. ||
* Less intensive I/O and R/W requirements than data plane, due to lower packets per second
* More complicated transactions resulting in (potentially) higher CPU load per packet.
||
* PPP session management
* Border Gateway Protocol (BGP) routing
* Remote Authentication Dial In User Service (RADIUS) authentication in a Broadband Remote Access Server (BRAS) network function
* Session Border Controller - SIP signaling function
* IMS core functions (S-CSCF / I-CSCF / BGCF)
|| -
|-
| Signal processing || All network function tasks related to digital processing
||
* Very sensitive to CPU processing capacity.
* Delay sensitive.
||
* Fast Fourier Transform (FFT) decoding
* Encoding in a Cloud-Radio Access Network (C-RAN) Base Band Unit (BBU)
* Audio transcoding in a Session Border Controller
|| -
|-
| Storage || All tasks related to disk storage.
||
* Varying disk, SAN, or NAS, I/O requirements based on applications, ranging from low to extremely high intensity.
||
* Logger
* Network probe
|| -
|-
|}

== ETSI-NFV Use Cases - High Level Description ==

ETSI NFV gap analysis document: https://wiki.openstack.org/wiki/File:NFV%2814%29000154r2_NFV_LS_to_OpenStack.pdf

===Use Case #1: Network Functions Virtualisation Infrastructure as a Service===

This is a reasonably generic IaaS requirement.

===Use Case #2: Virtual Network Function as a Service (VNFaaS)===
This primarily targets Customer Premise Equipment (CPE) devices such as access routers, enterprise firewall, WAN optimizers etc. with some Provider Edge devices possible at a later date. ETSI-NFV Performance & portability considerations will apply to deployments that strive to meet high performance and low latency considerations.

===Use Case #3: Virtual Network Platform as a Service (VNPaaS)===
This is similar to #2 but at the service level. At larger scale and not at the "app" level only.

===Use Case #4: VNF Forwarding Graphs===
Dynamic connectivity between apps in a "service chain".

===Use Case #5: Virtualisation of Mobile Core Network and IMS===
Primarily focusing on Evolved Packet Core appliances such as the Mobility Management Entity (MME), Serving Gateway (S-GW), etc. and the IP Multimedia Subsystem (IMS).

===Use Case #6: Virtualisation of Mobile base station===
Focusing on parts of the Radio Access Network such as eNodeB's, Radio Link Control and Packet Data Convergence Protocol, etc..

===Use Case #7: Virtualisation of the Home Environment===
Similar to Use Case 2, but with a focus on virtualising residential devices instead of enterprise devices. Covers DHCP, NAT, PPPoE, Firewall devices, etc.

===Use Case #8: Virtualisation of CDNs===
Content Delivery Networks focusing on video traffic delivery.

===Use Case #9: Fixed Access Network Functions Virtualisation===
Wireline related access technologies.

==Contributed Use Cases==

===Session Border Controller===

Contributed by: Calum Loudon

====Description====

Perimeta Session Border Controller, Metaswitch Networks. Sits on the edge of a service provider's network and polices SIP and RTP (i.e. VoIP) control and media traffic passing over the access network between end-users and the core network or the trunk network between the core and another SP.

====Characteristics====

* Fast and guaranteed performance:
** Performance in the order of several million VoIP packets (~64-220 bytes depending on codec) per second per core (achievable on COTS hardware).
** Guarantees provided via SLAs.
* Fully high availability
** No single point of failure, service continuity over both software and hardware failures.
* Elastically scalable
** NFV orchestrator adds and removes instances in response to network demands.
* Traffic segregation (ideally)
** Separate traffic from different customers via VLANs.

====Requirements====

* Fast & guaranteed performance (network)
** Packets per second target -> either SR-IOV or an accelerated DPDK-like data plane:
*** "SR-IOV Networking Support" (https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov)
*** "Open vSwitch to use patch ports" (https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use)
*** "userspace vhost in ovd vif bindings" (https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost)
*** "Snabb NFV driver" (https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver)
*** "VIF_VHOSTUSER" (https://blueprints.launchpad.net/nova/+spec/vif-vhostuser)

* Fast & guaranteed performance (compute):
** To optimize data rate we need to keep all working data in L3 cache:
***"Virt driver pinning guest vCPUs to host pCPUs" (https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning)
** To optimize data rate need to bind to NIC on host CPU's bus:
*** "I/O (PCIe) Based NUMA Scheduling" (https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling)
**To offer guaranteed performance as opposed to 'best efforts' we need:
** To control placement of cores, minimise TLB misses and get accurate info about core topology (threads vs. hyperthreads etc.); maps to the remaining blueprints on NUMA & vCPU topology:
*** "Virt driver guest vCPU topology configuration" (https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology)
*** "Virt driver guest NUMA node placement & topology" (https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement)
*** "Virt driver large page allocation for guest RAM" (https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages)
** May need support to prevent 'noisy neighbours' stealing L3 cache - unproven, and no blueprint we're aware of.

* High availability:
** Requires anti-affinity rules to prevent active/passive being instantiated on same host - already supported, so no gap.

* Elastic scaling:
** Readily achievable using existing features - no gap.

* VLAN trunking:
** "VLAN trunking networks for NFV" (https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks et al).

* Other:
** Being able to offer apparent traffic separation (e.g. service traffic vs. application management) over single network is also useful in some cases.
*** "Support two interfaces from one VM attached to the same network" (https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net)

===Virtual IMS Core===

Contributed by: Calum Loudon

====Description====

Project Clearwater, http://www.projectclearwater.org/. An open source implementation of an IMS core designed to run in the cloud and be massively scalable. It provides SIP-based call control for voice and video as well as SIP-based messaging apps. As an IMS core it provides P/I/S-CSCF function together with a BGCF and an HSS cache, and includes
a WebRTC gateway providing interworking between WebRTC & SIP clients.

====Characteristics relevant to NFV/OpenStack====

* Mainly a compute application: modest demands on storage and networking.
* Fully HA, with no SPOFs and service continuity over software and hardware failures; must be able to offer SLAs.
* Elastically scalable by adding/removing instances under the control of the NFV orchestrator.

====Requirements====

* Compute application:
** OpenStack already provides everything needed; in particular, there are no requirements for an accelerated data plane, nor for core pinning nor NUMA

*HA:
** implemented as a series of N+k compute pools; meeting a given SLA requires being able to limit the impact of a single host failure
** potentially a scheduler gap here: affinity/anti-affinity can be expressed pair-wise between VMs, which is sufficient for a 1:1 active/passive architecture, but an N+k pool needs a concept equivalent to "group anti-affinity" i.e. allowing the NFV orchestrator to assign each VM in a pool to one of X buckets, and requesting OpenStack to ensure no single host failure can affect more than one bucket
** (there are other approaches which achieve the same end e.g. defining a group where the scheduler ensures every pair of VMs within that group are not instantiated on the same host)
** for study whether this can be implemented using current scheduler hints

* Elastic scaling:
** as for compute requirements there is no gap - OpenStack already provides everything needed.

== References: ==
* [http://docbox.etsi.org/ISG/NFV/Open/Latest_Drafts/NFV-PER001v009%20-%20NFV%20Performance%20&%20Portability%20Best%20Practises.pdf Network Functions Virtualization NFV Performance & Portability Best Practices - DRAFT]
* ETSI-NFV Use Cases V1.1.1 [http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf]

== Related Teams and Projects ==
* OpenStack Congress - Policy as a Service [https://wiki.openstack.org/wiki/Congress]

= Development Efforts =

== Active Bugs ==

Add the "nfv" tag to bugs to have them appear in these queries:

* Nova: https://bugs.launchpad.net/nova/+bugs?field.tag=nfv
* Neutron: https://bugs.launchpad.net/neutron/+bugs?field.tag=nfv

== Active Blueprints ==
The NFV use case mappings identified below are from the perspective of higher performing use cases. Please note that there are many possible configurations of devices for each of these use cases and it is not implied that they will all need the proposed capability in the relevant blueprint.

There is an automatically updated gerrit dashboard for all specs and code under review here: http://nfv.russellbryant.net

PRIORITY - repeatedly mentioned at the BOF as blockers:

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
| VLAN trunking networks for NFV
This line item now confuses various requirements together:
VLAN tagged traffic transmissible over a tenant network is the most important (even if Openstack is otherwise VLAN unaware)
decomposition of VLAN trunks to virtual networks
VLAN tagged traffic to a physical appliance
management of VLANs on ports as sub-ports (nice to have, not a blocker)
| Neutron
| New
| https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks (tenant trunking)
https://blueprints.launchpad.net/neutron/+spec/l2-gateway (physical appliance-specific decomposition)
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms (VLAN port management)
| https://review.openstack.org/#/c/100278/ (physical appliance-specific decomposition)
https://review.openstack.org/97714 (tenant trunking)
https://review.openstack.org/#/c/94612/ (subports)
https://review.openstack.org/#/c/92541/ (patch for subports)
| * #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Permit unaddressed interfaces for NFV use cases || Neutron || New
| https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces https://blueprints.launchpad.net/neutron/+spec/ml2-ovs-portsecurity
| https://review.openstack.org/97715 https://review.openstack.org/#/c/99873/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
|}

The rest:

neutron port enhancement related to servicevm is summarized at https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
|
Virt driver guest NUMA node placement & topology
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-numa-placement || https://review.openstack.org/93636 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
Virt driver large page allocation for guest RAM [[#dupe|*]]
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-large-pages || https://review.openstack.org/93653 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
Virt driver pinning guest vCPUs to host pCPUs
|| Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/virt-driver-cpu-pinning || https://review.openstack.org/93652 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
|
: I/O (PCIe) Based NUMA Scheduling
|| Nova || Design Approved / Needs Code Review|| https://blueprints.launchpad.net/nova/+spec/input-output-based-numa-scheduling || https://review.openstack.org/#/c/100871/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
| Soft affinity support for server groups || Nova || Abandoned || https://blueprints.launchpad.net/nova/+spec/soft-affinity-for-server-group || https://review.openstack.org/91328 ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Open vSwitch-based Security Groups: Open vSwitch Implementation of FirewallDriver || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver || https://review.openstack.org/89712 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 vSwitch configuration may be needed to complete the forwarding graph (service chain).
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| Framework for Advanced Services in Virtual Machines || Neutron || Under Discussion || https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms || ||
* #1 is a broadly applicable IaaS requirement.
* #2 Potential lifecycle management support
* #3 TBD?
* #4 TBD?
* #5 Potential lifecycle management support
* #6 Potential lifecycle management support
* #7 Potential lifecycle management support
* #8 Potential lifecycle management support
* #9 Potential lifecycle management support
|-
| Neutron Services Insertion, Chaining, and Steering || Neutron || Design Approved / Needs Code Review || https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering || https://review.openstack.org/93524 ||
NOTE: this service chaining BP is all about chaining aaS services, not chaining tenant NFVs. Is this the one we want or do we require a new BP?
* #1 is a broadly applicable IaaS requirement.
* #2 May need to chain multiple functions to deliver a service.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 May need to chain multiple functions to deliver a service.
* #6 May need to chain multiple functions to deliver a service.
* #7 May need to chain multiple functions to deliver a service.
* #8 May need to chain multiple functions to deliver a service.
* #9 May need to chain multiple functions to deliver a service.
|-
| OVF Meta-Data Import via Glance || Glance || New || https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import || https://review.openstack.org/#/c/104904/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #3 TBD?
* #4 TBD?
* #5 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #6 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #7 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #8 Needed as one optional path to auto import platform feature requests to meet performance targets.
* #9Needed as one optional path to auto import platform feature requests to meet performance targets.
|-
| colspan="6" | ''Support for high performance Intel(R) Data Plane Development Kit based vSwitches''
|-
|
: Open vSwitch to use patch ports in place of veth pairs for vlan n/w
|| Neutron || Superseded / Unknown || https://blueprints.launchpad.net/neutron/+spec/openvswitch-patch-port-use ||
* https://review.openstack.org/96183
* https://bugs.launchpad.net/neutron/+bug/1331569
*https://bugs.launchpad.net/neutron/+bug/1331569 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
|
: Support userspace vhost in ovs vif bindings
|| Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/libvirt-ovs-use-usvhost || https://review.openstack.org/95805 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| [http://snabb.co/nfv.html Snabb NFV] mechanism driver || Neutron || Approved || https://blueprints.launchpad.net/neutron/+spec/snabb-nfv-mech-driver || https://review.openstack.org/95711 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 TBD?
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
| VIF_VHOSTUSER (qemu vhost-user) support || Nova || Approved || https://blueprints.launchpad.net/nova/+spec/vif-vhostuser || https://review.openstack.org/96138 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed in the non-SR-IOV based deployments.
* #3 TBD?
* #4 TBD?
* #5 Needed in the non-SR-IOV based deployments.
* #6 TBD?
* #7 Needed in the non-SR-IOV based deployments.
* #8 TBD?
* #9 Needed in the non-SR-IOV based deployments.
|-
|Solver Scheduler - complex constraints scheduler with NFV use cases || Nova || Design review in progress || https://blueprints.launchpad.net/nova/+spec/solver-scheduler || https://review.openstack.org/#/c/96543/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Possibly needed for smarter scheduling decision making to help with performance.
* #3 TBD?
* #4 TBD?
* #5 Possibly needed for smarter scheduling decision making to help with performance.
* #6 Possibly needed for smarter scheduling decision making to help with performance.
* #7 Possibly needed for smarter scheduling decision making to help with performance.
* #8 Possibly needed for smarter scheduling decision making to help with performance.
* #9 Possibly needed for smarter scheduling decision making to help with performance.
|-
| Discless VM || Nova || Under discussion || https://blueprints.launchpad.net/nova/+spec/libvirt-empty-vm-boot-pxe || ||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| Network QoS API || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/quantum-qos-api || https://review.openstack.org/#/c/88599 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons
* #3 TBD?
* #4 Needed to capture network QoS aspects of forwarding graph.
* #5 Needed for performance reasons
* #6 Needed for performance reasons
* #7 Needed for performance reasons
* #8 Needed for performance reasons
* #9 Needed for performance reasons
|-
| Port mirroring || Neutron || Under discussion || https://blueprints.launchpad.net/neutron/+spec/port-mirroring || ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for some specialized use cases.
* #3 TBD?
* #4 Needed based on forwarding graph for specialized use cases.
* #5 Needed for some specialized use cases.
* #6 Needed for some specialized use cases.
* #7 Needed for some specialized use cases.
* #8 TBD?
* #9 Needed for some specialized use cases.
|-
| Traffic Steering Abstraction || Neutron || Design review in progress || https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction || https://review.openstack.org/92477/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #3 TBD?
* #4 Closely coupled requirement needed to deliver on a forwarding graph.
* #5 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #6 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #7 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #8 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
* #9 Similar to "Neutron Services Insertion, Chaining, and Steering". May need to chain multiple functions to deliver a service.
|-
|}

=== Implemented (Juno) ===

{| class="wikitable sortable"
|-
! Description !! Project(s) !! Status !! Blueprint(s) !! Design(s) !! ETSI-NFV Use Cases
|-
| Support two interfaces from one VM attached to the same network || Nova || Design Approved / Implemented || https://blueprints.launchpad.net/nova/+spec/multiple-if-1-net ||
* Spec: https://review.openstack.org/97716
* Patch: https://review.openstack.org/98488
||
* #1 is a broadly applicable IaaS requirement.
* #2 TBD?
* #3 TBD?
* #4 TBD?
* #5 TBD?
* #6 TBD?
* #7 TBD?
* #8 TBD?
* #9 TBD?
|-
| SR-IOV Networking Support || Nova || Design Approved / Needs Code Review || https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov || https://review.openstack.org/#/c/86606/ ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 _Potential_ intersect if forwarding graph makes any particular request about the port connectivity.
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 TBD?
* #9 Needed for performance reasons.
|-
| Virt driver guest vCPU topology configuration
|| Nova || Design Approved / Implemented || https://blueprints.launchpad.net/nova/+spec/virt-driver-vcpu-topology || https://review.openstack.org/93510 ||
* #1 is a broadly applicable IaaS requirement.
* #2 Needed for performance reasons.
* #3 TBD?
* #4 TBD?
* #5 Needed for performance reasons.
* #6 Needed for performance reasons.
* #7 Needed for performance reasons.
* #8 Needed for performance reasons.
* #9 Needed for performance reasons.
|-
| Evacuate instance to scheduled host || Nova || Approved / Implemented (juno-2) || https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance || https://review.openstack.org/84429 ||
|-
|}

== Needed Development Not Yet Started ==

Neutron Plugins and Drivers

2014-08-19T17:00:01Z

Karthik Natarajan: /* Existing Plugin and Drivers */

=== 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.

=== Plugin and Driver Processes ===
Getting a plugin or driver merged upstream into Neutron allows you the benefit of being a part of the simultaneous release, and likely having your plugin or driver packaged with distributions which ship releases based on the simultaneous releases from upstream. However, this is not a "free ride", you should ideally be giving back more than you are taking by getting your code upstream. When you submit your code, you're putting a burden on the existing reviews and infrastructure. The same goes with subsequent bug fixes and backports to stable releases. Thus, you should have someone from your company or team reviewing other code upstream, participating in meetings, etc. The following is a list of requirements for inclusion of code upstream:
* Code which passes review, has adequate unit tests, and passes pep8 guidelines.
* A [http://ci.openstack.org/third_party.html functioning CI system], which has been running successfully against your plugin/driver patches, and other patches as well.
* Participation in Neutron meetings, IRC channels, and email lists.
* A member of the plugin/driver team participating in code reviews of other upstream code.

=== Removal of Upstream Plugins or Drivers ===
If you fail to meet the criteria above, you risk having your plugin or driver removed from upstream. The core team will continue to evaluate third party CI systems to ensure they are running and correctly testing patches for third party plugins and drivers. If they fail to function, an email will be sent to the openstack-dev mailing list asking for the owner to fix this issue. Ideally, the owner will reply to the email thread, and will work with the Neutron and Infra teams to address the CI issue. If no reply is received or if adequate progress is not being made to address the issue within 2 weeks, a process to remove the plugin or driver from upstream will commence. To get your plugin or driver upstream after it has been removed will take a functioning third party CI system running for a month, correctly voting on changes upstream.

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

=== Testing Requirements ===
https://wiki.openstack.org/wiki/NeutronThirdPartyTesting

=== 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"
|-
! Vendor !! Plugin/Driver Name !! Contact Name !! Status !! Notes
|-
| Neutron Team || ML2 - OVS/LB || Infra Team || Y || Covered by Infra (Jenkins)
|-
| A10 Networks || LBaaS Driver || Doug Wiegley || Y || None
|-
| Arista Networks || ML2 Driver || Sukhdev Kapur || Y || None
|-
| Big Switch || Plugin || Kevin Benton || Y || 8.5 hour delay
|-
| Big Switch || ML2 Driver || Kevin Benton || Y || 8.5 hour delay
|-
| Brocade || Vyatta Plugin || Karthik Natarajan || Y || None
|-
| Brocade || ML2 Driver || Shiv Haris || Y || None
|-
| Cisco || Plugin - NXOS || Dane Leblanc || N || It will be removed in Juno
|-
| Cisco || Plugin - N1Kv || Dane Leblanc || Y || None
|-
| Cisco || ML2 - APIC || Dane Leblanc || N || It is not running against all Neutron commits, results are fake
|-
| Cisco || ML2 - DFA || Dane Leblanc || N || Results are fake. Needs clarification from Cisco
|-
| Cisco || ML2 - NXOS || Dane Leblanc || Y || None
|-
| Cisco || VPNaaS - Driver || Dane Leblanc || Y || None
|-
| Embrane || Plugin || Ignacio Scopetta || N || No CI in place. Candidate to be removed from Neutron
|-
| Embrane || LBaaS - Driver || Ignacio Scopetta || N || No CI in place. Candidate to be removed from Neutron
|-
| Freescale || ML2 - Driver || Trinath Somanchi || - || Needs to be verified
|-
| Freescale || FWaaS - Driver || Trinath Somanchi || - || Needs to be verified
|-
| IBM || Plugin - SDN-VE || Mohammad Banikazemi || - || Results are not clear. Need clarification from IBM
|-
| Juniper || Plugin - Contrail || Rudra Rugge || Y || Needs to start testing all Neutron commits. Plugins just got merged in Juno-3
|-
| Mellanox || Plugin || Omri Marcovitch || N || It is deprecated. Will be removed in Kilo
|-
| Mellanox || ML2 - Driver || Omri Marcovitch || N || Logs are not available. Needs clarification
|-
| Mellanox || ML2 - Sriovnic switch || Omri Marcovitch || N || Logs are not available. Needs clarification
|-
| Metaplugin || Plugin - Multiple || NTT Team || N || It is missing some Neutron commits
|-
| Midokura || Plugin - Midonet || Lucas Eznarriaga || Y || None
|-
| NEC || Plugin - OpenFlow || Akihiro Motoki || Y || None
|-
| Citrix NetScaler || LBaaS - Driver || Parikshit Manur || Y || Only testing LBaaS changes
|-
| Nuage Networks || Plugin - VSP || Franck Yelles || Y || Plugin behaving correctly for +1, manual -1
|-
| OFAgent || ML2 - OF || Yamamoto Takashi || Y || None
|-
| OneCoverage || Plugin - NVSD || Hemanth Ravi || N || Logs are not available. It is missing some Neutron commits. Needs clarification
|-
| OpenDaylight || ML2 - ODL || ? || - || It is missing some Neutron commits
|-
| PLUMgrid || Plugin - Director || Fawad Khaliq || Y || None
|-
| Ryu || Plugin - Ryu Controller || Yamamoto Takashi || - || It is been deprecated and It will be removed in Kilo
|-
| Radware || LBaaS - Driver || Samuel Bercovici || N || CI does not exist. Should be removed from Neutron
|-
| Tail-f NCS || ML2 - NCS || Luke Gorrie || - || It is missing some Neutron commits
|-
| vArmour || FWaaS || Gary Duan || N || CI does not exist. Should be removed from Neutron
|-
| VMware || Plugin - NSX || Aaron Rosen || - || It is missing some Neutron commits.
|}

Neutron Plugins and Drivers

2014-08-16T01:21:22Z

Karthik Natarajan:

=== 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"
|-
! Vendor !! Plugin/Driver Name !! Contact Name !! Status !! Notes
|-
| Neutron Team || ML2 - OVS/LB || Infra Team || Y || Covered by Infra (Jenkins)
|-
| A10 Networks || LBaaS Driver || Doug Wiegley || N || CI does not exists
|-
| Arista Networks || ML2 Driver || Sukhdev Kapur || Y || None
|-
| Big Switch || Plugin || Kevin Benton || Y || Negative test was not reported on gerrit. Needs clarification from BigSwitch
|-
| Big Switch || ML2 Driver || Kevin Benton || Y || Negative test was not reported on gerrit. Needs clarification from BigSwitch
|-
| Brocade || Vyatta Plugin || Karthik Natarajan || N || Only found logs for ML2. Needs clarification from Brocade
|-
| Brocade || ML2 Driver || Shiv Haris || Y || None
|-
| Cisco || Plugin - NXOS || Dane Leblanc || N || It will be removed in Juno
|-
| Cisco || Plugin - N1Kv || Dane Leblanc || Y || None
|-
| Cisco || ML2 - APIC || Dane Leblanc || N || It is not running against all Neutron commits, results are fake
|-
| Cisco || ML2 - DFA || Dane Leblanc || N || Results are fake. Needs clarification from Cisco
|-
| Cisco || ML2 - NXOS || Dane Leblanc || Y || None
|-
| Cisco || VPNaaS - Driver || ? || Y || None
|-
| Embrane || Plugin || Ignacio Scopetta || N || No CI in place. Candidate to be removed from Neutron
|-
| Embrane || LBaaS - Driver || Ignacio Scopetta || N || No CI in place. Candidate to be removed from Neutron
|-
| IBM || Plugin - SDN-VE || Mohammad Banikazemi || - || Results are not clear. Need clarification from IBM
|-
| Juniper || Plugin - Contrail || Rudra Rugge || Y || Needs to start testing all Neutron commits. Plugins just got merged in Juno-3
|-
| Mellanox || Plugin || Irena Berezovsky || N || It is deprecated. Will be removed in Kilo
|-
| Mellanox || ML2 - Driver || Irena Berezovsky || N || Logs are not available. Needs clarification
|-
| Mellanox || Plugin - Sriovnicagent || ? || N || CI does not exist. Should be removed from Neutron
|-
| Mellanox || ML2 - Sriovnicagent || ? || N || Logs are not available. Needs clarification
|-
| Metaplugin || Plugin - Multiple || NTT Team || N || It is missing some Neutron commits
|-
| Midokura || Plugin - Midonet || Lucas Eznarriaga || Y || None
|-
| NEC || Plugin - OpenFlow || Akihiro Motoki || Y || None
|-
| Nuage Networks || Plugin - VSP || Ronak Shah || - || It is missing some Neutron commits
|-
| OFAgent || ML2 - OF || Yamamoto Takashi || Y || None
|-
| OneCoverage || Plugin - NVSD || ? || N || Logs are not available. It is missing some Neutron commits. Needs clarification
|-
| OpenDaylight || ML2 - ODL || ? || - || It is missing some Neutron commits
|-
| PLUMgrid || Plugin - Director || Fawad Khaliq || Y || None
|-
| Ryu || Plugin - Ryu Controller || Yamamoto Takashi || - || It is been deprecated and It will be removed in Kilo
|-
| Radware || LBaaS - Driver || Samuel Bercovici || N || CI does not exist. Should be removed from Neutron
|-
| Tail-f NCS || ML2 - NCS || Luke Gorrie || - || It is missing some Neutron commits
|-
| vArmour || FWaaS || Gary Duan || N || CI does not exist. Should be removed from Neutron
|-
| VMware || Plugin - NSX || Aaron Rosen || - || It is missing some Neutron commits.
|}

ThirdPartySystems/Brocade Vyatta CI

2014-08-15T01:11:53Z

Karthik Natarajan:

{{ThirdPartySystemInfo|name=Brocade Vyatta CI
|account=gerrit account
|contact=DL-GRP-VYATTA-OSS@Brocade.com
|intent=To continuously test all Neutron patches against Brocade Vyatta Plugins
|structure=Jenkins to receive gerrit events, Scripts to trigger tests based on gerrit events, Devstack to setup OpenStack environments, Tempest to test
|method=Using Jenkins to receive triggers from Gerrit
|programs=Neutron
|status=In production}}

ThirdPartySystems/Brocade Vyatta CI

2014-08-15T01:09:50Z

Karthik Natarajan:

{{ThirdPartySystemInfo|name=Name of 3rd party system
|account=gerrit account
|contact=DL-GRP-VYATTA-OSS@Brocade.com
|intent=To continuously test all Neutron patches against Brocade Vyatta Plugins
|structure=Jenkins to receive gerrit events, Scripts to trigger tests based on gerrit events, Devstack to setup OpenStack environments, Tempest to test
|method=Using Jenkins to receive triggers from Gerrit
|programs=Neutron
|status=In production}}

ThirdPartySystems/Brocade Vyatta CI

2014-08-15T01:05:29Z

Karthik Natarajan: Created page with "{{subst:ThirdPartySystemInfoSubst}}"

{{ThirdPartySystemInfo|name=Name of 3rd party system
|account=gerrit account
|contact=contact info for people taking responsibility for this system
|intent=of this system, why do you have it
|structure=of this system, what tools are you using
|method=what you are actually doing
|programs=touched by this system
|status=of this system, in production, testing, non-voting, voting, disabled}}

ThirdPartySystems

2014-08-15T01:04:25Z

Karthik Natarajan: /* Third Party CI Systems */

== Third Party CI Systems ==

{| border="1" cellpadding="2" cellspacing="0" class="wikitable"
|+
!colspan="2"|3rd Party CI Systems
|-
!Name
!Link
|-
{{ThirdPartySystemTableEntry|A10 Networks CI}}
{{ThirdPartySystemTableEntry|Arista-CI}}
{{ThirdPartySystemTableEntry|Brocade Vyatta CI}}
{{ThirdPartySystemTableEntry|Big Switch CI}}
{{ThirdPartySystemTableEntry|Cisco Neutron CI}}
{{ThirdPartySystemTableEntry|DB Datasets CI}}
{{ThirdPartySystemTableEntry|Dell StorageCenter CI}}
{{ThirdPartySystemTableEntry|emc-vnx-ci}}
{{ThirdPartySystemTableEntry|Freescale CI}}
{{ThirdPartySystemTableEntry|HP Storage CI}}
{{ThirdPartySystemTableEntry|Hyper-V CI}}
{{ThirdPartySystemTableEntry|IBMPowerKVMCI}}
{{ThirdPartySystemTableEntry|Intel-PCI-CI}}
{{ThirdPartySystemTableEntry|Metaplugin CI}}
{{ThirdPartySystemTableEntry|Midokura CI}}
{{ThirdPartySystemTableEntry|murano-ci}}
{{ThirdPartySystemTableEntry|Nuage CI}}
{{ThirdPartySystemTableEntry|One Convergence CI}}
{{ThirdPartySystemTableEntry|RedHat CI}}
{{ThirdPartySystemTableEntry|Scality CI}}
{{ThirdPartySystemTableEntry|XenServer CI}}
{{ThirdPartySystemTableEntry|Example}}
|-
|}

Instructions on how to add a new system to the above table:
* Add an entry in the above table: <code><nowiki>{{ThirdPartySystemTableEntry|Example}}</nowiki></code> where Example is the name of your system
* Save the page and click on the link to the new page
* Select the "edit the page" option and paste <code><nowiki>{{subst:ThirdPartySystemInfoSubst}}</nowiki></code> into your new page and then save it. This will expand to a table. Edit the table replacing the placeholder values with the correct values for your system

----
[[Category:ThirdPartySystems]]

Brocade Vyatta L3 Plugin

2014-08-13T22:43:10Z

Karthik Natarajan:

== '''Introduction''' ==

Cloud service providers want to use Brocade Vyatta vRouter as a tenant virtual router in their OpenStack cloud. In order to perform the vRouter VM lifecycle management and required configurations, a new Neutron L3 plugin for Brocade Vyatta vRouter is required.

Brocade Neutron L3 Plugin for Vyatta vRouter supports CRUD operations on vRouter, add/remove interfaces from vRouter and floating IPs for VMs. It performs vRouter VM lifecyle management by calling Nova APIs during the Create and Delete Router calls. Once the vRouter VM is up, L3 plugin connects to the REST API end-point exposed by the vRouter VM using REST API to perform
the appropriate configurations.L3 plugin supports add/remove router interfaces by attaching/detaching the neutron ports to vRouter VM using Nova API.

[[File:Brocade_Vyatta_L3_Plugin.png]]<br />

== Plugin Configuration ==

1. Edit Neutron configuration file /etc/neutron/neutron.conf to specify Vyatta vRouter L3 plugin:

service_plugins =
neutron.plugins.brocade.vyatta.vrouter_neutron_plugin.VyattaVRouterPlugin

2. Import the Brocade Vyatta vRouter image using the below glance command:

glance image-create --name "Vyatta vRouter" --is-public true
--disk-format qcow2 --file ./vyatta_l3_plugin/image/vyatta_vrouter.qcow2
--container-format bare

3. Note the provider management network name. This needs to be specified in
the plugin configuration.

4. Configure the L3 plugin configuration file /etc/neutron/plugins/brocade/vyatta/vrouter.ini with the below parameters:

# Service VM Tenant admin name
tenant_admin_name = admin
# Service VM Tenant admin password
tenant_admin_password = devstack
# Service VM Tenant-id
tenant_id = <UUID of the admin or service VM tenant>
# Vyatta vRouter Image id. Image should be imported using Glance
image_id = <UUID>
# vRouter VM Flavor-id (Small)
flavor = 2
# vRouter Management network name
management_network = management

Once configured, L3 plugin will be invoked for the CRUD operations on
tenant router, add/remove router interfaces and floating ip support.

Brocade Vyatta L3 Plugin

2014-08-13T22:40:34Z

Karthik Natarajan: /* Introduction */

== '''Introduction''' ==

Cloud service providers want to use Brocade Vyatta vRouter as a tenant virtual router in their OpenStack cloud. In order to perform the vRouter VM lifecycle management and required configurations, a new Neutron L3 plugin for Brocade Vyatta vRouter is required.

Brocade Neutron L3 Plugin for Vyatta vRouter supports CRUD operations on vRouter, add/remove interfaces from vRouter and floating IPs for VMs. It performs vRouter VM lifecyle management by calling Nova APIs during the Create and Delete Router calls. Once the vRouter VM is up, L3 plugin connects to the REST API end-point exposed by the vRouter VM using REST API to perform
the appropriate configurations.L3 plugin supports add/remove router interfaces by attaching/detaching the neutron ports to vRouter VM using Nova API.

https://wiki.openstack.org/wiki/File:Brocade_Vyatta_L3_Plugin.png

== Plugin Configuration ==

1. Edit Neutron configuration file /etc/neutron/neutron.conf to specify Vyatta vRouter L3 plugin:

service_plugins =
neutron.plugins.brocade.vyatta.vrouter_neutron_plugin.VyattaVRouterPlugin

2. Import the Brocade Vyatta vRouter image using the below glance command:

glance image-create --name "Vyatta vRouter" --is-public true
--disk-format qcow2 --file ./vyatta_l3_plugin/image/vyatta_vrouter.qcow2
--container-format bare

3. Note the provider management network name. This needs to be specified in
the plugin configuration.

4. Configure the L3 plugin configuration file /etc/neutron/plugins/brocade/vyatta/vrouter.ini with the below parameters:

# Service VM Tenant admin name
tenant_admin_name = admin
# Service VM Tenant admin password
tenant_admin_password = devstack
# Service VM Tenant-id
tenant_id = <UUID of the admin or service VM tenant>
# Vyatta vRouter Image id. Image should be imported using Glance
image_id = <UUID>
# vRouter VM Flavor-id (Small)
flavor = 2
# vRouter Management network name
management_network = management

Once configured, L3 plugin will be invoked for the CRUD operations on
tenant router, add/remove router interfaces and floating ip support.

File:Brocade Vyatta L3 Plugin.png

2014-08-13T22:39:50Z

Karthik Natarajan:

Brocade Vyatta L3 Plugin

2014-08-13T22:22:11Z

Karthik Natarajan: Created page with "== '''Introduction''' == Cloud service providers want to use Brocade Vyatta vRouter as a tenant virtual router in their OpenStack cloud. In order to perform the vRouter VM li..."

== '''Introduction''' ==

Cloud service providers want to use Brocade Vyatta vRouter as a tenant virtual router in their OpenStack cloud. In order to perform the vRouter VM lifecycle management and required configurations, a new Neutron L3 plugin for Brocade Vyatta vRouter is required.

Brocade Neutron L3 Plugin for Vyatta vRouter supports CRUD operations on vRouter, add/remove interfaces from vRouter and floating IPs for VMs. It performs vRouter VM lifecyle management by calling Nova APIs during the Create and Delete Router calls. Once the vRouter VM is up, L3 plugin connects to the REST API end-point exposed by the vRouter VM using REST API to perform
the appropriate configurations.L3 plugin supports add/remove router interfaces by attaching/detaching the neutron ports to vRouter VM using Nova API.

== Plugin Configuration ==

1. Edit Neutron configuration file /etc/neutron/neutron.conf to specify Vyatta vRouter L3 plugin:

service_plugins =
neutron.plugins.brocade.vyatta.vrouter_neutron_plugin.VyattaVRouterPlugin

2. Import the Brocade Vyatta vRouter image using the below glance command:

glance image-create --name "Vyatta vRouter" --is-public true
--disk-format qcow2 --file ./vyatta_l3_plugin/image/vyatta_vrouter.qcow2
--container-format bare

3. Note the provider management network name. This needs to be specified in
the plugin configuration.

4. Configure the L3 plugin configuration file /etc/neutron/plugins/brocade/vyatta/vrouter.ini with the below parameters:

# Service VM Tenant admin name
tenant_admin_name = admin
# Service VM Tenant admin password
tenant_admin_password = devstack
# Service VM Tenant-id
tenant_id = <UUID of the admin or service VM tenant>
# Vyatta vRouter Image id. Image should be imported using Glance
image_id = <UUID>
# vRouter VM Flavor-id (Small)
flavor = 2
# vRouter Management network name
management_network = management

Once configured, L3 plugin will be invoked for the CRUD operations on
tenant router, add/remove router interfaces and floating ip support.

Neutron/FWaaS/JunoPlan

2014-07-22T17:41:00Z

Karthik Natarajan:

{| class="wikitable"
|-
! Task !! Gerrit Link !! Status !! Milestone !! Owner
|-
! Topic: Flavor and STF integration
|-
| Blueprint || https://review.openstack.org/92874 || Pending || Not set || Gary
|-
| Neutron || https://review.openstack.org/60699 || Pending || Not set || Gary
|-
| CLI/Client || Pending || Pending || Not set || Gary
|-
| Tempest || Pending || Pending || Not set || Gary
|-
| Horizon || Pending || Pending || Not set || Gary
|-
| Heat || Pending || Pending || Not set || Gary
|-
| Documentation || Pending || Pending || Not set || Gary
|-
! Topic: FWaaS DVR support
|-
| Blueprint || https://review.openstack.org/106225 || Pending || Not set || Sridar
|-
| Neutron || Pending || Pending || Not set || Sridar, Vishnu
|-
| CLI/Client || Pending || Pending || Not set || NA
|-
| Tempest || Pending || Pending || Not set || NA
|-
| Horizon || Pending || Pending || Not set || NA
|-
| Heat || Pending || Pending || Not set || NA
|-
| Documentation || Pending || Pending || Not set || NA
|-
! Topic: FWaaS Service Insertion
|-
| Blueprint || https://review.openstack.org/#/c/93128 || Pending || Not set || Kanzhe
|-
| Neutron || Pending || Pending || Not set || Kanzhe
|-
| CLI/Client || Pending || Pending || Not set || Kanzhe
|-
| Tempest || Pending || Pending || Not set || Kanzhe
|-
| Horizon || Pending || Pending || Not set || Kanzhe
|-
| Heat || Pending || Pending || Not set || Kanzhe
|-
| Documentation || Pending || Pending || Not set || Kanzhe
|-
! Topic: Service Objects
|-
| Blueprint || https://review.openstack.org/#/c/94133 || Pending || Juno-2 || Yi
|-
| Neutron || https://review.openstack.org/#/c/67784/ || Pending || Juno-2 || Yi
|-
| CLI/Client || Pending || Pending || Juno-2 || Yi
|-
| Tempest || Pending || Pending || Not set || Yi
|-
| Horizon || Pending || Pending || Not set || Yi
|-
| Heat || Pending || Pending || Not set || Yi
|-
| Documentation || Pending || Pending || Not set || Yi
|-
! Topic: Hit Counts
|-
| Blueprint || https://review.openstack.org/#/c/95779 || Pending || Not set || Pradeep
|-
| Neutron || Pending || Pending || Not set || Pradeep/Rajesh
|-
| CLI/Client || Pending || Pending || Not set || Pradeep
|-
| Tempest || Pending || Pending || Not set || Pradeep
|-
| Horizon || Pending || Pending || Not set || Pradeep
|-
| Heat || Pending || Pending || Not set || Pradeep
|-
| Documentation || Pending || Pending || Not set || Pradeep
|-
! Topic: Firewall Zones
|-
| Blueprint || Pending || Pending || Not set || Sridar
|-
| Neutron || Pending || Pending || Not set || Sridar/Rajesh
|-
| CLI/Client || Pending || Pending || Not set || Sridar
|-
| Tempest || Pending || Pending || Not set || Sridar
|-
| Horizon || Pending || Pending || Not set || TBD
|-
| Heat || Pending || Pending || Not set || TBD
|-
| Documentation || Pending || Pending || Not set || Sridar
|-
|-
! Topic: FWaaS Implementation for Cisco Virtual Router
|-
| Blueprint || Pending || Pending || Juno-2 || Sridar
|-
| Neutron || Pending || Pending || Juno-2|| Sridar + Cisco
|-
| CLI/Client || Pending || Pending || Juno-2 || Sridar + Cisco
|-
| Tempest || Pending || Pending || Juno-2 || Cisco
|-
| Horizon || Pending || Pending || Not set || Cisco
|-
| Heat || Pending || Pending || Not set || Cisco
|-
| Documentation || Pending || Pending || Not set || Sridar
|-
}

Neutron/FWaaS/JunoPlan

2014-06-25T22:49:30Z

Karthik Natarajan:

{| class="wikitable"
|-
! Task !! Gerrit Link !! Status !! Milestone !! Owner
|-
! Topic: Flavor and STF integration
|-
| Blueprint || https://review.openstack.org/92874 || Pending || Not set || Gary
|-
| Neutron || https://review.openstack.org/60699 || Pending || Not set || Gary
|-
| CLI/Client || Pending || Pending || Not set || Gary
|-
| Tempest || Pending || Pending || Not set || Gary
|-
| Horizon || Pending || Pending || Not set || Gary
|-
| Heat || Pending || Pending || Not set || Gary
|-
| Documentation || Pending || Pending || Not set || Gary
|-
! Topic: FWaaS Service Insertion
|-
| Blueprint || https://review.openstack.org/#/c/93128 || Pending || Not set || Kanzhe
|-
| Neutron || Pending || Pending || Not set || Kanzhe
|-
| CLI/Client || Pending || Pending || Not set || Kanzhe
|-
| Tempest || Pending || Pending || Not set || Kanzhe
|-
| Horizon || Pending || Pending || Not set || Kanzhe
|-
| Heat || Pending || Pending || Not set || Kanzhe
|-
| Documentation || Pending || Pending || Not set || Kanzhe
|-
! Topic: Service Objects
|-
| Blueprint || https://review.openstack.org/#/c/94133 || Pending || Juno-2 || Yi
|-
| Neutron || https://review.openstack.org/#/c/67784/ || Pending || Juno-2 || Yi
|-
| CLI/Client || Pending || Pending || Juno-2 || Yi
|-
| Tempest || Pending || Pending || Not set || Yi
|-
| Horizon || Pending || Pending || Not set || Yi
|-
| Heat || Pending || Pending || Not set || Yi
|-
| Documentation || Pending || Pending || Not set || Yi
|-
! Topic: Hit Counts
|-
| Blueprint || https://review.openstack.org/#/c/95779 || Pending || Not set || Pradeep
|-
| Neutron || Pending || Pending || Not set || Pradeep/Rajesh
|-
| CLI/Client || Pending || Pending || Not set || Pradeep
|-
| Tempest || Pending || Pending || Not set || Pradeep
|-
| Horizon || Pending || Pending || Not set || Pradeep
|-
| Heat || Pending || Pending || Not set || Pradeep
|-
| Documentation || Pending || Pending || Not set || Pradeep
|-
! Topic: Firewall Zones
|-
| Blueprint || Pending || Pending || Not set || Sridar
|-
| Neutron || Pending || Pending || Not set || Sridar/Rajesh
|-
| CLI/Client || Pending || Pending || Not set || Sridar
|-
| Tempest || Pending || Pending || Not set || Sridar
|-
| Horizon || Pending || Pending || Not set || TBD
|-
| Heat || Pending || Pending || Not set || TBD
|-
| Documentation || Pending || Pending || Not set || Sridar
|-
|-
! Topic: FWaaS Implementation for Cisco Virtual Router
|-
| Blueprint || Pending || Pending || Juno-2 || Sridar
|-
| Neutron || Pending || Pending || Juno-2|| Sridar + Cisco
|-
| CLI/Client || Pending || Pending || Juno-2 || Sridar + Cisco
|-
| Tempest || Pending || Pending || Juno-2 || Cisco
|-
| Horizon || Pending || Pending || Not set || Cisco
|-
| Heat || Pending || Pending || Not set || Cisco
|-
| Documentation || Pending || Pending || Not set || Sridar
|-
! Topic: FWaaS Implementation for Brocade Vyatta vRouter
|-
| Blueprint || Pending || Pending || Juno-2 || Karthik
|-
| Neutron || Pending || Pending || Juno-2|| Karthik + Brocade
|}

Tacker

2014-06-24T06:21:11Z

Karthik Natarajan:

= Tacker: ServiceVM/DeviceManager Project =
About new project
* https://docs.google.com/presentation/d/1gmuBprzedbvTQBt98JYiDFgLlTipDjr1ZgaEGL0xkcs/edit#slide=id.p
* IRC meeting: https://wiki.openstack.org/wiki/Meetings/ServiceVM
* launchpad project page: https://launchpad.net/tacker
* irc channel on freenode: #tacker

== Action Items ==
* discuss on starting incubation process: Would this project sustenable?
** review incubation page https://wiki.openstack.org/wiki/ServiceVM/Incubation
** Do we have enough developer to contribute?
** Do we have enough user/use case? How about NFV use case?

* create repo on stack-forge: https://review.openstack.org/#/c/97435/
** design/code review process
* deployment model
* neutron port attribute use case/requirement: https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
* terminology conversion https://wiki.openstack.org/wiki/ServiceVM/terminology
* API/data model design https://wiki.openstack.org/wiki/ServiceVM/api-datamodel
* Neutron/Nova/oslo.messaging related stuff https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items
** disable security groups: One thing that I am not sure if it has been discussed is, for L2 agent that supports security groups, such as ovs, some port filters are automatically enabled. Usually this is not what service VM wants. The port-security extension could be used to solve that issue, but it should be confirmed.(raised by Gary Duan)

== Links ==
* nfv: https://wiki.openstack.org/wiki/Meetings/NFV

== resource tracking ==
* Juno summit logistics
** https://etherpad.openstack.org/p/servicevm
** http://summit.openstack.org/cfp/details/395
*** https://blueprints.launchpad.net/neutron/+spec/device-manager-service-plugin
** http://summit.openstack.org/cfp/details/409
*** https://blueprints.launchpad.net/neutron/+spec/cisco-config-agent
** http://summit.openstack.org/cfp/details/54

* links
** Blueprint
*** https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms advanced service vm framework
*** https://blueprints.launchpad.net/horizon/+spec/neutron-adv-svc-vm horizon GUI
*** https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server oslo.messaging rpc proxy
*** https://blueprints.launchpad.net/python-neutronclient/+spec/advanced-servicevm-support python-neutronclient
*** https://blueprints.launchpad.net/devstack/+spec/neutron-adv-servicevm-support devstack
*** https://blueprints.launchpad.net/neutron/+spec/mcafee-ngfw-fwaas-driver Firewall as a Service mcafee ngfw driver
*** https://blueprints.launchpad.net/neutron/+spec/device-manager-service-plugin Resource manager for hosting devices like service VMs (Cisco)
*** https://blueprints.launchpad.net/neutron/+spec/cfg-agent-scheduler Scheduler of hosting devices to configuration agents (Cisco)
*** https://blueprints.launchpad.net/neutron/+spec/cisco-config-agent Configuration agent for hosting devices like service VMs (Cisco)
*** https://blueprints.launchpad.net/neutron/+spec/cisco-routing-service-vm Neutron routing service implemented using service VMs (Cisco)
*** https://blueprints.launchpad.net/neutron/+spec/router-scheduler-to-hosting-devices Scheduler of Neutron routers to hosting devices and l3agents (Cisco)
*** https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt Support for multivendor multi-instance L3-L7 physical and virtual network resources
**** https://wiki.openstack.org/w/images/7/71/Dnrm-blueprint-001.pdf
*** https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation Network Function Virtualization using OpenStack and Network Service Chain Implementation Architecture and Design
**** https://docs.google.com/file/d/0B05WnTIhCwXhaThPanhRYmZtd0E/edit
**** https://github.com/kumarcv/openstack-nf
** etherpad
*** https://etherpad.openstack.org/p/NeutronServiceVM etherpad
** document
*** https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# Status update of Framework for Advanced Services in Virtual Machines
*** https://docs.google.com/presentation/d/1Ir8MZC7fJb8SOhiZOEQovP_EvdFz_cF_-GEWsidAu7k/edit?pli=1#slide=id.g298d501cf_05 adv-svc-vm-impl
*** https://docs.google.com/presentation/d/14dvV3S9Eph2z-auk34I_Ftld-lHA3VMoyNWAPRTeWgE/edit?usp=sharing dividing features
*** https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server Oslo/blueprints/message-proxy-server

* patch review tracking
** neutron
*** https://review.openstack.org/#/c/72068/ Implement service vm framework: drivers for load balande
*** https://review.openstack.org/#/c/56892/ Implement service vm framework: REST API and DB model part
*** https://review.openstack.org/#/c/72070/ adv-svc-vm: support service vm framework
*** https://review.openstack.org/#/c/74194/ Implements Neutron routing API using Cisco appliances
*** https://review.openstack.org/#/c/74152/ Configuration agent for Cisco Service VMs
*** https://review.openstack.org/#/c/101281 Adds adv. services role and change policy to allow cross-tenant port creation
** neutron python client
*** https://review.openstack.org/#/c/59310/ setup logger name of NeutronCommand automatically
** oslo.messaging
*** https://review.openstack.org/#/c/77862/ _driver: implement unix domain support
*** https://review.openstack.org/#/c/77863/ proxy: implement proxy server

* repository
** github
*** https://github.com/yamahata/neutron/tree/adv-svc-vm
*** https://github.com/yamahata/python-neutronclient/tree/adv-svc-vm
*** https://github.com/yamahata/oslo.messaging/tree/adv-svc-vm
*** https://github.com/yamahata/devstack/tree/adv-svc-vm
*** https://github.com/Karthik-Natarajan/OpenStack-DNRM (Brocade DNRM) Design doc: https://drive.google.com/file/d/0B_-dXko4DlFNbmpPNENvT3o2Y00/edit?usp=sharing
*** https://github.com/CiscoSystems/neutron/tree/csr1kv_for_routing_juno Cisco service VM implementation with L3 router plugin (this branch contains code for Juno trunk for all 5 BP's marked "Cisco" above)
* bugs

Tacker

2014-06-18T21:46:48Z

Karthik Natarajan:

= Tacker: ServiceVM/DeviceManager Project =
About new project
* https://docs.google.com/presentation/d/1gmuBprzedbvTQBt98JYiDFgLlTipDjr1ZgaEGL0xkcs/edit#slide=id.p
* IRC meeting: https://wiki.openstack.org/wiki/Meetings/ServiceVM
* launchpad project page: https://launchpad.net/tacker
* irc channel on freenode: #tacker

== Action Items ==
* discuss on starting incubation process: Would this project sustenable?
** review incubation page https://wiki.openstack.org/wiki/ServiceVM/Incubation
** Do we have enough developer to contribute?
** Do we have enough user/use case? How about NFV use case?

* create repo on stack-forge: https://review.openstack.org/#/c/97435/
** design/code review process
* deployment model
* neutron port attribute use case/requirement: https://wiki.openstack.org/wiki/ServiceVM/neutron-port-attributes
* terminology conversion https://wiki.openstack.org/wiki/ServiceVM/terminology
* API/data model design https://wiki.openstack.org/wiki/ServiceVM/api-datamodel
* Neutron/Nova/oslo.messaging related stuff https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items
** disable security groups: One thing that I am not sure if it has been discussed is, for L2 agent that supports security groups, such as ovs, some port filters are automatically enabled. Usually this is not what service VM wants. The port-security extension could be used to solve that issue, but it should be confirmed.(raised by Gary Duan)

== Links ==
* nfv: https://wiki.openstack.org/wiki/Meetings/NFV

== resource tracking ==
* Juno summit logistics
** https://etherpad.openstack.org/p/servicevm
** http://summit.openstack.org/cfp/details/395
*** https://blueprints.launchpad.net/neutron/+spec/device-manager-service-plugin
** http://summit.openstack.org/cfp/details/409
*** https://blueprints.launchpad.net/neutron/+spec/cisco-config-agent
** http://summit.openstack.org/cfp/details/54

* links
** Blueprint
*** https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms advanced service vm framework
*** https://blueprints.launchpad.net/horizon/+spec/neutron-adv-svc-vm horizon GUI
*** https://blueprints.launchpad.net/oslo.messaging/+spec/message-proxy-server oslo.messaging rpc proxy
*** https://blueprints.launchpad.net/python-neutronclient/+spec/advanced-servicevm-support python-neutronclient
*** https://blueprints.launchpad.net/devstack/+spec/neutron-adv-servicevm-support devstack
*** https://blueprints.launchpad.net/neutron/+spec/mcafee-ngfw-fwaas-driver Firewall as a Service mcafee ngfw driver
*** https://blueprints.launchpad.net/neutron/+spec/device-manager-service-plugin Manager for Cisco devices and service VMs
*** https://blueprints.launchpad.net/neutron/+spec/cfg-agent-scheduler Scheduler of Cisco device to configuration agent
*** https://blueprints.launchpad.net/neutron/+spec/cisco-config-agent Configuration agent for Cisco service VMs
*** https://blueprints.launchpad.net/neutron/+spec/cisco-routing-service-vm Neutron routing service implemented using Cisco service VM
*** https://blueprints.launchpad.net/neutron/+spec/router-scheduler-to-hosting-devices Scheduler of Neutron routers to hosting devices
*** https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt Support for multivendor multi-instance L3-L7 physical and virtual network resources
**** https://wiki.openstack.org/w/images/7/71/Dnrm-blueprint-001.pdf
*** https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation Network Function Virtualization using OpenStack and Network Service Chain Implementation Architecture and Design
**** https://docs.google.com/file/d/0B05WnTIhCwXhaThPanhRYmZtd0E/edit
**** https://github.com/kumarcv/openstack-nf
** etherpad
*** https://etherpad.openstack.org/p/NeutronServiceVM etherpad
** document
*** https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# Status update of Framework for Advanced Services in Virtual Machines
*** https://docs.google.com/presentation/d/1Ir8MZC7fJb8SOhiZOEQovP_EvdFz_cF_-GEWsidAu7k/edit?pli=1#slide=id.g298d501cf_05 adv-svc-vm-impl
*** https://docs.google.com/presentation/d/14dvV3S9Eph2z-auk34I_Ftld-lHA3VMoyNWAPRTeWgE/edit?usp=sharing dividing features
*** https://wiki.openstack.org/wiki/Oslo/blueprints/message-proxy-server Oslo/blueprints/message-proxy-server

* patch review tracking
** neutron
*** https://review.openstack.org/#/c/72068/ Implement service vm framework: drivers for load balande
*** https://review.openstack.org/#/c/56892/ Implement service vm framework: REST API and DB model part
*** https://review.openstack.org/#/c/72070/ adv-svc-vm: support service vm framework
*** https://review.openstack.org/#/c/74152/ Configuration agent for Cisco Service VMs
*** https://review.openstack.org/#/c/74194/ Implements Neutron routing API using Cisco appliances
** neutron python client
*** https://review.openstack.org/#/c/59310/ setup logger name of NeutronCommand automatically
** oslo.messaging
*** https://review.openstack.org/#/c/77862/ _driver: implement unix domain support
*** https://review.openstack.org/#/c/77863/ proxy: implement proxy server

* repository
** github
*** https://github.com/yamahata/neutron/tree/adv-svc-vm
*** https://github.com/yamahata/python-neutronclient/tree/adv-svc-vm
*** https://github.com/yamahata/oslo.messaging/tree/adv-svc-vm
*** https://github.com/yamahata/devstack/tree/adv-svc-vm
*** https://github.com/Karthik-Natarajan/OpenStack-DNRM (Brocade DNRM)
* bugs

Tacker/Incubation

2014-06-03T19:54:19Z

Karthik Natarajan:

'''This page is Draft under review'''

== Project codename ==
Tacker

== Trademarks ==
(Does this project name, codename or contents use any trademarks, and if so, who owns them? List the codenames or other marks for which a trademark search should occur.)

No known trademarks.

== Summary ==
Tacker is a servicevm/device life cycle management for openstack clouds

== Parent Program name and PTL ==
Neutron networking/Kyle Mestery

== Mission statement ==
provide common framework/ground work for life cycle management of
ServiceVMs and virtual/physical services which conforms ETSI NFV.

=== Mission ===
establish/encourage ecosystem of virtual/physical appliance on
OpenStack.
To make it easy for appliance providers to integrate their
appliances (services implemented in virtual machines
(a.k.a. ServiceVM) or physical hardware) with OpenStack by
providing unified interface for life cycle management of
VMs/Services which is capable of multiple service/vendor.

== Detailed Description ==
(Background: this project is spin-out project from Neutron)

It is a quite common requirement to run services in virtual
machines aka ServiceVM. So far each OpenStack
service(Especially Neutron case) implemented their own life
cycle management of ServiceVMs/services and
hardware. Preparing/pooling/scheduling VMs/services and so on.
It resulted in duplicated work and rises the bar for appliance
provide to integrate appliances with OpenStack.

This project introduces a new service for managing
servicevm/device. Its responsibility is to:
# manage VMs/devices/services
# control the allocation of processing capacity in such devices As such the servicevm/device manager mainly serves other projects. Another natural responsibility of this service would be to keep track of and store the physical topology that the devices are part of.
# pluggable for each VMs/physical devices/services

As ETSI NFV is an important use case, NFV conformance is in the scope of this project.
This project services as some components of NFV MANO architecture.
http://www.ietf.org/proceedings/89/slides/slides-89-opsawg-7.pdf

* corresponding component:
** VNFM(VNF Manager)

* corresponding interfaces:
** VNF lifecycle management interface
** VNF lifecycle changes notifications interface
** VNF configuration interface

The relationship of NFV team and this project:

This project serves as (sub)component(s) necessary for NFV in openstack. The team will cooperate with NFV team.

* links to NFV team
** https://wiki.openstack.org/wiki/Meetings/NFV
** https://etherpad.openstack.org/p/juno-nfv-bof

== Basic roadmap for the project ==
from Near term to middle term
(Note: Addressing missing features for Neutron/Nova: some features are missing in Neutron/Nova. Those features can be addressed independently of this project.)
Design/patch review process will follow Neutron style as this project spun out of Neutron.

* terminology conversion. including NFV conformance/nomenclature
* produce a minimul working code as an independent service(out of Neutron. So far there were two implementations within Neutron). merge floating around multiple implementations.
* design review process: gerrit, wiki, google-doc
* API/data model design
* Actual coding(server, python client)
* establish testing
* Corporate with Neutron driver for Network service in VM (e.g. router vm, firewall vm) that interacts with Tacker
* make use of currently missing Neutron feature like service insertion
At first temporal shim code will be needed in Neutron for service
insertion, traffic steering and so on. At this moment those features
are under development. Once such features are stabilized and
public RestAPI is provided, convert the implmentation to use RestAPI
and remove the temporal shim code.
* consider generic VM/service scheduling

== Location of project source code ==
TODO:xxx

== Programming language, required technology dependencies ==
language: Python
Dependencies: alembic, eventlet, sqlalchemy, pbr, xxx (??? pecan, jsonschema, ...)

== Is project currently open sourced? What license? ==
yes and apache 2.0

== Level of maturity of software and team ==
=== Software ===
TODO(to be written)

=== Team ===
The team has worked for more than 3 months as Neutron subteam.
It as independent project out of Neutron started to work since
May 2014.
From three(XXX) differenct companies(Cisco, Midokura, Intel. XXX)

== Project developers qualifications ==
=== Isaku Yamahata(yamahata on irc) ===
Intel Senior Software Engineer - Core Developer

Isaku is a developer who has been involved with OpenStack since Diablo cycle.
He has contributed the first version of boot-from-volume to Nova, Ryu plugin to Neutron.
Recently he's mainly been contributing to Neutron and servicevm project.

=== Bob Melander(bmelande on irc) ===
Cicco - Core Developer
xxx(put BIO)

=== Stephen Wong(s3wong on irc) ===
Midokura - Core Developer
xxx(put BIO)

=== Hareesh Puthalath ===
Cisco - Developer
xxx(put BIO)

=== Sridar Kandaswamy ===
Cisco - Developer
xxx(put BIO)

===Yong sheng gong (gongysh on irc) ===
Unitedstack - Developer

===Karthik Natarajan (natarajk on irc) ===
Brocade - Developer

=== Kyle Mestery (mestery in IRC) ===
Cisco - Developer

== Infrastructure requirements (testing, etc) ==
no additional requirements to the current OpenStack Infrastructure

== Have all current contributors agreed to the OpenStack CLA? ==
yes