The tenth OpenStack release codenamed Juno was released on October 16, 2014. This press release provides a good summary of what to expect in Juno. It also discusses important new capabilities included in the more than 340 new enhancements built in to Juno and highlights different usecases that showcase the diversity of workloads supported on OpenStack.
In the first part of the Cisco and Openstack Juno Release blog, I covered Cisco’s OpenStack team contributions to the Neutron project. Here I’ll provide details of our contributions to other OpenStack projects as well highlight our development efforts on StackForge. Cisco was the sixth top code reviewer for the Juno release across all projects in Juno release and is Foundation’s fifth largest company in terms of OpenStack membership.
This Nova blueprint was completed in Juno and provides support for configuration and provisioning of instances with SR-IOV port connectivity. The implementation generates SR-IOV specific libvirt domain and network configuration XML for the instances as well as includes the capability to schedule instances based on the compute nodes SR-IOV capabilities. One of the key use-cases for SR-IOV is Network Function Virtualization (NFV) that requires high performance traffic throughput in and out of a virtual machine providing network services (Virtual Network Function or VNF).
We proposed and implemented support for metering Network Services in Neutron using Ceilometer. This included new pollsters and notification handlers for Load Balancer as a Service (LBaaS), Firewall as a Service (FWaaS) and VPN as a Service (VPNaaS). The metrics are categorized into Provider or Service Level, providing different level of details. Provider level metrics help determine the type of implementation and its feature, whereas the Service level metrics provide more granular metric details on the service health and consumption. Separately, instance metrics were enhanced as part of this blueprint to support read and write metrics per instance disk device.
In the Cinder project, Fibre Channel Zone Manager allows FC SAN Zone/Access control management in conjunction with Fibre Channel block storage. It has a pluggable architecture and we contributed the Cisco FC Zoning plugin that automates creation, deletion and modification of zones in zonesets. Zones are configured automatically as part of the active zone set for the specified VSAN in the FC SAN to provide a more flexible and secure way of controlling access.
Enhancements to Horizon to enable configuration of IPv6 subnet modes is also part of the Juno release. This allows tenants to configure address and Route Advertisement (ra) mode for their subnets through the user dashboard. Neutron supports multiple IPv6 address configuration modes including SLAAC and DHCPv6 (both Stateful and Stateless modes).
The Cisco OpenStack team has been actively developing across different projects on StackForge as well. This provides an excellent platform for OpenStack related projects to make use of OpenStack project infrastructure and also continue to collaborate in the open.
OpenStack Services Puppet Modules – One of challenges that we hear about from our OpenStack customers is how to make OpenStack more manageable and deployable. There are several different deployment options for OpenStack and we have tremendous experience with automating the underlying system and service configuration via Puppet. We work with customers, partners and the community to enhance Puppet modules for OpenStack services and integrate with Cisco infrastructure as well. We also recently announced, in collaboration with RedHat, Cisco UCS Integrated Infrastructure that combines Cisco’s server, switching and management technologies with Red Hat’s enterprise-grade OpenStack platform.
Group Based Policy (GBP)– Currently staged on StackForge, this project aims to provide policy abstractions that extend the current Neutron API resources and introduces a declarative policy driven connectivity model that presents application-oriented interfaces to the user. The Group Based Policy framework implementation provides the flexibility for new API resources – End Points, End Point Groups, Contracts and Classifiers – that can be mapped to existing Neutron resources or passed directly to a third party controller. In addition to a mapping driver that supports all existing Neutron plugins, Cisco will also be releasing a driver to directly integrate GBP with its Application Policy Infrastructure Controller.
Nova Solver Scheduler – For resolving complex constraints based on policies and business rules, we have been collaborating with the community to develop a smart Nova Scheduler driver that models compute placement as a supply and demand problem. The intent is for the Solver Scheduler to integrate with the Gantt project that is aiming to separate out the Nova scheduler as a standalone project.
Cisco’s OpenStack team contributions are across numerous projects in OpenStack. Our aim is to work with the community, with our customers and partners to enable more successful OpenStack User Stories, resulting in a win-win situation. We are going to be presenting several general sessions that were selected as part of the community voting process at the upcoming Kilo Summit in Paris. You can find more details in this blog post and we look forward to seeing you there!
You can also download OpenStack Cisco Validated Designs, White papers, and more at www.cisco.com/go/openstack
Tags: ACI, Cinder, Cisco, horizon, IPv6, NOVA, OpenStack, Puppet, StackForge
[Note: This is the third a four-part series on the OpFlex protocol in Cisco ACI, how it enables an application-centric policy model, and why other SDN protocols do not. Part 1 | Part 2 | Part 4]
The Cisco ACI fabric is designed as an application-centric intelligent network. The Cisco APIC policy model is defined from the top down as a policy enforcement engine focused on the application itself and abstracting the networking functions underneath. The policy model unites with the advanced hardware capabilities of the Cisco ACI fabric underlying the business-application-focused control system.
The Cisco APIC policy object-oriented model is built on the distributed policy enforcement concepts for intelligent devices enabled by OpFlex and characterized by modern development and operations (DevOps) applications such as Puppet and Chef.
At the top level, the Cisco APIC policy model is built on a series of one or more tenants, which allows the network infrastructure administration and data flows to be segregated. Tenants can be customers, business units, or groups, depending on organization needs. Below tenants, the model provides a series of objects that define the application itself. These objects are endpoints and endpoint groups (EPGs) and the policies that define their relationships (see figure below). The relationship between two endpoints, which might be two virtual machines connected in a three-tier web application, can be implemented by routing traffic between the endpoints to firewalls and ADCs that enforce the appropriate security and quality of service (QoS) policies for the application and those endpoints.
Endpoints and Application Workloads Along with Tenants and Application Network Profiles Are the Foundation of the Cisco ACI Policy ModelEndpoints and Application Workloads Along with Tenants and Application Network Profiles Are the Foundation of the Cisco ACI Policy Model
For a more thorough description of the Cisco ACI application policy model, please refer to this whitepaper, or this one more specifically on Endpoint Groups.
For this discussion, the important feature to notice is the way that Cisco ACI policies are applied to application endpoints (physical and virtual workloads) and to EPGs. Configuration of individual network devices is ancillary to the requirements of the application and workloads. Individual devices do not require programmatic control as in prior SDN models, but are orchestrated according to the centrally defined and managed policies and according to application policies.
This model is catching hold in the industry and in the open source community. The OpenStack organization has begun work on including group-based policies to extend the OpenStack Neutron API for network orchestration with a declarative policy-based model based closely on EPG policies from Cisco ACI. (Note: “Declarative” refers to the orchestration model in which control is distributed to intelligent devices based on centralized policies, in contrast to retaining per-flow management control within the controller itself.)
Read More »
Tags: Chef, Cisco ACI, Cisco APIC, devops, Group Policy, Open Daylight, OpenStack, Puppet, SDN
Cisco is again a Premiere Sponsor of the OpenStack Summit, November 3-7 at Le Palais des Congrès in Paris. Here’s a summary of Cisco sponsored activities for your schedule.
Premier Breakout Session: “A World of Many (OpenStack) Clouds”
Wed. 05 Nov; 13:50 – 14:30
Cisco VP and Cloud CTO, Lew Tucker, will talk about how Cisco is working with leading service providers and enterprise customers to enable a world of interconnected clouds. Find out how Cisco is delivering greater automation, programmability, and openness for IT infrastructure, to support the next generation of virtualization and cloud.
Cisco Expo Booth, Location #C3
Stop by and pick up a special OpenStack@Cisco gift while supplies last. Cisco specialists in services, sales and product development will be available to chat and answer any questions.
Mon. 03 Nov: 8:15 – 9:30 and 11:15 – 19:30
Tues. 04 Nov: 10:45 – 18:00
Wed. 05 Nov: 9:00 – 16:30
See demonstrations of:
-OpenStack Networking Using Cisco CSR and Nexus
-Cisco UCS Integrated Infrastructure with Red Hat OpenStack Platform
-Group-Based Policy for Cloud Deployment
-Cisco UCS Bare-Metal-as-a-Service Cloud
Find out more about Metacloud, which officially became a part of Cisco on 17 SEP. Metacloud offers OpenStack clouds as a service, giving customers a choice of hosted or hybrid architecture, to operate like a public cloud from inside an organization’s own data center.
Breakout: Group Based Policy Extension for Networking
Mon. 03 Nov; 16:20 – 17:00
Sumit Naiksatam, Principal Engineer, Cisco
Breakout: Deploying and Auto-Scaling Applications on OpenStack with Heat
Tues. 04 Nov; 11:15 – 11:55
Daneyon Hansen, Software Engineer, Cisco
Panel Discussion: OpenStack Design Guide
Tues. 04 Nov; 14:00 – 14:40
Featuring: Maish Saidel-Keesing, Platform Architect, Cisco Video Technologies
Panel Discussion: Tips and Tools for Building a Successful OpenStack Group
Tues. 04 Nov; 14:50-15:30
Featuring Shannon McFarland, Principal Engineer and Mark T. Voelker, Technical Lead; Cisco
Breakout: Using Ceilometer Data to Detect Fraud in the OpenStack Cluster
Wed. 05 Nov; 9:50 – 10:30
Debojyoti Dutta, with Marc Solanas Tarre, Principal Engineers, Cisco
Breakout: Under the Hood with Nova, Libvirt and KVM (Part Two)
Wed. 05 Nov; 9:50 – 10:30
Rafi Khardalian, CTO, Metacloud/Cisco
Breakout: Scaling OpenStack Services: The Pre-TripleO Service Cloud
Wed. 05 Nov; 16:30 – 17:10
Kevin Bringard, with Richard Maynard
Technical Leads, Cisco
Evening Reception with Red Hat
Wed. 05 Nov; 20:00 – 2:00
Each attendee who completes the Red Hat and Cisco Booth Rally Challenge (instructions onsite) will receive a ticket for the Evening Reception held at Faust, an entertainment facility located at the foot of the Ivalides Esplanade, underneath the Alexandre III Bridge. Shuttle transportation will be available. Food and drinks will be served. This is an awesome location and might very well be the highlight of the week.
Tags: ACI, Cisco, InterCloud, lew tucker, Neutron, nexus, OpenStack, Paris, UCS
Curious about OpenStack? Don’t miss this episode of Engineers Unplugged, where Kenneth Hui (@hui_kenneth) and Gabriel Chapman (@bacon_is_king) explain the difference between OpenStack the project, product, and service using bacon as an analogy. Don’t watch hungry.
Cue the unicorns.
**Want to be Internet Famous? Act now! Join us for our next shoot: VMworld Barcelona. Tweet me @CommsNinja!**
This is Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
- Episodes will publish weekly (or as close to it as we can manage)
- Subscribe to the podcast here: engineersunplugged.com
- Follow the #engineersunplugged conversation on Twitter
- Submit ideas for episodes or volunteer to appear by Tweeting to @CommsNinja
- Practice drawing unicorns
Join the behind the scenes by liking Engineers Unplugged on Facebook.
The next stable OpenStack release codenamed “Juno” is slated to be released October 16, 2014. From improving live upgrades in Nova to enabling easier migration from Nova Network to Neutron, the OpenStack Juno release will address operational challenges in addition to providing many new features and enhancements across all projects.
As indicated in the latest Stackalytics contributor statistics, Cisco has contributed to seven different OpenStack projects including Neutron, Cinder, Nova, Horizon and Ceilometer as part of the Juno development cycle. This is up from five projects in the Icehouse release. Cisco also ranks first in the number of completed blueprints in Neutron as well.
In this blog post, I’ll focus on Neutron contributions, which are the major share of contributions in Juno from Cisco.
Cisco OpenStack team lead Neutron Community Contributions
An important blueprint that Cisco collaborated on and implemented with the community was to develop the Router Advertisement Daemon (radvd) for IPv6. With this support, multiple IPv6 configuration modes including SLAAC and DHCPv6 (both Stateful and Stateless modes) are now possible in Neutron. The implementation provides for running a radvd process in the router namespace for handling IPv6 auto address configuration.
To support the distributed routing model introduced by Distributed Virtual Router (DVR), this Firewall as a Service (FWaaS) blueprint implementation handles firewalling North–South traffic with DVR. The fix ensures that firewall rules are installed in the appropriate namespaces across the Network and Compute nodes to support perimeter firewall (North-South). However, firewalling East-West traffic with DVR will be handled in the next development cycle as a Distributed Firewall use case.
Additional capabilities in the ML2 and services framework were contributed for enabling better plugin and vendor driver integration. This included the following blueprint implementations –
Cisco device specific contributions in Neutron
Cisco added Application Policy Infrastructure Controller (APIC) ML2 MD and Layer 3 Service Plugin in the Juno development cycle. The ML2 APIC MD translates Neutron API calls into APIC data model specific requests and achieves tenant Layer 2 isolation through End-Point-Groups (EPG).
The APIC MD supports dynamic topology discovery using LLDP, reducing the configuration burden in Neutron for APIC MD and also ensures data is in-sync between Neutron and APIC. Additionally, the Layer 3 APIC service plugin enables configuration of internal and external subnet gateways on routers using Contracts to enable communication between EPGs as well as provide external connectivity. The APIC ML2 MD and Service Plugin have also been made available with OpenStack IceHouse release. Installation and Operation Guide for the driver and plugin is available here.
Enterprise-class virtual networking solution using Cisco Nexus1000v is enabled in OpenStack with its own core plugin. In addition to providing host based overlays using VxLAN (in both unicast and multi-cast mode), it provides Network and Policy Profile extensions for virtual machine policy provisioning.
The Nexus 1000v plugin added support for accepting REST API responses in JSON format from Virtual Supervisor Module (VSM) as well as control for enabling Policy Profile visibility across tenants. More information on features and how it integrates with OpenStack is provided here.
As an alternative to the default Layer 3 service implementations in Neutron, a Cisco router service plugin is now available that delivers Layer 3 services using the Cisco Cloud Services Router(CSR) 1000v.
The Cisco Router Service Plugin introduces a notion of “hosting device” to bind a Neutron router to a device that implements the router configuration. This allows the flexibility to add virtual as well as physical devices seamlessly into the framework for configuring services. Additionally, a Layer 3+ “configuration agent” is available upstream as well that interacts with the service plugin and is responsible for configuring the device for routing and advanced services. The configuration agent is multi-service capable, supports configuration of hardware or software based L3 service devices via device drivers and also provides device health monitoring statistics.
The VPN as a Service (VPNaaS) driver using the CSR1000v has been available since the Icehouse release, as a proof-of-concept implementation. The Juno release enhances the CSR1000v VPN driver such that it can be used in a more dynamic, semi-automated manner to establish IPSec site-to-site connections, and paves the way for a fully integrated and dynamic implementation with the Layer 3 router plugin planned for the Kilo development cycle.
The OpenStack team at Cisco has led, implemented and successfully merged upstream numerous blueprints for the Neutron Juno release. Clearly, some have been critical for the community and others enable customers to better integrate Cisco networking solutions with OpenStack Networking.
Stay tuned for more information on other project contributions in Juno and on Cisco lead sessions at the Kilo Summit in Paris !
You can also download OpenStack Cisco Validated Designs, White papers, and more at www.cisco.com/go/openstack
Tags: ACI, APIC, CSR1000v, IPv6, Juno, Neutron, Nexus1000V, OpenStack