Move from program-based structure to project-based
Move from a program-driven project structure (which prevented competition and innovation) to a project-based structure. Introduce new simple objective requirements for future OpenStack projects. Remove incubation process (keeping old incubation/integration requirements doc around as a reference until it's converted into a set of representative tags). This change is heavily based on a previous proposal by Doug Hellmann (see https://review.openstack.org/#/c/131422/1) Change-Id: Ida9f60d8cbd0dcf48669b82e619fc4016ee0bcb7
This commit is contained in:
parent
6d049c94c6
commit
fcc4046f7d
|
@ -6,40 +6,38 @@ Mission
|
|||
=======
|
||||
|
||||
The Technical Committee ("TC") is tasked with providing the technical
|
||||
leadership for OpenStack as a whole (all official programs, as defined below).
|
||||
leadership for OpenStack as a whole (all official projects, as defined below).
|
||||
It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration,
|
||||
Quality...), decides on issues affecting multiple programs, forms an ultimate
|
||||
appeals board for technical decisions, and generally has oversight over all the
|
||||
OpenStack project.
|
||||
Quality...), decides on issues affecting multiple projects, forms an ultimate
|
||||
appeals board for technical decisions, and generally has technical oversight
|
||||
over all of OpenStack.
|
||||
|
||||
OpenStack Programs
|
||||
==================
|
||||
OpenStack Project Teams
|
||||
=======================
|
||||
|
||||
OpenStack "Programs" are efforts which are essential to the completion of the
|
||||
OpenStack project mission, which is ''to produce the ubiquitous Open Source
|
||||
OpenStack "Project Teams" are groups of people dedicated to the completion of
|
||||
the OpenStack project mission, which is ''to produce the ubiquitous Open Source
|
||||
Cloud Computing platform that will meet the needs of public and private clouds
|
||||
regardless of size, by being simple to implement and massively scalable''.
|
||||
Programs can create any code repository and produce any deliverable they deem
|
||||
necessary to achieve their goals.
|
||||
Project Teams may create any code repository and produce any deliverable they
|
||||
deem necessary to achieve their goals.
|
||||
|
||||
Programs are placed under the oversight of the TC, and contributing to one of
|
||||
their code repositories grants you ATC status (see below). Current efforts or
|
||||
teams which want to be recognized as a Program should file a motion to the TC.
|
||||
The TC has ultimate authority over which programs are accepted or declined.
|
||||
The work of project teams is performed under the oversight of the TC.
|
||||
Contributing to one of their associated code repositories grants you ATC status
|
||||
(see below). The TC has ultimate authority over which project teams are
|
||||
designated as official OpenStack projects.
|
||||
|
||||
The current, official list of programs can be found [[Programs|here]].
|
||||
Project Team Leads
|
||||
==================
|
||||
|
||||
Program Leads
|
||||
=============
|
||||
|
||||
Program leads ("PTLs") manage day-to-day operations, drive the program goals
|
||||
and resolve technical disputes within their program. Each program community
|
||||
Project Team leads ("PTLs") manage day-to-day operations, drive the team goals
|
||||
and resolve technical disputes within their team. Each team
|
||||
should be self-managing by the contributors, and all disputes should be
|
||||
resolved through active debate and discussion by the community itself. However
|
||||
if a given debate cannot be clearly resolved, the PTL can decide the outcome.
|
||||
Although the TC is generally not involved in program-internal decisions, it
|
||||
still has oversight over program-specific decisions, especially when they
|
||||
affect other programs or go contrary to general OpenStack project goals.
|
||||
Although the TC is generally not involved in team-internal decisions, it
|
||||
still has oversight over team decisions, especially when they
|
||||
affect other teams or go contrary to general OpenStack goals.
|
||||
|
||||
TC Members
|
||||
==========
|
||||
|
@ -100,22 +98,22 @@ Election for PTL seats
|
|||
======================
|
||||
|
||||
PTL seats are completely renewed every 6 months. A separate election is run for
|
||||
each program. These elections are collectively held 5 weeks prior to each
|
||||
each project team. These elections are collectively held 5 weeks prior to each
|
||||
design summit, with nominations due 6 weeks prior to the summit and elections
|
||||
held open for no less than five business days.
|
||||
|
||||
Voters for PTL seats ("APC")
|
||||
============================
|
||||
|
||||
Voters for a given program PTL election are the active program contributors
|
||||
Voters for a given project's PTL election are the active project contributors
|
||||
("APC"), which are a subset of the Foundation Individual Members. Individual
|
||||
Members who committed a change to a repository of a program over the last two
|
||||
6-month release cycles are considered APC for that program.
|
||||
Members who committed a change to a repository of a project over the last two
|
||||
6-month release cycles are considered APC for that project team.
|
||||
|
||||
Candidates for PTL seats
|
||||
========================
|
||||
|
||||
Any APC can propose their candidacy for the corresponding program PTL election.
|
||||
Any APC can propose their candidacy for the corresponding project PTL election.
|
||||
Sitting PTLs are eligible to run for re-election each cycle, provided they
|
||||
continue to meet the criteria.
|
||||
|
||||
|
@ -135,9 +133,9 @@ Voters for TC seats ("ATC")
|
|||
The TC seats are elected by the Active Technical Contributors ("ATC"), which
|
||||
are a subset of the Foundation Individual Members. Individual Members who
|
||||
committed a change to a repository under ''any'' of the official OpenStack
|
||||
programs (as defined above) over the last two 6-month release cycles are
|
||||
Project Teams (as defined above) over the last two 6-month release cycles are
|
||||
automatically considered ATC. Specific contributors who did not have a change
|
||||
recently accepted in one of the OpenStack programs but nevertheless feel their
|
||||
recently accepted in one of the OpenStack projects but nevertheless feel their
|
||||
contribution to the OpenStack project is technical in nature (bug triagers,
|
||||
technical documentation writers...) can exceptionally apply for ATC either by
|
||||
sending an email to the TC chair or by being nominated by an existing ATC via
|
||||
|
|
|
@ -1,58 +1,58 @@
|
|||
# Program: Full name (email) [expires in]
|
||||
Dashboard: Jaromir Coufal (jcoufal@redhat.com) [September 2015]
|
||||
Dashboard: Liz Blanchard (lsurette@redhat.com) [September 2015]
|
||||
Identity: David Chadwick (d.w.chadwick@kent.ac.uk) [December 2015]
|
||||
Telemetry: Edouard Thuleau (edouard.thuleau@cloudwatt.com) [September 2015]
|
||||
Telemetry: Jordan Pittier (jordan.pittier@cloudwatt.com) [September 2015]
|
||||
# Project: Full name (email) [expires in]
|
||||
Horizon: Jaromir Coufal (jcoufal@redhat.com) [September 2015]
|
||||
Horizon: Liz Blanchard (lsurette@redhat.com) [September 2015]
|
||||
Keystone: David Chadwick (d.w.chadwick@kent.ac.uk) [December 2015]
|
||||
Ceilometer: Edouard Thuleau (edouard.thuleau@cloudwatt.com) [September 2015]
|
||||
Ceilometer: Jordan Pittier (jordan.pittier@cloudwatt.com) [September 2015]
|
||||
|
||||
# Entries below here automatically generated based on co-authored-by
|
||||
|
||||
# Compute program
|
||||
# (Repos for Compute are openstack/nova, openstack/python-novaclient)
|
||||
# Nova project
|
||||
# (Repos for Nova are openstack/nova, openstack/python-novaclient)
|
||||
|
||||
Compute: Bogdan Teleaga (bteleaga@cloudbasesolutions.com) [September 2015]
|
||||
Nova: Bogdan Teleaga (bteleaga@cloudbasesolutions.com) [September 2015]
|
||||
# Foundation profile: 20147
|
||||
Compute: Mouhammad-Nashwan Azhari (nmouhammad@cloudbasesolutions.com) [September 2015]
|
||||
Nova: Mouhammad-Nashwan Azhari (nmouhammad@cloudbasesolutions.com) [September 2015]
|
||||
# Foundation profile: 20156
|
||||
Compute: Pablo Fernando Cargnelutti (pablo.fernando.cargnelutti@intel.com) [September 2015]
|
||||
Nova: Pablo Fernando Cargnelutti (pablo.fernando.cargnelutti@intel.com) [September 2015]
|
||||
# Primary author in: openstack/ironic
|
||||
Compute: Fengqian Gao (fengqian.gao@intel.com) [September 2015]
|
||||
Nova: Fengqian Gao (fengqian.gao@intel.com) [September 2015]
|
||||
# Primary author in: openstack/sahara, openstack/ceilometer, openstack/horizon, openstack/ironic, openstack/nova, openstack/zaqar
|
||||
Compute: Sushma Korati (sushma_korati@persistent.co.in) [September 2015]
|
||||
Nova: Sushma Korati (sushma_korati@persistent.co.in) [September 2015]
|
||||
# Foundation profile: 5964
|
||||
Compute: Dmitry Tantsur (dtantsur@redhat.com) [September 2015]
|
||||
Nova: Dmitry Tantsur (dtantsur@redhat.com) [September 2015]
|
||||
# Primary author in: openstack/horizon, openstack/ironic, openstack/python-ironicclient
|
||||
Compute: Maithem (munshedm@vmware.com) [September 2015]
|
||||
Nova: Maithem (munshedm@vmware.com) [September 2015]
|
||||
# Primary author in: openstack/python-glanceclient, openstack/nova
|
||||
Compute: Ian Wells (iawells@cisco.com) [September 2015]
|
||||
Nova: Ian Wells (iawells@cisco.com) [September 2015]
|
||||
# Primary author in: openstack/nova
|
||||
Compute: Shawn Hartsock (hartsocks@acm.org) [September 2015]
|
||||
Nova: Shawn Hartsock (hartsocks@acm.org) [September 2015]
|
||||
# Foundation profile: 10853
|
||||
Compute: Cyril Roelandt (cyril.roelandt@enovance.com) [September 2015]
|
||||
Nova: Cyril Roelandt (cyril.roelandt@enovance.com) [September 2015]
|
||||
# Primary author in: openstack/python-glanceclient, openstack/python-neutronclient, openstack/python-tuskarclient, openstack/python-saharaclient, openstack/api-site, openstack/ceilometer, openstack/python-ceilometerclient, openstack/python-keystoneclient, openstack/horizon, openstack/python-heatclient, openstack/nova, openstack/python-novaclient, openstack/trove, openstack/python-troveclient
|
||||
Compute: Ionut Balutoiu (ibalutoiu@cloudbasesolutions.com) [September 2015]
|
||||
Nova: Ionut Balutoiu (ibalutoiu@cloudbasesolutions.com) [September 2015]
|
||||
# Foundation profile: 20081
|
||||
Compute: Ryan Moe (rmoe@mirantis.com) [September 2015]
|
||||
Nova: Ryan Moe (rmoe@mirantis.com) [September 2015]
|
||||
# Foundation profile: 13294
|
||||
Compute: Lucas Alvares Gomes (lucasagomes@gmail.com) [September 2015]
|
||||
Nova: Lucas Alvares Gomes (lucasagomes@gmail.com) [September 2015]
|
||||
# Primary author in: openstack/cinder, openstack/ironic, openstack/python-ironicclient, openstack/nova
|
||||
Compute: Navneet Kumar (navneetk@thoughtworks.com) [September 2015]
|
||||
Nova: Navneet Kumar (navneetk@thoughtworks.com) [September 2015]
|
||||
# Primary author in: openstack/nova
|
||||
Compute: Zsolt Dudas (zdudas@cloudbasesolutions.com) [September 2015]
|
||||
Nova: Zsolt Dudas (zdudas@cloudbasesolutions.com) [September 2015]
|
||||
# Foundation profile: 14692 or 16553 (both same employer referenced)
|
||||
Compute: Anuj Mathur (anujm@thoughtworks.com) [September 2015]
|
||||
Nova: Anuj Mathur (anujm@thoughtworks.com) [September 2015]
|
||||
# Foundation profile: 9221
|
||||
Compute: Chenchong Qin (qinchenchong@gmail.com) [September 2015]
|
||||
Nova: Chenchong Qin (qinchenchong@gmail.com) [September 2015]
|
||||
# Primary author in: openstack/zaqar
|
||||
Compute: Thomas Kaergel (kaergel@b1-systems.de) [September 2015]
|
||||
Nova: Thomas Kaergel (kaergel@b1-systems.de) [September 2015]
|
||||
# Foundation profile: 19424
|
||||
Compute: Ryo Kurahashi (kurahashi-rxa@necst.nec.co.jp) [September 2015]
|
||||
Nova: Ryo Kurahashi (kurahashi-rxa@necst.nec.co.jp) [September 2015]
|
||||
# Primary author in: openstack/ironic
|
||||
Compute: Adam Gandelman (adamg@ubuntu.com) [September 2015]
|
||||
Nova: Adam Gandelman (adamg@ubuntu.com) [September 2015]
|
||||
# Primary author in: openstack/ironic, openstack/python-ironicclient
|
||||
Compute: Andres Buraschi (andres.buraschi@intel.com) [September 2015]
|
||||
Nova: Andres Buraschi (andres.buraschi@intel.com) [September 2015]
|
||||
# Primary author in: openstack/python-neutronclient, openstack/horizon
|
||||
Compute: Claxton Correya (claxton@gmail.com) [September 2015]
|
||||
Nova: Claxton Correya (claxton@gmail.com) [September 2015]
|
||||
# Primary author in: openstack/nova
|
||||
|
||||
Documentation: Beth Cohen (beth.cohen@verizon.com) [September 2015]
|
||||
|
|
|
@ -8,8 +8,8 @@ Reference documents which need to be revised over time.
|
|||
:maxdepth: 2
|
||||
|
||||
charter
|
||||
new-programs-requirements
|
||||
incubation-integration-requirements
|
||||
new-projects-requirements
|
||||
project-testing-interface
|
||||
tags/index
|
||||
Template for new tags <tag-template>
|
||||
Requirements for previously-used incubation/integration process <incubation-integration-requirements>
|
||||
|
|
|
@ -1,28 +0,0 @@
|
|||
======================================================
|
||||
Minimal Requirements for New Programs Applications
|
||||
======================================================
|
||||
|
||||
Teams in OpenStack can be created as-needed and grow organically. As the team
|
||||
work matures, some technical efforts will be recognized as essential to the
|
||||
completion of the OpenStack project mission. By becoming an official Program,
|
||||
they place themselves under the authority of the OpenStack Technical
|
||||
Committee. In return, their contributors get to vote in the Technical
|
||||
Committee election, and they get some space and time to discuss future
|
||||
development at our Design Summits. When considering new programs, the TC will
|
||||
look into a number of criteria, including (but not limited to):
|
||||
|
||||
- Scope
|
||||
|
||||
- Team must have a specific scope, distinct from others teams scope
|
||||
- Team must have a mission statement
|
||||
|
||||
- Maturity
|
||||
|
||||
- Team must already exist, have regular meetings and produce some work
|
||||
- Team should have a lead, selected by the team contributors
|
||||
- Team should have a clear way to grant ATC (voting) status to its
|
||||
significant contributors
|
||||
|
||||
- Deliverables
|
||||
|
||||
- Team should have a number of clear deliverables
|
|
@ -0,0 +1,53 @@
|
|||
======================================================
|
||||
Requirements for new OpenStack Projects applications
|
||||
======================================================
|
||||
|
||||
Teams in OpenStack can be created as-needed and grow organically. As the team
|
||||
work matures, some technical efforts will be recognized as being part of the
|
||||
OpenStack community. By becoming an official OpenStack Project, they place
|
||||
themselves under the authority of the OpenStack Technical Committee. In return,
|
||||
their contributors get to vote in the Technical Committee election.
|
||||
|
||||
When considering new projects for addition, the TC will check that:
|
||||
|
||||
* The project aligns with the OpenStack Mission:
|
||||
The project must have a clear and defined scope. It should help further
|
||||
the OpenStack mission, by providing a cloud infrastructure service, or
|
||||
directly building on an existing OpenStack infrastructure service.
|
||||
|
||||
* The project follows the OpenStack way ("the 4 opens"):
|
||||
|
||||
* Open Source:
|
||||
|
||||
* The proposed project uses an open source license (preferably the Apache
|
||||
v2.0 license, since it is necessary if the project wants to be used in
|
||||
an OpenStack trademark program)
|
||||
* Project must have no library dependencies which effectively restrict
|
||||
how the project may be distributed or deployed
|
||||
|
||||
* Open Community:
|
||||
|
||||
* The leadership is chosen by the contributors to the project
|
||||
* The project has regular meetings on IRC and those meetings are logged
|
||||
|
||||
* Open Development:
|
||||
|
||||
* The project uses public code reviews on the OpenStack infrastructure
|
||||
* The project has core reviewers and adopts a test-driven gate for changes
|
||||
* The project provides liaisons that serve as contacts for the work of
|
||||
cross-project teams in OpenStack
|
||||
* Where it makes sense, the project cooperates with existing projects
|
||||
rather than gratuitously competing or reinventing the wheel
|
||||
* Project should use oslo libraries or oslo-incubator where appropriate
|
||||
|
||||
* Open Design:
|
||||
|
||||
* The project direction is discussed at the Design Summit and/or on
|
||||
public forums
|
||||
* The project uses the openstack-dev ML to discuss issues
|
||||
|
||||
* The project ensures basic interoperability with the rest of OpenStack:
|
||||
User-facing API services should support Keystone for discovery and
|
||||
authentication.
|
||||
|
||||
* The project should have an active team of contributors
|
|
@ -1,5 +1,4 @@
|
|||
Compute:
|
||||
codename: Nova
|
||||
Nova:
|
||||
ptl: Michael Still (mikal)
|
||||
mission: >
|
||||
To implement services and associated libraries to provide massively
|
||||
|
@ -14,8 +13,7 @@ Compute:
|
|||
- repo: openstack/python-novaclient
|
||||
- repo: openstack/nova-specs
|
||||
|
||||
Object Storage:
|
||||
codename: Swift
|
||||
Swift:
|
||||
ptl: John Dickinson (notmyname)
|
||||
url: https://wiki.openstack.org/wiki/Swift
|
||||
projects:
|
||||
|
@ -27,8 +25,7 @@ Object Storage:
|
|||
- repo: openstack/swift-bench
|
||||
- repo: openstack/swift-specs
|
||||
|
||||
Image Service:
|
||||
codename: Glance
|
||||
Glance:
|
||||
ptl: Nikhil Komawar (nikhil_k)
|
||||
mission: >
|
||||
To provide a service where users can upload and discover data assets that
|
||||
|
@ -44,8 +41,7 @@ Image Service:
|
|||
- repo: openstack/python-glanceclient
|
||||
- repo: openstack/glance_store
|
||||
|
||||
Identity:
|
||||
codename: Keystone
|
||||
Keystone:
|
||||
ptl: Morgain Fainberg (morgainfainberg)
|
||||
mission: >
|
||||
To facilitate API client authentication, service discovery, distributed
|
||||
|
@ -63,8 +59,7 @@ Identity:
|
|||
- repo: openstack/python-keystoneclient-kerberos
|
||||
- repo: openstack/python-keystoneclient-federation
|
||||
|
||||
Dashboard:
|
||||
codename: Horizon
|
||||
Horizon:
|
||||
ptl: David Lyle (david-lyle)
|
||||
mission: >
|
||||
To provide an extensible unified web based user interface for all
|
||||
|
@ -78,8 +73,7 @@ Dashboard:
|
|||
- repo: openstack/django_openstack_auth
|
||||
- repo: openstack/tuskar-ui
|
||||
|
||||
Networking:
|
||||
codename: Neutron
|
||||
Neutron:
|
||||
ptl: Kyle Mestery (mestery)
|
||||
mission: >
|
||||
To implement services and associated libraries to provide on-demand,
|
||||
|
@ -105,8 +99,7 @@ Networking:
|
|||
- repo: openstack/neutron-specs
|
||||
- repo: openstack/python-neutronclient
|
||||
|
||||
Block Storage:
|
||||
codename: Cinder
|
||||
Cinder:
|
||||
ptl: Mike Perez (thingee)
|
||||
mission: >
|
||||
To implement services and libraries to provide on-demand, self-service
|
||||
|
@ -121,8 +114,7 @@ Block Storage:
|
|||
- repo: openstack/cinder-specs
|
||||
- repo: openstack/python-cinderclient
|
||||
|
||||
Telemetry:
|
||||
codename: Ceilometer
|
||||
Ceilometer:
|
||||
ptl : Eoghan Glynn (eglynn)
|
||||
url: https://wiki.openstack.org/wiki/Ceilometer
|
||||
mission: >
|
||||
|
@ -132,7 +124,6 @@ Telemetry:
|
|||
criteria are met.
|
||||
projects:
|
||||
- repo: openstack/ceilometer
|
||||
incubated-since: grizzly
|
||||
tags:
|
||||
- name: integrated-release
|
||||
since: havana
|
||||
|
@ -140,13 +131,11 @@ Telemetry:
|
|||
- repo: openstack/python-ceilometerclient
|
||||
- repo: openstack/ceilometermiddleware
|
||||
|
||||
Orchestration:
|
||||
codename: Heat
|
||||
Heat:
|
||||
ptl: Angus Salkeld (asalkeld)
|
||||
url: https://wiki.openstack.org/wiki/Heat
|
||||
projects:
|
||||
- repo: openstack/heat
|
||||
incubated-since: grizzly
|
||||
tags:
|
||||
- name: integrated-release
|
||||
since: havana
|
||||
|
@ -157,8 +146,7 @@ Orchestration:
|
|||
- repo: openstack-dev/heat-cfnclient
|
||||
- repo: openstack/heat-translator
|
||||
|
||||
Database Service:
|
||||
codename: Trove
|
||||
Trove:
|
||||
ptl: Nikhil Manchanda (SlickNik)
|
||||
mission: >
|
||||
To provide scalable and reliable Cloud Database as a Service functionality
|
||||
|
@ -167,7 +155,6 @@ Database Service:
|
|||
url: https://wiki.openstack.org/wiki/Trove
|
||||
projects:
|
||||
- repo: openstack/trove
|
||||
incubated-since: havana
|
||||
tags:
|
||||
- name: integrated-release
|
||||
since: icehouse
|
||||
|
@ -175,8 +162,7 @@ Database Service:
|
|||
- repo: openstack/trove-integration
|
||||
- repo: openstack/trove-specs
|
||||
|
||||
Bare metal:
|
||||
codename: Ironic
|
||||
Ironic:
|
||||
ptl: Devananda van der Veen (devananda)
|
||||
mission: >
|
||||
To produce an OpenStack service and associated python libraries capable of
|
||||
|
@ -185,7 +171,6 @@ Bare metal:
|
|||
url: https://wiki.openstack.org/wiki/Ironic
|
||||
projects:
|
||||
- repo: openstack/ironic
|
||||
incubated-since: havana
|
||||
tags:
|
||||
- name: integrated-release
|
||||
since: kilo
|
||||
|
@ -193,8 +178,7 @@ Bare metal:
|
|||
- repo: openstack/python-ironicclient
|
||||
- repo: openstack/ironic-python-agent
|
||||
|
||||
Common Libraries:
|
||||
codename: Oslo
|
||||
Oslo:
|
||||
ptl: Doug Hellmann (dhellmann)
|
||||
mission: >
|
||||
To produce a set of python libraries containing code shared by OpenStack
|
||||
|
@ -231,7 +215,6 @@ Common Libraries:
|
|||
- repo: openstack-dev/pbr
|
||||
|
||||
Infrastructure:
|
||||
codename: Infra
|
||||
ptl: James E. Blair (jeblair)
|
||||
url: https://wiki.openstack.org/wiki/Infrastructure
|
||||
mission: >
|
||||
|
@ -313,7 +296,6 @@ Documentation:
|
|||
- repo: openstack/volume-api
|
||||
|
||||
Quality Assurance:
|
||||
codename: QA
|
||||
ptl: Matthew Treinish (mtreinish)
|
||||
mission: >
|
||||
Develop, maintain, and initiate tools and plans to ensure the upstream
|
||||
|
@ -328,8 +310,7 @@ Quality Assurance:
|
|||
- repo: openstack-dev/devstack
|
||||
- repo: openstack-dev/hacking
|
||||
|
||||
Deployment:
|
||||
codename: TripleO
|
||||
TripleO:
|
||||
ptl: Clint Byrum (SpamapS)
|
||||
mission: >
|
||||
Develop and maintain tooling and infrastructure able to deploy OpenStack in
|
||||
|
@ -363,8 +344,7 @@ Release cycle management:
|
|||
- repo: openstack/requirements
|
||||
- repo: openstack-infra/release-tools
|
||||
|
||||
Message service:
|
||||
codename: Zaqar
|
||||
Zaqar:
|
||||
ptl: Flavio Percoco (flaper87)
|
||||
mission: >
|
||||
To produce an OpenStack messaging service that affords a
|
||||
|
@ -374,12 +354,10 @@ Message service:
|
|||
url: https://wiki.openstack.org/wiki/Zaqar
|
||||
projects:
|
||||
- repo: openstack/zaqar
|
||||
incubated-since: icehouse
|
||||
- repo: openstack/zaqar-specs
|
||||
- repo: openstack/python-zaqarclient
|
||||
|
||||
Data processing service:
|
||||
codename: Sahara
|
||||
Sahara:
|
||||
ptl: Sergey Lukjanov (SergeyLukjanov)
|
||||
mission: >
|
||||
To provide a scalable data processing stack and associated management
|
||||
|
@ -387,7 +365,6 @@ Data processing service:
|
|||
url: https://wiki.openstack.org/wiki/Sahara
|
||||
projects:
|
||||
- repo: openstack/sahara
|
||||
incubated-since: icehouse
|
||||
tags:
|
||||
- name: integrated-release
|
||||
since: juno
|
||||
|
@ -397,8 +374,7 @@ Data processing service:
|
|||
- repo: openstack/sahara-image-elements
|
||||
- repo: openstack/sahara-specs
|
||||
|
||||
Key management service:
|
||||
codename: Barbican
|
||||
Barbican:
|
||||
ptl: Douglas Mendizabal (redrobot)
|
||||
mission: >
|
||||
To produce a secret storage and generation system capable of providing key
|
||||
|
@ -406,15 +382,13 @@ Key management service:
|
|||
url: https://wiki.openstack.org/wiki/Barbican
|
||||
projects:
|
||||
- repo: openstack/barbican
|
||||
incubated-since: juno
|
||||
- repo: openstack/barbican-specs
|
||||
- repo: openstack/castellan
|
||||
- repo: openstack/python-barbicanclient
|
||||
- repo: openstack/kite
|
||||
- repo: openstack/python-kiteclient
|
||||
|
||||
DNS Services:
|
||||
codename: Designate
|
||||
Designate:
|
||||
ptl: Kiall Mac Innes (kiall)
|
||||
mission: >
|
||||
To provide scalable, on demand, self service access to authoritative DNS
|
||||
|
@ -422,19 +396,16 @@ DNS Services:
|
|||
url: https://wiki.openstack.org/wiki/Designate
|
||||
projects:
|
||||
- repo: openstack/designate
|
||||
incubated-since: juno
|
||||
- repo: openstack/designate-specs
|
||||
- repo: openstack/python-designateclient
|
||||
|
||||
Shared File Systems:
|
||||
codename: Manila
|
||||
Manila:
|
||||
ptl: Ben Swartzlander (bswartz)
|
||||
mission: >
|
||||
To provide a set of services for management of shared file systems
|
||||
in a multitenant cloud environment, similar to how OpenStack provides
|
||||
for block-based storage management through the Block Storage program.
|
||||
for block-based storage management through the Cinder project.
|
||||
url: https://wiki.openstack.org/wiki/Manila
|
||||
projects:
|
||||
- repo: openstack/manila
|
||||
incubated-since: juno
|
||||
- repo: openstack/python-manilaclient
|
Loading…
Reference in New Issue