OpenStack Plugins

From DocWiki

Jump to: navigation, search

OpenStack (see background @ OpenStack) is an extensible cloud platform, and the primary vehicle for extension is the plugin. Many OpenStack components; Horizon, Neutron, etc. have plugins. Cisco has extended OpenStack's networking component (Neutron) with additional virtual devices, physical devices and new technologies. The plugins are all open source and exist in various open source repositories, see the specific plugin for information on its location. The plugins are open source components which extend OpenStack, not Cisco products. In some cases, there may be an option to buy a support contract from Cisco to support the plugin, see the specific plugin for details on this support.


Cisco OpenStack Neutron Plugins

The following virtualized plugins exist: CSR, Nexus1000.

The following physical device based plugins exist: ASR1000 Plugin, Nexus (switches).

The following technology based plugins exist: GBP/APIC/ACI.

These plugins are supported in various releases and from various repositories, detailed below.

Plugin Release Overview

OpenStack projects release software from a variety of code repositories, governed by OpenStack release policies. The Cisco OpenStack plugins are an extension of the OpenStack Neutron project and were formerly part of the OpenStack Big Tent (OpenStack Neutron plugins were removed from the Big Tent in 2016). As part of the big tent they were fully under OpenStack governance (they followed OpenStack release guidelines). The Cisco OpenStack plugins can still be used in conjunction with OpenStack, they are just not bundled with or documented on Regardless of their formal status, the Cisco OpenStack plugins continue to follow the OpenStack release guidelines as an independently released project (see In most circumstances the plugins will be co-released with the major releases of OpenStack to ensure customers can use the latest Cisco OpenStack plugin software with the latest OpenStack infrastructure software.

Not all of the OpenStack Cisco plugins release from the same repository. The Cisco UCS, Nexus 9000 and ASR1000 plugins release from the Cisco Systems github networking-cisco repository ( The Cisco APIC/ACI related plugins are hosted from the Cisco data center github repository (

The release branch/tagging process for the networking-cisco repository is slightly different than for other OpenStack projects (see a review of this below @ Plug Release Details). Many projects pull stable release branches and maintain these branches to provide support for a particular OpenStack release. For example, a stable-liberty branch was pulled off of the networking-cisco repository which contained liberty version software. However; as the plugin software is not closely coupled to the OpenStack infrastructure software, a single version of it can support multiple OpenStack infrastructure releases. Therefore, stable release branches are no longer pulled from networking-cisco. When new OpenStack infrastructure software is released a new version of the Cisco OpenStack Plugin repository is simply tagged (not branched) in our master branch, and the master branch will support the corresponding latest release of OpenStack infrastructure software and some number of previous releases. Details of the release are contained in the README file in the networking-cisco repository.

Plugin Data (per release)

Newton (release)

Mitaka (release)

Liberty (release)

Kilo (release)

Juno+ (release)

Juno+ is an enhanced version of the Juno release.

Juno (release)

Plugin Release Details

OpenStack provides support for multiple releases. At one time, 3 concurrent releases are supported. Cisco supports plugins associated with these releases (as do other vendors). Each vendor must choose a mechanism/methodology for how to support multiple releases in the easiest and most efficient way.

The table below lists the tradeoffs of two release mechanisms/methodologies:

Release Methodology
Single master branch Stable branch per release
Branch management support Single branch (w/ multiple releases) Multiple branches
Regression/test support per releases Same Same
Backward compatiblity/backport support Development and test done for every fix for every supported release Development and test done only when needed in prior release
Code clarity Single branch obfuscated with per release code Stable branch only contains code relevant to release
Standard Permitted Used by OpenStack core projects
Migration support Complex due to support for multiple releases Simple - one release to next release
Code risk Changes in one release may impact other releases Code isolated so no risk

With respect to back port support - there is a cost associated with the upfront support for multiple releases. The cost is estimated at 1/3 more than the cost of making the fix in a single release for a typical change (can be as high s 1x for a complex change). There is also a cost/extra cost for backporting later, in that you lose the context of the original fix. We estimate the extra cost of re-establishing this context as 1/3 more than doing the fix for all releases at the time you made the original fix.

Given these estimates, if there is not a need to backport many fixes to older releases, the single master branch is a high cost proposition. However; if there is a need for frequent back ports, the single master branch is good strategy, because not only does it save work (work is done at the time of the original fix) but it also prevents the need to do additional work on demand (urgently) to meet a customer need.


Rating: 0.0/5 (0 votes cast)

Personal tools