This is a combined session. The mailing list discussion around the topic of service VMs being their own project will be discussed here, along with next steps.
This session will include the following subject(s):
Neutron service and devices:
Neutron has gone from a single (core) plugin architecture to one where the (core) plugin is accompanied with a variety of service plugins. The different plugins implement Neutron resources such as network, port, router, firewall, and so on. These resources are realized within different types of network equipment (like ToR switches or firewall boxes) or within regular servers (like in Linux network namespaces or vswitches). More recently, implementation of Neutron resources in Nova-based virtual machines have also emerged as an important use case.
It is not uncommon that a device is capable of implementing multiple Neutron services, e.g., routing, firewall and VPN. When services are provided by separated service plugins this leads to the question: what component manages (the lifecycle of) the devices that the service plugins place resources inside?
Furthermore, a device (not the least a VM) has a limit on how many Neutron resources it can support. So, how is resource allocation in a device done in a deployment with different, concurrently operating service plugins?
The objective of this session is to discuss the above questions and our proposal to handle them: to introduce a device manager service plugin. The task of such a device manager is to manage the life cycle of network devices and monitor their “health” status. The device manager can also be used to police allocation of resources in the devices so to arbitrate between other service plugins. The device manager service plugin is also a natural termination point of REST api for device management.
At Cisco we have developed such a device manager service plugin and as part of the session we can share our experiences from that effort. We also have code that we are willing to share with the community.
This session proposal is closely coupled to the session proposal: Configuration agent for Neutron services.
(Session proposed by Bob Melander)
Configuration agent for Neutron services:
The objective of this session is to discuss the use and benefits of configuration agents to instantiate Neutron resources (like routers or firewalls) in devices.
A configuration agent acts as a delegate for service plugins in configuration and instantiation tasks. This delegation helps to reduce load on the Neutron server. Another suitable task for configuration agents is to monitor the health of the devices it is given responsibility for.
As part of the session we will describe how we have evolved the L3 agent to become a modular configuration agent for (Cisco) devices. This evolved agent is designed to handle multiple services and uses device drivers to support different device types. A configuration task will typically involve pre-propressing and book-keeping steps coupled to a service that are common to all drivers. The configuration agent consolidates that into what we call service helpers. This reduces what need to be implemented in the device drivers.
Each service plugin can use its own RPC to interact with the configuration agent independently of other plugins. The typical plugin - configuration agent workflow involves notifications from service plugin that some resource has been created or updated. The configuration agent then periodically fetches the latest state on such resources. It then apply configurations to reflect the new state.
Another benefit of a joint agent for multiple services is that it can orchestrate the application of configurations so that they are applied in a ordered fashion in a device. By being a single point of all interactions with a device our configuration agent is also performing health monitoring of devices. As part of that the agent can place temporarily unavailable devices on a backlog. Configuration actions are then deferred until the device becomes available. This has been particularly useful when the device is a Nova-based VM that is created on demand.
This session proposal is closely coupled to the session proposal: Neutron services and devices.
(Session proposed by Hareesh Puthalath)
Advance servicevm framework next steps:
NFV(Network Function Virtualization) support is desired and advanced servicevm framework has been discussed and developed for a while. As several parties are interested on it, present the current status to let the people know the various software elements which have been developed and discuss the issues/requirements/related development effort to reach the consensus and define the roadmaps for Juno as next step.
