Tacker/Incubation
This page is Draft under review
Contents
- 1 Project codename
- 2 Trademarks
- 3 Summary
- 4 Parent Program name and PTL
- 5 Mission statement
- 6 Detailed Description
- 7 Basic roadmap for the project
- 8 Location of project source code
- 9 Programming language, required technology dependencies
- 10 Is project currently open sourced? What license?
- 11 Level of maturity of software and team
- 12 Team
Project codename
Tacker
Trademarks
(Does this project name, codename or contents use any trademarks, and if so, who owns them? List the codenames or other marks for which a trademark search should occur.)
No known trademarks.
Summary
Tacker is a servicevm/device life cycle management for openstack clouds
Parent Program name and PTL
Neutron networking/Kyle Mestery
Mission statement
provide common framework/ground work for life cycle management of ServiceVMs and virtual/physical services which conforms ETSI NFV.
Mission
establish/encourage ecosystem of virtual/physical appliance on OpenStack. To make it easy for appliance providers to integrate their appliances (services implemented in virtual machines (a.k.a. ServiceVM) or physical hardware) with OpenStack by providing unified interface for life cycle management of VMs/Services which is capable of multiple service/vendor.
Detailed Description
(Background: this project is spin-out project from Neutron)
It is a quite common requirement to run services in virtual machines aka ServiceVM. So far each OpenStack service(Especially Neutron case) implemented their own life cycle management of ServiceVMs/services and hardware. Preparing/pooling/scheduling VMs/services and so on. It resulted in duplicated work and rises the bar for appliance provide to integrate appliances with OpenStack.
This project introduces a new service for managing servicevm/device. Its responsibility is to:
- manage VMs/devices/services
- control the allocation of processing capacity in such devices As such the servicevm/device manager mainly serves other projects. Another natural responsibility of this service would be to keep track of and store the physical topology that the devices are part of.
- pluggable for each VMs/physical devices/services
As ETSI NFV is an important use case, NFV conformance is in the scope of this project.
This project services as some components of NFV MANO architecture.
http://www.ietf.org/proceedings/89/slides/slides-89-opsawg-7.pdf
- corresponding component:
- VNFM(VNF Manager)
- corresponding interfaces:
- VNF lifecycle management interface
- VNF lifecycle changes notifications interface
- VNF configuration interface
The relationship of NFV team and this project:
This project serves as (sub)component(s) necessary for NFV in openstack. The team will cooperate with NFV team.
- links to NFV team
Basic roadmap for the project
from Near term to middle term (Note: Addressing missing features for Neutron/Nova: some features are missing in Neutron/Nova. Those features can be addressed independently of this project.) Design/patch review process will follow Neutron style as this project spun out of Neutron.
- terminology conversion. including NFV conformance/nomenclature
- produce a minimul working code as an independent service(out of Neutron. So far there were two implementations within Neutron). merge floating around multiple implementations.
- design review process: gerrit, wiki, google-doc
- API/data model design
- Actual coding(server, python client)
- establish testing
- Corporate with Neutron driver for Network service in VM (e.g. router vm, firewall vm) that interacts with Tacker
- make use of currently missing Neutron feature like service insertion
At first temporal shim code will be needed in Neutron for service insertion, traffic steering and so on. At this moment those features are under development. Once such features are stabilized and public RestAPI is provided, convert the implmentation to use RestAPI and remove the temporal shim code.
- consider generic VM/service scheduling
Location of project source code
TODO:xxx
Programming language, required technology dependencies
language: Python Dependencies: alembic, eventlet, sqlalchemy, pbr, xxx (??? pecan, jsonschema, ...)
Is project currently open sourced? What license?
yes and apache 2.0
Level of maturity of software and team
Software
TODO(to be written)
Team
The team has worked for more than 3 months as Neutron subteam. It as independent project out of Neutron started to work since May 2014. From three(XXX) differenct companies(Cisco, Midokura, Intel. XXX)
Team Members
We are growing! Add your name and details here if you are planning to contribute or simply be kept in the loop :)
Isaku Yamahata
Status : Core Developer
IRC handle: yamahata
Email:
Affiliation: Intel
Isaku is a developer who has been involved with OpenStack since Diablo cycle. He has contributed the first version of boot-from-volume to Nova, Ryu plugin to Neutron. Recently he's mainly been contributing to Neutron and servicevm project.
Bob Melander
Status : Core Developer
IRC handle: bmelande
Email: bob.melander@gmail.com
Affiliation: Cisco
Stephen Wong
Status : Core Developer
IRC handle: s3wong
Email:
Affiliation: -
Hareesh Puthalath
Status : Developer
IRC handle: hareeshp
Email: hareesh.puthalath@gmail.com
Affiliation: Cisco
Sridar Kandaswamy
Status : Developer
IRC handle: SridarK
Email: skandasw@cisco.com
Affiliation: Cisco
Yong sheng gong
Status : Developer
IRC handle: gongysh
Email:
Affiliation: United Stack
Karthik Natarajan
Status : Developer
IRC handle: natarajk
Email:
Affiliation: Brocade
Kyle Mestery
Status : Developer
IRC handle: mestery
Email:
Affiliation: HP
Balaji Padnala
Status : Developer
IRC handle: balajip
Email:
Affiliation: FreeScale
Sridhar Ramaswamy
Status : Developer
IRC handle: SridharRamaswamy
Email:
Affiliation: Brocade
Vishwanath Jayaraman
Status : Developer
IRC handle: vishwanathj
Email: vishwanathj@hotmail.com
Affiliation: Brocade
Vikash Kumar==
Status: Developer
IRC handle: vks
Email: vikash.kumar@oneconvergence.com
Infrastructure requirements (testing, etc)
no additional requirements to the current OpenStack Infrastructure
Have all current contributors agreed to the OpenStack CLA?
yes