Framework for Advanced Services in Virtual Machines
This blueprint defines a framework for creating, managing and deploying Neutron advanced services implemented as virtual machines. The goal is to enable advanced network services (e.g. Load Balancing, Security, Monitoring) that may be supplied by third party vendors, are deployed as virtual machines, and are launched and inserted into the tenant network on demand.
etherpad
https:/
current status
https:/
IRC meeting
https:/
horizon
https:/
python-
https:/
devstack
https:/
oslo.messaging enhancement
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Mark McClain
- Priority:
- Undefined
- Drafter:
- Greg Regnier
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Needs Code Review
- Milestone target:
-
next
- Started by
- Isaku Yamahata
- Completed by
- Isaku Yamahata
Related branches
Related bugs
Sprints
Whiteboard
23/12/2014 - what is the relationship between this BP and service chaining BP (such as Group Based Policy). In my understanding a "service VM" is just one piece of a chain - who will put the chain of multiple "service VM" together? Moreover, we might have the use-case of service scale-up/down where multiple "service VM"s must be launched - is it job of this BP? Thanks!
Yuriy
6/11/2014 -- as there are a few similar BPs around this topic (at least 4, and one already in "Approved"), can someone update how to coordinate or consolidate? Also, please add current date when post to whiteboard. Thanks!
Peng
I think the service VM framework is a very important feature. We have already asked about if there will be service VM support in Neutron during the last summit. I'm looking forward to learn more details about the design and the targeted release schedule for this blueprint
Thanks
Yi
This blueprint addresses a subset of the functionality described in the earlier DNRM blueprint: https:/
Let's get a coordinated discussion going.
There is a Blueprint already on network service VMs and more advanced features like service insertion, chaining defined. It has PoC ready on Grizzly as well.
https:/
Need to get all ideas into one place
Thanks,
-Ravi
There are two major use cases I see - where you allocate a VM for a tenant for every instance of the service (e.g. you create a load balancer VM for every LB you want) and where you share resources so that multiple tenants can use the same VM (e.g. you create one load balancer VM and divide it up so that it implements multiple LBs at the Neutron layer, potentially for multiple tenants). Were you considering both cases?
-Ian.
Thanks for the feedback. Lets have the coordinated discussion on the dev mailing list. Sumit has kindly gotten the ball rolling. - Greg
Hello Greg,
Blueprint you have put together is very much in line what we have done in openContrail virtual services implementation.
One thing that we have done is "Service instance" is a single type of service provided by virtual appliance.
e.g. firewall or load-balancer etc
"Service instance" itself can be made up one or more virtual machines. This will usually be case when you need to scale out services for performance reasons
Another thing that we have done is introduced a concept of service template. Service template describes how the service can be deployed. Image specified in the template can also be snapshot of VM with cookie cutter configuration.
service templates can be created by admins.Service instances are created by tenants (if allowed) using a service templates.
So a a single firewall instance from vendor can be packaged as transparent L2 firewall in one template and in network L3 firewall in another template.
Regards
-Harshad
Hi all,
I have updated the specification to reflect recent discussions. Thanks.
Greg
We should also make sure interface can be unplugged dynamically. I am experimenting interface attach/detach nova call's. There are still several places in detach function that prevent us from detach ports in a different tenant.
Gary
Hello Greg,
The spec is in read-only mode, can we allow interested reader to add comment or questions on the document directly?
Also, I think VLAN trunking may not be a rare case, in order to support large amount of networks (VNICs) with only a few service VMs, trunking could be a good choice.
Yi
The spec is now open to comment.
- Greg
Hi Greg,
I would like to propose and updated version of this spec. I know we are short on time before HK but wanted to see if the group would like to discuss my additions.
The proposal is located here.
https:/
It would address most cases. I left scale out out of the use cases as I think it needs a separate specification.
Thanks,
Mike Thompson
Greg,
Tried to email you and it bounced. Please gmail or call me when you get a chance.
Thanks,
Mike Thompson
-----
Wow, that was large addition to the document. Will read it with interest.
Greg, What it the best format for continuing this technical discussion? Shall interested parties follow Mike's example and make versions of the original doc and then you merge from them based on discussion on email and IRC?
Thanks,
Bob
--
I havent had a chance to consume the changes from Mike yet. The method Bob suggests is probably the best way for now.
Thanks,
Greg
When would everyone like to discuss? I am on IRC but may have to pop into meetings? Do we want to setup a time to have a chat about this?
Thanks,
MIke
Greg,
As we discussed today we will remove all but use case one and two for the initial proposal. This removes all of the multi-tenant requirements which simplifies the problem domain.
When we are ready to tackle the multi-tenant on the same service VM then we will need to rehash the other use cases.
Thanks,
Mike
---
All, I updated the spec to reflect recent discussions at face to face and some major input from Mike Thompson. Hope to discuss the latest at Sumit's IRC meeting on Service VMs on Tuesday.
Thanks,
Greg
---
I created a first draft for service VM library API as starting point
https:/
Isaku
Presentation from design summit now linked to Etherpad at:
https:/
Greg
---
basic future use case with multiple service VMs.
This is only for showing the future use cases that won't be excluded with this blue print.
Not for inclusion of the spec.
https:/
Isaku
Gerrit topic: https:/
Addressed by: https:/
Implement service vm framework(WIP):
overview of implementation(
https:/
The current status of the implementation
https:/
blueprint for horizon
https:/
---
Could it be more sense to have service VMs infrastructure as a separate OpenStack service or maybe as an extension of Nova? It seems like it doesn't fit into current Neutron architecture, plus there can be other OpenStack services that would want to use service VMs.
Aleks Chirko
---
Maybe yes in long term. Nova extension isn't a direction because other project like
HEAT can be utilized instead of nova and it should manage non-VM device.
The short term plan(I cycle) is to have a working code (in Neutron) and real examples/use cases
because it requires much effort to start new project.
Then, we can discuss the long term direction.
What do you think, Aleks?
Isaku Yamahata
---
Thank you for response, Isaku. To have working implementation in Neutron first sounds reasonable.
Aleks Chirko
---
Addressed by: https:/
tests/service: consolidate setUp/tearDown logic
Addressed by: https:/
Implement service vm framework: drivers for load balander (WIP)
Mar 4, 2014[Isaku Yamahata] oslo.messaging enhancement
https:/
[Isaku -- March 20, 2014]
IRC meeting page
https:/
python-
https:/
devstack
https:/
