Jump to: navigation, search

Tacker

Revision as of 05:48, 18 November 2014 by Sridhar Ramaswamy (talk | contribs)

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 ServiceVM (a) acquire a service-vm instance (b) release a service-vm instance Operator High Kilo
3 ServiceVM Neutron plugging driver Neutron port attributes to plug in ServiceVM to appropriates networks (a) Tenant L2 network Operator High Kilo
4 Resource Pools of ServiceVMs Operator should be able to configure a pool of ServiceVMs to be in standby for immediate allocation 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. 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