Jump to: navigation, search


Revision as of 08:19, 25 November 2014 by Hareeshpc (talk | contribs)

Title: Tacker / Service VM

Aim: To develop a framework to simplify hosting of services in virtual and physical appliances

Repo: http://git.openstack.org/cgit/stackforge/tacker/

Tags: [Service VM] [Tacker]

Mission & Scope

Tacker is a project developing a framework to simplify hosting of services in virtual and physical appliances. The framework relieves service developers of having to, themselves, implement functionality to manage devices that host service instances.

The capabilities and functionality envisioned for Tacker are:

  • Device inventory to keep track of available devices
  • Template constructs to describe and categorize devices of different types
  • Lifecycle management of virtual machines and containers
    • This includes maintenance of VM pools that can hide boot latency, thus making the VM instance immediately available
  • Control allocation of capacity in the devices

Implementation or orchestration of the services (e.g., FWaaS or LBaaS) is NOT in scope of Tacker. Initial use cases are advanced network service oriented but use cases from other areas are not excluded. Indeed, folks from non-networking communities are welcomed to participate and contribute.

Relation to Nova, Glance, Heat : Tacker makes use of Nova and Glance for VM and image management. Tacker does not, but could, make use of Heat as a subsystem to manage virtual devices.

Points of contact

Use Cases

No. Name Description User Priority Target Release Status
1 Define ServiceVM Ability to define a ServiceVM template using (a) instance image (2) device specification (to run the image) Operator High Kilo
2 ServiceVM CRUD API API for basic life-cycle management of ServiceVMs (a) acquire a service-vm instance (b) release a service-vm instance Plugin High Kilo
3 ServiceVM Neutron plugging driver Neutron port attributes to plug in ServiceVM to appropriate networks (a) Tenant L2 network Plugin High Kilo
4 Resource Pools of ServiceVMs Operator should be able to configure a pool of ServiceVMs to be in standby for immediate allocation (to avoid bootup latency) Operator Medium L
5 Service allocation using partial ServiceVM Allocate a portion of ServiceVM for specific service. Reason: Overhead cost of spinning another VM instance is high. If a ServiceVM supports multi-tenancy (for eg VRF for network services) a single ServiceVM can be segregated to support multiple tenant services. Note, there should be 100% tenant isolation while providing this scheme Operator, Plugin Medium L
6 Scheduling Scheme for ServiceVM allocation across a pool of VMs. Ability to schedule ServiceVMs based on different filters (Gnaat integration). For e.g. Tenant-A might have a higher application throughput needs. It would need a "high-end" FW ServiceVM with SR-IOV nics. Tacker scheduler need to get the "hint" from the plugin and allocate "appropriate" FW ServiceVM from the pool. Operator, Plugin Low M
7 Capacity management of ServiceVM Ability to report and use "remaining-capacity" data within a ServiceVM to host the next service request Plugin Low L
8 Docker Container Hosted Services Ability to host a ServiceVM in a Docker Container Operator Low M
9 Physical Appliance Hosted Services Ability to host a Service-Instance in a physical appliance Operator Low M


Tacker http://git.openstack.org/cgit/stackforge/tacker/
Tacker Specs http://git.openstack.org/cgit/stackforge/tacker-specs/
Tacker Python Client http://git.openstack.org/cgit/stackforge/python-tackerclient/
Tacker https://review.openstack.org/#/q/status:open+project:stackforge/tacker,n,z
Tacker Specs https://review.openstack.org/#/q/status:open+project:stackforge/tacker-specs,n,z
Tacker Python client https://review.openstack.org/#/q/status:open+project:stackforge/python-tackerclient,n,z

Quick Links

Action Items ServiceVM/ActionItems
Resources ServiceVM/Resources
Design ServiceVM/Design
Dependencies ServiceVM/Dependencies
Juno Design Summit ServiceVM/JunoSummit