Jump to: navigation, search

Tacker/Incubation

< Tacker(Redirected from ServiceVM/Incubation)

This page is Draft under review

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 an OpenStack service for NFV Orchestration with a general purpose VNF Manager to deploy and operate Virtual Network Functions (VNFs) and Network Services on an NFV Platform. It is based on ETSI MANO Architectural Framework.

Parent Program name and PTL

Neutron networking/Kyle Mestery


Mission statement

Provide common framework/groundwork for lifecycle management of VNFs 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/container-based VNFs or physical hardware) with OpenStack by providing a unified interface for lifecycle management of VNFs 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:

  1. manage VMs/devices/services
  2. 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.
  3. 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.

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

Tacker: http://git.openstack.org/cgit/openstack/tacker/ Tacker Specs: http://specs.openstack.org/openstack/tacker-specs/ Tacker Python Client: http://git.openstack.org/cgit/openstack/python-tackerclient/

Programming language, and required technology dependencies

Language: Python. Dependencies: alembic, eventlet, sqlalchemy, pbr, 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 :)

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 : Core Developer
IRC handle: gongysh
Email: gong_ys2004@aliyun.com
Affiliation: 99cloud

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

Sripriya Seetharam

Status : Developer
IRC handle: sripriya
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

Prakash Ramchandran

Status : Core Developer
IRC handle: rprakash
Email: pramchan@yahoo.com
Affiliation: Futurewei Inc.

Bob Haddleton

Status: Developer
IRC handle: bobh
Email: bob.haddleton@alcatel-lucent.com
Affiliation: Alcatel-Lucent

Ahmed El-Khouly

Status: Developer
IRC handle: ahelkhou
Email: Ahmed.h.elkhouly@gmail.com
Affiliation: Nokia

Ashok Pachaiappan

Status: Comcast Lead
IRC handle: apachia
Email: ashok_pachaiappan@cable.comcast.com
Affiliation: Comcast

Rajkumar Kuppuraj

Status: Developer
IRC handle: rajkumar_kuppuraj
Email: Rajkumar_Kuppuraj@cable.comcast.com
Affiliation: Comcast

Shrinath Suresh

Status: Developer
IRC handle: Shrinath_Suresh
Email: Shrinath_Suresh@cable.comcast.com
Affiliation: Comcast

Bharath Thiruveedula

Status: Developer
IRC handle: tbh
Email: bharath_ves@hotmail.com
Affiliation:

Denis Makogon

Status: Developer
IRC handle: denismakogon
Email: lildee1991@gmail.com

Martin Oemke

Status : Developer
IRC handle: zeih
Email: zeih@zeih.eu
Affiliation: Deutsche Telekom

Ravi Chunduru

Status: Developer
IRC handle: rsun
Email: ravivsn@gmail.com
Affiliation: ClearPath Networks

Steve Wilkerson

Status: Developer
IRC handle: srwilkers
Email: wilkers.steve@gmail.com
Affiliation: AT&T

Manikantha Srinivas Tadi

Status: Developer
IRC handle: manikanta_tadi
Email: manikantha.tadi@gmail.com
Affiliation:

Dharmendra Kushwaha

Status : Developer
IRC handle: dkhuswaha
Email: dharmendra.kushwaha@nectechnologies.in
Affiliation: NEC

VenkataMahesh Kotha

Status : Developer
IRC handle: kvmahesh
Email: Venkata.Kotha@infinite.com
Affiliation: Infinite

Janki Chhatbar

Status : Developer
IRC handle: janki
Email: jankihchhatbar@gmail.com
Affiliation: RedHat

Tung Doan

Status : Developer
IRC handle: tung_doan
Email: doantungbk.203@gmail.com
Affiliation: K-ONE

Nguyen Hai

Status : Developer
IRC handle: nguyenhai
Email: nguyentrihai93@gmail.com
Affiliation: Soongsil University

Trinh Nguyen

Status : Developer
IRC handle: dangtrinhnt
Email: dangtrinhnt@gmail.com

Abdel Rabi

Status : NFV & SDN Architect
Email: abdel.rabi@vodafone.com
Affiliation: Vodafone Group

Infrastructure requirements (testing, etc)

No additional requirements to the current OpenStack Infrastructure

Have all current contributors agreed to the OpenStack CLA?

Yes