Update project doc to reflect OpenDev changes
This change effectively converts the OpenStack Infra project description into an OpenDev project description in our documentation. Since OpenDev is largely an evolution of the preexisting infra team much of the content remains the same. I have added a section on governance as we'll not be able to run off of the OpenStack governance any longer. Note this leaves what becomes the OpenStack Infra project without a project document. However, the remaining scope of that OpenStack project will be small and I don't think it will need to same level of team organization. I think we can get by with OpenStack's default governance for its teams there. Then should we need something more explicit or different we can write that up within openstack itself. Depends-On: https://review.opendev.org/#/c/703134/ Change-Id: I56aab771510768211386325e6466d2f94fe298fb
This commit is contained in:
parent
d0f59d19cc
commit
95e8c8edde
@ -1,37 +1,43 @@
|
||||
:title: Infrastructure Project
|
||||
:title: OpenDev Project
|
||||
|
||||
.. _infra-project:
|
||||
|
||||
Infrastructure Project
|
||||
######################
|
||||
OpenDev Project
|
||||
###############
|
||||
|
||||
The infrastructure for the OpenStack project itself is run with the
|
||||
same processes, tools and philosophy as any other OpenStack project.
|
||||
The infrastructure team is an open meritocracy that welcomes new
|
||||
members. You can read about the OpenStack way on the wiki:
|
||||
OpenDev is an evolution of the OpenStack Infrastructure project. The
|
||||
goal is to make OpenStack's proven software development tools available
|
||||
for projects outside of OpenStack. We believe that Free Software needs
|
||||
Free tools and OpenDev provides one such set that has been proven to
|
||||
work at large and small scales of development.
|
||||
|
||||
* https://wiki.openstack.org/wiki/How_To_Contribute
|
||||
* https://wiki.openstack.org/wiki/Open
|
||||
* https://wiki.openstack.org/wiki/Governance
|
||||
* https://wiki.openstack.org/wiki/Programs
|
||||
The OpenDev team is an open meritocracy that welcomes new members. We
|
||||
follow OpenStack's `Four Opens <https://www.openstack.org/four-opens/>`_.
|
||||
|
||||
Scope
|
||||
=====
|
||||
|
||||
The project infrastructure encompasses all of the systems that are
|
||||
used in the day to day operation of the OpenStack project as a whole.
|
||||
This includes development, testing, and collaboration tools. All of
|
||||
the software that we run is open source, and its configuration is
|
||||
public. The project still uses a number of systems that do not yet
|
||||
fall under this umbrella (notably, the main website), but we're
|
||||
working to incorporate them so that people may just as easily
|
||||
contribute to those areas. All new services used by the project
|
||||
should begin as part of the infrastructure project to ensure easy
|
||||
collaboration from the start.
|
||||
OpenDev now covers many of the original OpenStack Infrastructure systems,
|
||||
but not all. The goal is to run any service that has generic applicability
|
||||
for open and collaborative software development in OpenDev. OpenStack and
|
||||
other project specific tooling would be managed by those projects outside
|
||||
of OpenDev.
|
||||
|
||||
In particular OpenDev covers the operations and development of code
|
||||
management systems and collaboration tools. Git repository management, code
|
||||
review, continuous integration, etherpads, mailing lists, and more are all
|
||||
within the scope of OpenDev. All of the software we run is open source, and
|
||||
openly operated through configuration files stored in git.
|
||||
|
||||
Contributing
|
||||
============
|
||||
|
||||
.. note::
|
||||
|
||||
Until we complete the transition from OpenStack Infra to OpenDev some
|
||||
communication platforms will remain under "OpenStack". Expect
|
||||
this list to get smaller over time.
|
||||
|
||||
We welcome contributions from new contributors. Reading this
|
||||
documentation is the first step. You should also join our `mailing list <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra>`_.
|
||||
|
||||
@ -42,13 +48,6 @@ Feel free to attend our `weekly IRC meeting
|
||||
<https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting>`_
|
||||
on Tuesdays at 19:00 UTC in #openstack-meeting.
|
||||
|
||||
Check out our open bugs on `StoryBoard
|
||||
<https://storyboard.openstack.org/#!/project_group/55>`_.
|
||||
|
||||
We hold regular `bug days
|
||||
<https://wiki.openstack.org/wiki/InfraTeam#Bugs>`_ where we review and
|
||||
triage bugs.
|
||||
|
||||
To read about how our systems are managed and how to view or edit
|
||||
those configurations, see :ref:`sysadmin`.
|
||||
|
||||
@ -61,20 +60,19 @@ And if you have any questions, please ask.
|
||||
Bugs
|
||||
====
|
||||
|
||||
The infrastructure project maintains a bug list at::
|
||||
|
||||
https://storyboard.openstack.org/#!/project_group/55
|
||||
The OpenDev project maintains a bug list at:
|
||||
https://storyboard.openstack.org/#!/project_group/55
|
||||
|
||||
Both defects and new features are tracked in the bug system. A number
|
||||
of tags are used to indicate relevance to a particular subsystem.
|
||||
There is also a low-hanging-fruit tag associated with bugs that should
|
||||
provide a gentle introduction to working on the infrastructure project
|
||||
provide a gentle introduction to working on the OpenDev project
|
||||
without needing too much in-depth knowledge or access.
|
||||
|
||||
Priority Efforts
|
||||
================
|
||||
|
||||
The infrastructure project designates a small number of efforts
|
||||
The OpenDev project designates a small number of efforts
|
||||
underway at any time as priority efforts. These are areas where the
|
||||
project has decided to focus resources to achieve major initiatives.
|
||||
These help reviewers prioritize their review workload and help to
|
||||
@ -97,60 +95,91 @@ considerable time in review, but they will be reviewed eventually. If
|
||||
a change is urgent, you might consider contacting someone in
|
||||
#openstack-infra on Freenode.
|
||||
|
||||
Teams
|
||||
=====
|
||||
Governance
|
||||
==========
|
||||
|
||||
The infrastructure project is open, meaning anyone may join and begin
|
||||
The OpenDev project is governed by two entities. The first is the
|
||||
Service Coordinator. They coordinate work of contributors and act as
|
||||
a tie breaker when clear consensus isn't found. The Service Coordinator is
|
||||
responsible for managing spec reviews and core team membership (details
|
||||
below). This role is essentially the same as the old Infra PTL role.
|
||||
|
||||
The Service Coordinator is elected every 6 months. The nominee pool and
|
||||
electorate are individuals that have contributed changes to OpenDev git
|
||||
repositories in the last 12 months.
|
||||
|
||||
The second is an advisory board made up of representatives from OpenDev's
|
||||
user base of projects and organizations that contribute compute resources.
|
||||
This advisory board provides a formal location for those key
|
||||
stakeholders to express their needs to the OpenDev project.
|
||||
This creates a clear contact point for feedback on priorities and direction.
|
||||
Their input will help ensure that the OpenDev project is a good steward of
|
||||
the resources provided to it and that user needs are being addressed.
|
||||
|
||||
Contributing orgs and user projects are not required to join the advisory
|
||||
board, but are encouraged to do so. Individuals on the board would be
|
||||
selected by their own constituency as that constituency feels is
|
||||
appropriate.
|
||||
|
||||
The advisory board will also serve as a point of contact for the OpenDev
|
||||
project when making changes that may be disruptive. The intent is to create
|
||||
bidirectional communication between OpenDev and its constituent
|
||||
organizations.
|
||||
|
||||
Teams
|
||||
-----
|
||||
|
||||
The OpenDev project is open, meaning anyone may join and begin
|
||||
contributing with no formal process. As an individual's contributions
|
||||
and involvement grow, there are more formal roles. These roles are
|
||||
designed to empower groups of people to get work done in their area of
|
||||
expertise and interest, as well as supply a strong sense of direction
|
||||
for the infrastructure project as a whole. Everyone participating in
|
||||
for the OpenDev project as a whole. Everyone participating in
|
||||
the project is encouraged to expand their own knowledge while helping
|
||||
to support and mentor others as they progress.
|
||||
|
||||
Core Teams
|
||||
The infrastructure project is composed of a large number of
|
||||
The OpenDev project is composed of a large number of
|
||||
subprojects. Every source code repository has its own core team
|
||||
which is responsible for maintenance of that subproject, with some
|
||||
groups of repositories sharing a core team. These core teams are
|
||||
empowered to approve changes that reflect the currently understood
|
||||
project direction. Changes in project direction or major new
|
||||
initiatives must be approved by the infrastructure council.
|
||||
initiatives must be approved by the OpenDev council.
|
||||
|
||||
Any existing core team member may nominate someone for addition to
|
||||
that core team by private communication with the infrastructure PTL.
|
||||
The PTL will consider the opinions of the existing core team members
|
||||
and the review history of the person in question, but final
|
||||
determination of core team membership (additions and removals) rests
|
||||
with the PTL. This process is private to enable honest evaluations
|
||||
in a safe environment.
|
||||
that core team by private communication with the OpenDev Service
|
||||
Coordinator. The Service Coordinator will consider the opinions of the
|
||||
existing core team members and the review history of the person in
|
||||
question, but final determination of core team membership (additions and
|
||||
removals) rests with the Service Coordinator. This process is private to
|
||||
enable honest evaluations in a safe environment.
|
||||
|
||||
Infrastructure Core Team
|
||||
OpenDev Core Team
|
||||
Individuals who show an interest in a wide range of areas of the
|
||||
infrastructure project may be asked to join the infra-core team. To
|
||||
OpenDev project may be asked to join the infra-core team. To
|
||||
provide a baseline level of support to all of our subprojects and to
|
||||
ensure that important efforts may move forward, this team has
|
||||
approval rights in all infrastructure repositories. Members of this
|
||||
approval rights in all OpenDev repositories. Members of this
|
||||
team may not be experts in all areas, but know their limits, and
|
||||
will not exceed those limits when reviewing changes outside of their
|
||||
area of expertise.
|
||||
|
||||
They are expected to have a wide general knowledge of what is going
|
||||
on in the infrastructure project and to help guide overall project
|
||||
on in the OpenDev project and to help guide overall project
|
||||
direction. To that end, they are able to veto specs proposed to the
|
||||
infrastructure council.
|
||||
OpenDev council.
|
||||
|
||||
Infrastructure Council
|
||||
The infrastructure council is the technical design body for the
|
||||
infrastructure project. While individuals and groups are empowered
|
||||
OpenDev Council
|
||||
The OpenDev council is the technical design body for the
|
||||
Opendev project. While individuals and groups are empowered
|
||||
to execute the designs from the council, major technical designs are
|
||||
agreed upon as a group to ensure that our large set of projects are
|
||||
all working together to the same end. The council need not delve
|
||||
too deeply into technical detail -- just enough so that development
|
||||
efforts may happen in parallel and work toward a common goal.
|
||||
|
||||
All members of any infrastructure project core team have a seat on
|
||||
All members of any OpenDev project core team have a seat on
|
||||
the Council. The Council is responsible for approving changes in
|
||||
project direction, major new initiatives, setting priority efforts,
|
||||
and addition or removal of projects.
|
||||
@ -163,20 +192,20 @@ Infrastructure Council
|
||||
ready. Members of the council will vote by leaving reviews on the
|
||||
spec to approve or reject the change. The determination will be
|
||||
based on a majority vote, with members of the infra-core team able
|
||||
to veto, and in the case of a tie, the PTL will cast the deciding
|
||||
vote. The PTL will execute the workflow action on the change after
|
||||
the vote.
|
||||
to veto, and in the case of a tie, the Service Coordinator will cast
|
||||
the deciding vote. The Service Coordinator will execute the workflow
|
||||
action on the change after the vote.
|
||||
|
||||
Specs are living documents, and once approved, should be maintained
|
||||
for the duration of the effort they describe. Substantial changes
|
||||
in direction should go through the same process described above.
|
||||
The PTL may chose to approve insubstantial changes without the
|
||||
formal council voting process.
|
||||
The Service Coordinator may chose to approve insubstantial changes
|
||||
without the formal council voting process.
|
||||
|
||||
Infrastructure Root Team
|
||||
While core membership is analogous to the same system in other
|
||||
OpenStack projects, because the infrastructure team operates
|
||||
production servers there is another sub-group of the infrastructure
|
||||
OpenDev Root Team
|
||||
Core membership enables one to approve changes within our code
|
||||
repositories. Because the OpenDev team operates
|
||||
production servers there is another sub-group of the OpenDev
|
||||
team that has root access to all servers. Root membership is
|
||||
handled in the same way as core membership. Root members must also
|
||||
be infra-core members, but infra-core members may not necessarily be
|
||||
@ -184,15 +213,16 @@ Infrastructure Root Team
|
||||
performed through code review, so anyone able to log into a machine
|
||||
to execute commands must be able to approve those same commands in
|
||||
configuration management; otherwise it would be easier for a person
|
||||
to bypass puppet than use it in the intended fashion.
|
||||
to bypass configuration management than use it in the intended
|
||||
fashion.
|
||||
|
||||
Root access is generally only necessary to launch new servers,
|
||||
perform low-level maintenance, manage DNS, or fix problems. In
|
||||
general it is not needed for day-to-day system administration and
|
||||
configuration which is done in puppet (where anyone may propose
|
||||
changes). Therefore it is generally reserved for people who are
|
||||
well versed in infrastructure operations and can commit to spending
|
||||
a significant amount of time troubleshooting on servers.
|
||||
configuration which is done through automated config management tools
|
||||
(where anyone may propose changes). Therefore it is generally
|
||||
reserved for people who are well versed in OpenDev operations and can
|
||||
commit to spending a significant amount of time troubleshooting on servers.
|
||||
|
||||
Some individuals may need root access to individual servers; in
|
||||
these cases the infra-core group may grant root access on a limited
|
||||
|
Loading…
x
Reference in New Issue
Block a user