Jump to: navigation, search

Difference between revisions of "Tacker"

(Points of contact: added a link to a page of tracking specs/patches)
Line 1: Line 1:
= Tacker: mission & scope =
+
__NOTOC__
 +
 
 +
'''Title:''' Tacker / Service VM<br />
 +
 
 +
'''Aim:''' <tt style="color: blue">To develop a framework to simplify hosting of services in virtual and physical appliances</tt><br />
 +
 
 +
'''Repo:''' http://git.openstack.org/cgit/stackforge/tacker/<br />
 +
 
 +
'''Tags:'''  [Service VM] [Tacker]<br />
 +
 
 +
 
 +
__TOC__
 +
= 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.  
 
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.  
  
Line 7: Line 20:
 
* Lifecycle management of virtual machines and containers
 
* 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
 
** 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
+
* Control allocation of capacity in the devices<br/>
  
  
 
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.
 
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 ==
 
== Relation to Nova, Glance, Heat ==
Line 16: Line 30:
 
Tacker does not, but could, make use of Heat as a subsystem to manage virtual devices.
 
Tacker does not, but could, make use of Heat as a subsystem to manage virtual devices.
  
== Points of contact ==
+
 
 +
= Points of contact =
 
* IRC meeting information: https://wiki.openstack.org/wiki/Meetings/ServiceVM
 
* IRC meeting information: https://wiki.openstack.org/wiki/Meetings/ServiceVM
 
* Launchpad project page: https://launchpad.net/tacker
 
* Launchpad project page: https://launchpad.net/tacker
Line 22: Line 37:
 
* tracking spec/patch review: https://wiki.openstack.org/wiki/Tracking_ServiceVM_Reviews
 
* tracking spec/patch review: https://wiki.openstack.org/wiki/Tracking_ServiceVM_Reviews
  
== Use Cases ==
+
 
 +
= Use Cases =
  
 
{| class="wikitable"
 
{| class="wikitable"

Revision as of 07:05, 25 November 2014


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


Action Items


Links

Dependencies

We are tracking our dependencies on other features or blueprints in rest of the Openstack projects here: ServiceVM/Dependencies

Slides/Presentations

resource tracking