kgess-mirror/openstack-governance
1
0
Fork 0
mirror of https://opendev.org/openstack/governance.git synced 2026-01-16 23:00:30 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge "Merge governance-sigs repository into governance"

Browse source
This commit is contained in:
Zuul 2025-11-17 19:41:44 +00:00 • committed by Gerrit Code Review
commit 1555895eac
12 changed files with 971 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

137
doc/source/_exts/sigtable.py Normal file
View file

@ -0,0 +1,137 @@
#!/usr/bin/env python
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
"""Build a table of the current teams"""
import yaml
from docutils import nodes
from docutils.parsers.rst import directives
from docutils.parsers.rst.directives.tables import Table
from sphinx.util import logging
LOG = logging.getLogger(__name__)
class SIGTable(Table):
"""Insert the members table using the referenced file as source.
"""
HEADERS = ('Name', 'Status', 'Chairs', 'Scope')
WIDTHS = [15, 15, 40, 80]
option_spec = {'class': directives.class_option,
'name': directives.unchanged,
'datafile': directives.unchanged,
}
def run(self):
env = self.state.document.settings.env
# The required argument to the directive is the name of the
# file to parse.
datafile = self.options.get('datafile')
if not datafile:
error = self.state_machine.reporter.error(
'No filename in sigtable directive',
nodes.literal_block(self.block_text, self.block_text),
line=self.lineno)
return [error]
# Now find the real path to the file, relative to where we are.
rel_filename, filename = env.relfn2path(datafile)
LOG.info('loading sigtable')
LOG.info('reading %s' % filename)
with open(filename, 'r') as f:
_teams_yaml = yaml.safe_load(f.read())
table = nodes.table()
# Set up the column specifications
# based on the widths.
tgroup = nodes.tgroup(cols=len(self.HEADERS))
table += tgroup
tgroup.extend(nodes.colspec(colwidth=col_width)
for col_width in self.WIDTHS)
# Set the headers
thead = nodes.thead()
tgroup += thead
row_node = nodes.row()
thead += row_node
row_node.extend(
nodes.entry(h, nodes.paragraph(text=h))
for h in self.HEADERS
)
# The body of the table is made up of rows.
# Each row contains a series of entries,
# and each entry contains a paragraph of text.
tbody = nodes.tbody()
tgroup += tbody
rows = []
all_teams = _teams_yaml
if not all_teams:
return []
for team in sorted(all_teams.keys()):
trow = nodes.row()
# Iterate over the headers in the same order every time.
for h in self.HEADERS:
if h.lower() == "name":
cell = "<a href=\"%s\">%s</a>" % (all_teams[team]['url'],
team)
entry = nodes.entry()
para = nodes.raw('', cell, format='html')
elif h.lower() == "status":
s = all_teams[team]['status'].lower()
cell = ('<a href="https://governance.openstack.org/sigs/'
'reference/sig-guideline.html#%s">%s</a>'
) % (s, s)
entry = nodes.entry()
para = nodes.raw('', cell, format='html')
elif h.lower() == "chairs":
chairs = []
for chair in all_teams[team]['chairs']:
chairs.append("%s (%s, <br /> %s) <br /> <br />" % (chair['name'], chair['irc'], chair['email']))
cell = "".join(chairs)
entry = nodes.entry()
para = nodes.raw('', cell, format='html')
else:
# Get the cell value from the row data, replacing None
# in re match group with empty string.
cell = all_teams[team][h.lower()] or ''
entry = nodes.entry()
para = nodes.paragraph(text=str(cell))
entry += para
trow += entry
rows.append(trow)
tbody.extend(rows)
# Build the table node
table['classes'] += self.options.get('class', [])
self.add_name(table)
return [table]
class RetiredSIGTable(SIGTable):
HEADERS = ('Name', 'Status', 'Chairs', 'Scope', 'Reason')
WIDTHS = [15, 15, 40, 60, 60]
def setup(app):
app.add_directive('sigtable', SIGTable)
app.add_directive('retired-sigtable', RetiredSIGTable)

1
doc/source/conf.py
View file

@ -40,6 +40,7 @@ extensions = [
'teams',
'badges',
'page_context',
'sigtable',
]
todo_include_todos = True

2
doc/source/index.rst
View file

@ -72,7 +72,7 @@ exceptions are listed in the :doc:`reference/house-rules` document.
.. _`Open Infrastructue Foundation bylaws`: http://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
.. _`Special Interest Groups (SIGs)`: https://governance.openstack.org/sigs/
.. _`Special Interest Groups (SIGs)`: reference/sigs/index.html
.. _`current proposals tracker`: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

4
reference/index.rst
View file

@ -11,8 +11,9 @@ Reference documents which need to be revised over time.
principles
charter
projects/index
distributed-project-leadership
sigs/index
popup-teams
distributed-project-leadership
technical-vision
upstream-investment-opportunities/index
role-of-the-tc
@ -32,7 +33,6 @@ Reference documents which need to be revised over time.
house-rules
comparison-of-official-group-structures
working-groups
Special Interest Groups <https://governance.openstack.org/sigs/>
sig-repos
tc-guide
OpenStack-name-in-external-services

2
reference/sigs-repos.yaml
View file

@ -49,8 +49,6 @@ i18n:
Large Scale:
- repo: openstack/large-scale
Meta:
- repo: openstack/governance-sigs
Multi-Arch:
- repo: openstack/multi-arch-sig
Operation Docs and Tooling:

36
reference/sigs/archived-sigs.yaml Normal file
View file

@ -0,0 +1,36 @@
---
# All SIGs here have not yet completed their mission but are considered
# retired. You can propose to resume these SIGs if you think the SIG's goal
# is still valid and you have someone willing to chair the SIG.
Containers:
chairs:
- name: Jean-Philippe Evrard
irc: evrardjp
email: jean-philippe@evrard.me
scope: >
The scope of the Containers SIG is to share practices for the
build, deploy, and operate of OpenStack using application
containers. This is not another deployment tool of containers.
Instead, this SIG should have as members people from the
different projects in the business of dealing with OpenStack
in application containers. The participants should be
interested in container building, willing to share their
practices, and/or define common practices for use within
all OpenStack projects. One example of the deliverables of
the SIG would be a common series of "rules" for the bindep
files relevant for container image building. These rules
would then be applied consistenty across all the OpenStack
projects, but also maintained over time by this group.
Another example of common ground would be sharing how
deployment projects are writing their container "check
probes", and figure out what can be re-used. In other words,
defining together what are application containers "readiness"
and "aliveness" for each service project.
status: archived
reason: >
There's currently no one available to drive Containers SIG and this SIG's
previous status is still forming and no repository associated.
Mailing List notification for retirement discussion can be found in
http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021297.html
url: https://etherpad.openstack.org/p/containers-sig

41
reference/sigs/completed-sigs.yaml Normal file
View file

@ -0,0 +1,41 @@
---
# All SIGs here have completed their mission and are considered retired.
Upgrade:
chairs:
- name: James Page
irc: jamespage
email: james.page@canonical.com
- name: Lujin Luo
irc: lujinluo
email: luo.lujin@jp.fujitsu.com
scope: >
The objective of the Upgrade SIG is to improve the overall upgrade
process for OpenStack Clouds, covering both offline 'fast-forward'
upgrades and online 'rolling' upgrades, by providing a forum for
cross-project collaboration between operators and developers to
document and codify best practice for upgrading OpenStack.
status: completed
reason: >
OpenStack is considered valid for both offline 'fast-forward' upgrades and
online 'rolling' upgrades. Therefore, we consider mission for Upgrade SIG
is completed.
url: https://wiki.openstack.org/wiki/Upgrade_SIG
Technical Writing:
chairs:
- name: Stephen Finucane
irc: stephenfin
email: sfinucan@redhat.com
scope: >
The technical writing SIG provides guidance, assistance, tooling, and style
guides enabling OpenStack project teams to produce consistent, accurate,
and high-quality documentation.
url: https://wiki.openstack.org/wiki/Documentation
status: completed
reason: >
The technical writing SIG has provided the guidelines and tooling to move
the documentation ownership to the projects. Now we have significantly less
amount of work under this SIG and having fewer or maintainer for this SIG
in the Yoga cycle, we decided to merge this SIG into the Technical Committee.
Contact OpenStack Technical Committee for any query related to this SIG.

51
reference/sigs/index.rst Normal file
View file

@ -0,0 +1,51 @@
================
OpenStack SIGs
================
The OpenStack SIGs (Special Interest Groups) are a form of
working group in OpenStack that is not directly responsible for
producing a part of the OpenStack software release. As such, they
do not require the same level of accountability that project teams
do.
SIGs are a good match for an activity that centers around a topic
or practice that spans all the community (developers, operators,
end users...), by forming a guild of people with a shared interest.
SIGs can own code repositories and produce software (independently
of the OpenStack software release itself). Contributions to a SIG
grant voting rights for the Technical Committee elections, in the
same way contributing to an OpenStack project team does.
.. sigtable::
:datafile: sigs.yaml
.. toctree::
:hidden:
tact-sig
.. toctree::
:maxdepth: 4
sig-guideline
Retired SIGs
============
Archived SIGs
-------------
These SIGs are retired but have not yet completed their mission.
.. retired-sigtable::
:datafile: archived-sigs.yaml
Completed SIGs
--------------
These SIGs are retired and have completed their mission.
.. retired-sigtable::
:datafile: completed-sigs.yaml

273
reference/sigs/sig-guideline.rst Normal file
View file

@ -0,0 +1,273 @@
=======================================================
Guidelines for OpenStack SIGs (Special Interest Groups)
=======================================================
Before we dive into more details, it is important to learn what a SIG is and
what the differences are to other work groups in OpenStack. Please check
`Comparison of Official Group Structures`_ for more detail.
SIGs lifecycle
==============
Before creating a SIG
---------------------
Before creating a SIG, you should check out the existing `SIGs`_ and see if
your goals could not be shared with an existing group.
If not, you should raise a thread on the openstack-discuss mailing-list about
creating a new SIG. That should allow you to raise visibility of the SIG,
get more feedback, refine the SIG scope, and recruit more volunteers.
Creating a SIG
--------------
To formally propose a SIG you'll need to propose a change to the
`SIG Governance`_ file. That change will be reviewed and approved by the
`OpenStack Technical Committee`_.
The change should include the chosen name for the SIG (a combination of
ASCII letters, `-` and space), the proposed SIG scope, the initial status
(usually "forming") and the name of the SIG chair(s). It's strongly
encouraged to have more than one chair in order to spread the load.
Particular attention should be paid to the SIG scope. Documenting down the
very reason for this SIG will help others who have similar interests to join
this group. It's important to learn why we need to form a SIG, where we need
this SIG, and what's the goal and responsibility of this SIG.
Here is an `example of a SIG creation request`_.
Keeping SIG status up to date
-----------------------------
Once the SIG is approved, it is important to keep its filing in
`SIG Governance`_ up to date. In particular, keeping the status, chairs,
and scope up to date.
SIG status may be:
forming
~~~~~~~
The SIG is still setting up. This status also applied to SIG which needs to
regroup.
active
~~~~~~
The SIG reaches out for discussion, have plans for current
cycle, host meetings or send messages about status out to the mailing-list
regularly.
advisory
~~~~~~~~
The SIG is not actively meeting or driving specific goals every cycle. SIG
members stay around for help, make sure everything stays working and
provide advice when needed.
The SIG will keep the owned repository or documents up to date and will accept
updates on-demand.
unknown
~~~~~~~
SIG status is unknown, the TC is currently working to update its status.
completed
~~~~~~~~~
This SIG's mission is considered completed and the SIG itself is retired.
archived
~~~~~~~~
This SIG is considered retired but didn't complete its mission.
Retiring a SIG
--------------
Inactive SIGs can be made "advisory" if SIG members are still available for
answering questions, or they can be retired.
Before retiring
~~~~~~~~~~~~~~~
Before considering to retire a SIG, you need to first provide discussion
in community to make sure it's common agreement to retire it. This should at
least include a mailing list. You can also consider to host an offical meeting
to make sure opinions are received and noted.
The next step is to take care of SIG resources. You need to make sure resources
maintained by this SIG can find new maintainer group. Resources mean
documentation, etherpads, Wiki pages, repositories, etc. Make sure these
resources can be found even after SIG is retired.
For repositories, you can consider to retire them (see
`Repository retirement`_ process) or move it under other group's maintenance.
For resources which are no longer needed (resources like IRC channels, meeting
schedule, etc.), you need to delete them at this stage.
Retire a mission completed SIG
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To retire a SIG which is considered mission completed. You need to propose a
change that moves its definition from `SIG Governance`_ to the
`Completed SIGs`_ file, changes the `status` field to `completed`, and changes
the `reason` field to provide explanation why the SIG is considered completed
and where we can found documentations or references (if any).
Retire an archived SIG
~~~~~~~~~~~~~~~~~~~~~~
Be careful when you consider retiring a SIG which didn't finish its mission.
You need to make sure discussions are made with clear agreement on retiring the
SIG, and resources are well maintained (See `Before retiring`_).
To retire a SIG which didn't finish it's mission, You need to propose a
change that moves its definition from `SIG Governance`_ to the
`Archived SIGs`_ file, changes the `status` field to `archived`, and changes
the `reason` field to provide proper explanation why we archive the SIG as not
completed and where we can find documentations or references (if any).
Best practices for running a SIG
================================
SIG chairs role
---------------
A chair is encouraged as a moderator for the following work:
* Organize meeting agenda and host meetings
* Organize polling
* Coordinate with SIG members to generate a schedule for possible upcoming
events (Summit, PTG, etc.) if needed.
* Moderate SIG tasks and help to find and encourage action takers for each
task.
* Welcome new members to join the SIG.
SIG communications
------------------
Due to SIG differences, each SIG might have its own way to communicate. The
only requirement is that the SIG communications are well documented, so that
interested parties can easily join. Here are a few suggestions:
Mailing List
~~~~~~~~~~~~
Asynchronous communication between SIG members happens on the
`OpenStack-discuss mailing-list`_, prefixing the subject with [$signame-sig]
where $signame matches the SIG’s name. SIG work output can, of course, be
posted to other mailing-lists as needed to reach other groups.
IRC
~~~
IRC is the preferred method of communication as it aligns with OpenStack
community best practices for inclusive, synchronous messaging.
If your SIG uses a specific IRC channel, Opendev provides a number of IRC bots
to assist with logging. You can read more about `IRC services`_ and see an
`example for adding status/meeting bot to channel`_.
IRC meetings
~~~~~~~~~~~~
If you run regular SIG meetings, you should consider to post the meeting
schedule for SIG. SIG members can decide the meeting schedule (frequency
and location) and make sure there will be moderator for each meeting.
Here's an `example for adding meeting schedule`_ to `meeting list`_.
.. note::
Meeting location can be at SIG's IRC channel or other public places if
more desired (Like K8s SIG uses Slack channel in K8s community for
meeting). Make sure meeting location allows public access so everyone can
join.
Post SIG news regularly
~~~~~~~~~~~~~~~~~~~~~~~
It's encouraged to provide updates for all who might be interested in
learning. This can be done through the mailing list, or instant messaging
channels. Keeping everyone informed of the SIG progress helps to attract new
members, and to make sure others know about the new changes.
Attend events
~~~~~~~~~~~~~
We encourage every SIG to participate to the Summit and PTG events if possible.
SIGs can have:
* PTG rooms for SIG in-person group discussions
* Forum sessions to get wider community feedback on issues within the SIG
scope.
* Speaking slots are reserved for SIG update presentations at Summits. This
is a great way to spread the word about a SIG and recruit new members.
SIG resources
-------------
Git repositories
~~~~~~~~~~~~~~~~
While SIGs do not produce software that is included in the regular OpenStack
release, SIGs can own git repositories, for example for documentation or add-on
software.
You can read more about `how to create a new git repository`_. In particular,
you will need to register this new repository in the `sigs-repos.yaml`_ file
(like in this `example for register a repository under SIG`_),
`add Gerrit permission`_ and `ask Infra team to create core team`_ for
Gerrit.
Doc repository
~~~~~~~~~~~~~~
A classic use case for a git repository in a SIG is to publish peer-reviewed
documentation. Using `Sphinx`_ and `Zuul jobs`_ it is easy to publish
documentation under `docs.openstack.org`_.
A good example of such a repository is `openstack/auto-scaling-sig`_, which
includes `Sphinx`_ configuration and `Zuul jobs`_ to publish the
`Auto-scaling SIG docs`_.
StoryBoard task tracker
~~~~~~~~~~~~~~~~~~~~~~~
If you use a git repository, you can use `StoryBoard`_ to track tasks in the
SIG. Adding `use_storyboard: true` to the repository definition in
`gerrit/projects.yaml`_ will automatically generate a corresponding project
in StoryBoard. Here is an `example for add config in gerrit/projects`_.
.. _Comparison of Official Group Structures: https://governance.openstack.org/tc/reference/comparison-of-official-group-structures.html
.. _SIGs: https://governance.openstack.org/sigs/
.. _SIG Governance: https://opendev.org/openstack/governance/src/branch/master/reference/sigs/sigs.yaml
.. _OpenStack Technical Committee: https://governance.openstack.org/tc/
.. _example of a SIG creation request: https://review.opendev.org/#/c/632252/
.. _OpenStack-discuss mailing-list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
.. _Repository retirement: ` https://docs.openstack.org/project-team-guide/repository.html#retiring-a-repository
.. _Completed SIGs: https://opendev.org/openstack/governance/src/branch/master/reference/sigs/completed-sigs.yaml
.. _Archived SIGs: https://opendev.org/openstack/governance/src/branch/master/reference/sigs/archived-sigs.yaml
.. _IRC services: https://docs.openstack.org/infra/system-config/irc.html
.. _example for adding status/meeting bot to channel: https://review.opendev.org/#/c/656796
.. _example for adding meeting schedule: https://review.opendev.org/#/c/656810/
.. _meeting list: http://eavesdrop.openstack.org/
.. _how to create a new git repository: https://docs.openstack.org/infra/manual/creators.html
.. _sigs-repos.yaml: https://opendev.org/openstack/governance/src/branch/master/reference/sigs-repos.yaml
.. _example for register a repository under SIG: https://review.opendev.org/#/c/637126
.. _add Gerrit permission: https://docs.openstack.org/infra/manual/creators.html#add-gerrit-permissions
.. _ask Infra team to create core team: https://docs.openstack.org/infra/manual/creators.html#update-the-gerrit-group-members
.. _Sphinx: https://www.sphinx-doc.org/
.. _Zuul jobs: https://zuul-ci.org/docs/zuul/index.html
.. _docs.openstack.org: https://docs.openstack.org/
.. _openstack/auto-scaling-sig: https://opendev.org/openstack/auto-scaling-sig/
.. _Auto-scaling SIG docs: https://docs.openstack.org/auto-scaling-sig/
.. _StoryBoard: https://storyboard.openstack.org/
.. _gerrit/projects.yaml: https://github.com/openstack/project-config/blob/master/gerrit/projects.yaml
.. _example for add config in gerrit/projects: https://review.opendev.org/#/c/637125/7/gerrit/projects.yaml

347
reference/sigs/sigs.yaml Normal file
View file

@ -0,0 +1,347 @@
---
Ansible:
chairs:
- name: Sagi Shnaidman
irc: sshnaidm
email: sshnaidm@redhat.com
- name: Kevin Carter
irc: cloudnull
email: kecarter@redhat.com
scope: >
Ansible is an orchestration tool that is becoming increasingly common
in usage across many parts of OpenStack. There are a few deployment
projects that are using it, alongside many of our CI systems. This
SIG exists to help create a colloborative space between different
interested parties to share Ansible code under one group.
It is also responsible of the OpenStack namespace on Ansible's galaxy.
status: active
url: https://wiki.openstack.org/wiki/Ansible_SIG
API:
chairs:
- name: Dmitry Tantsur
irc: dtantsur
email: dtantsur@protonmail.com
- name: Michael McCune
irc: elmiko
email: msm@redhat.com
scope: >
Formerly known as the API-WG, the API SIG scope is to improve the developer
experience of API users by converging the OpenStack API to a consistent and
pragmatic RESTful design. The working group creates guidelines that all
OpenStack projects should follow for new development, and promotes
convergence of new APIs and future versions of existing APIs.
status: advisory
url: https://wiki.openstack.org/wiki/API_SIG
Automation:
chairs:
- name: Rico Lin
irc: ricolin
email: ricolin@ricolky.com
scope: >
Automation SIG scope is to improve experience on develop, operate, and use
all automation (includes auto-scaling and self-healing) and its related
features (like metering, cluster schedule, life cycle management) and to
coordinate across projects and communities (like k8s cluster autoscaling
on OpenStack). Also provide a central place to put tests, documentations,
and even common libraries for auto-scaling and self-healing features.
status: advisory
url: https://etherpad.openstack.org/p/Automation
Bare Metal:
chairs:
- name: Arne Wiebalck
irc: arne_wiebalck
email: arne.wiebalck@cern.ch
- name: Dmitry Tantsur
irc: dtantsur
email: dtantsur@protonmail.com
scope: >
The scope of the Bare Metal Sig is to promote the development and use
of Ironic and other OpenStack bare metal software. This will include
marketing efforts like case studies of Ironic clusters in industry
and academia, supporting integration of Ironic with projects like
Airship and the Kubernetes Cluster API, coordinating presentations
for industry events, developing documentation and tutorials,
gathering feedback from the community on usage and feature gaps, and
other broader community-facing efforts to encourage the adoption of
Ironic as a bare-metal management tool.
status: active
url: https://etherpad.openstack.org/p/bare-metal-sig
Cloud Research:
chairs:
- name: Mohamed Elsakhawy
irc: melsakhawy
email: m2elsakha@gmail.com
scope: >
The Cloud Research SIG aims to bridge the gap between Academic
Research in Cloud Computing and Technology projects within OpenStack.
The group's purpose is to establish a collaboration space for Cloud
researchers to discuss advancements in Cloud research and methodologies
and to implement them in OpenStack. The group is also a communication
space for researchers looking for guidance on how to evaluate their
research work ( e.g., placement algorithms, model-free frameworks...etc.)
in Openstack.
status: active
url: https://etherpad.opendev.org/p/cloud-research-sig
Edge Computing:
chairs:
- name: Ildiko Vancsa
irc: ildikov
email: ildiko@openstack.org
- name: Gergely Csatari
irc: csatari
email: gergely.csatari@nokia.com
scope: >
The Edge Computing group is a OSF-level special interest group focused
on defining infrastructure systems needed to support applications
distributed over a broad geographic area, with potentially thousands of
sites, located as close as possible to discrete data sources, physical
elements or end users.
status: active
url: https://wiki.openstack.org/wiki/Edge_Computing_Group
Stable Maintenance:
chairs:
- name: Elõd Illés
irc: elod
email: elod.illes@est.tech
scope: >
Defining, enforcing and accompanying project teams in the application
of a common stable branch policy. Keeping CI working on stable branches.
Creating and improving related tooling and automation.
status: advisory
url: https://docs.openstack.org/project-team-guide/stable-branches.html
First Contact:
chairs:
- name: Kendall Nelson
irc: diablo_rojo
email: knelson@openstack.org
- name: Matt Oliver
irc: mattoliverau
email: matt@oliver.net.au
scope: >
To provide a place for new contributors to come for information and advice.
This group will also analyze and document successful contribution models
while seeking out and providing information to new members of the community.
status: active
url: https://wiki.openstack.org/wiki/First_Contact_SIG
Hardware Vendor:
chairs:
- name: Sean McGinnis
irc: smcginnis
email: sean.mcginnis@gmail.com
- name: Jay Bryant
irc: jungleboyj
email: jsbryant@electronicjungle.net
scope: >
The goals of this SIG are to provide a place where vendors, and those
interested in vendor specific things like drivers and supporting libs,
can work together and collaborate openly to enable OpenStack services to
integrate and work well on all hardware platforms.
status: active
url: https://wiki.openstack.org/wiki/Hardware_Vendor_SIG
i18n:
chairs:
- name: Ian Y. Choi
irc: ianychoi
email: ianyrchoi@gmail.com
scope: >
To make OpenStack ubiquitously accessible to people of
all language backgrounds.
status: active
url: https://wiki.openstack.org/wiki/I18nTeam
K8s:
chairs:
- name: Feilong Wang
irc: flwang
email: feilong@catalyst.net.nz
- name: Kendall Nelson
irc: diablo_rojo
email: kennelson11@gmail.com
scope: >
Community-local counterpart to the k8s-sig-openstack group, focused on
cross community communication and collaboration. Where k8s-sig-openstack
spends a good deal of time managing upstream provider code, sig-k8s
would likewise be focused on code to support and enable K8s deployments
within the OpenStack community. This SIG is directly intertwined with
k8s-sig-openstack within the Kubernetes community, with the same sig
leadership and meetings.
status: advisory
url: https://github.com/kubernetes/cloud-provider-openstack/blob/master/README.md
Large Scale:
chairs:
- name: Belmiro Moreira
irc: belmoreira
email: belmiro.moreira@cern.ch
- name: Pengju Jiao
irc: jiaopengju
email: jiaopengju@cmss.chinamobile.com
- name: Thierry Carrez
irc: ttx
email: thierry@openstack.org
scope: >
The aim of the group is to facilitate running OpenStack at large scale,
and help address some of the limitations operators encounter in large
OpenStack clusters.
status: active
url: https://wiki.openstack.org/wiki/Large_Scale_SIG
Multi-Arch:
chairs:
- name: Rico Lin
irc: ricolin
email: ricolin@ricolky.com
- name: Seongsoo Cho
irc: seongsoocho
email: ppiyakk2@printf.kr
scope: >
This SIG tracks and encourages efforts towards better support for OpenStack
on CPU architectures other than x86_64. This includes providing documents,
building test jobs, tracking issues, and building ecosystem for multiple
architectures.
status: active
url: https://etherpad.openstack.org/p/Multi-arch
Operation Docs and Tooling:
chairs:
- name: Chris Morgan
irc: mihalis68
email: mihalis68@gmail.com
- name: Sean McGinnis
irc: smcginnis
email: sean.mcginnis@gmail.com
scope: >
The Operation Docs and Tooling SIG is for those interested in operator
guide documentation and tools, scripts, and other code to make running
OpenStack clouds easier and more efficient.
status: active
url: https://wiki.openstack.org/wiki/Operation_Docs_SIG
Packaging:
chairs:
- name: Javier Peña
irc: jpena
email: jpena@redhat.com
- name: Dirk Mueller
irc: dirk
email: dirk@dmllr.de
scope: >
To make OpenStack easier to update and consume by operators and
provide tooling to package all OpenStack projects directly for
(at first) all RPM based distributions.
status: active
url: https://wiki.openstack.org/wiki/Rpm-packaging
PowerVMStacker:
chairs:
- name: Ramakrishnan Ramasubbu
irc: SriRamaSan
email: RR00462393@techmahindra.com
- name: Anurag Mahanto
irc: anuragmahanto67
email: Anurag.Mahanto@TechMahindra.com
scope: >
The scope of the PowerVMStacker is to provide OpenStack support for the
POWER CPU architecture on the PowerVM hypervisor.
This enables support of Linux, AIX and IBM i for PowerVM systems.
There are currently three supported components of the PowerVM driver -
nova-powervm – Support for Nova use cases.
ceilometer-powervm – Gathers instance/VM statistics.
networking-powervm – An optional Neutron ML2 agent that supports PowerVM
Shared Ethernet Adapters (SEAs). Users should utilize this if their environment
requires Shared Ethernet. However, they may also use the standard Open vSwitch
agent from the Neutron project to support advanced functions such as Security Groups,
Quality of Service (QoS), overlay networks (VXLANs) and more.
status: active
url: https://wiki.openstack.org/wiki/PowerVM
Public Cloud:
chairs:
- name: Tobias Rydberg
irc: tobberydberg
email: tobias.rydberg@citynetwork.eu
- name: Howard Huang
irc: zhipeng
email: huangzhipeng@huawei.com
scope: >
The aim of this sig is to represent the interests of the OpenStack
public cloud provider community, and to further adoption of OpenStack
public cloud usage.
status: advisory
url: https://wiki.openstack.org/wiki/PublicCloudSIG
Resource Management:
chairs:
- name: Howard Huang
irc: zhipeng
email: huangzhipeng@huawei.com
scope: >
The Resource Management SIG provides a gathering of similar interested
parties and establish an official channel cross different communities,
such as Kubernetes (Resource Management WG), Apache Mesos, Open Compute
Project and so forth, to focus on alignment of resource management
related functionalities.
status: forming
url: https://wiki.openstack.org/wiki/Res_Mgmt_SIG
Scientific:
chairs:
- name: Blair Bethwaite
irc: b1airo
email: blair.bethwaite@gmail.com
- name: Stig Telfer
irc: oneswig
email: stig.openstack@telfer.org
- name: Martial Michel
irc: martial_
email: martialmichel@datamachines.io
scope: >
The Scientific SIG (formerly Scientific Working Group) is dedicated to
representing and advancing the use-cases and needs of research and
high-performance computing atop OpenStack. It's also a great forum for
cross-institutional collaboration. If you are (or would like to) run
OpenStack to support researchers/scientists/academics and/or HPC/HTC,
then please join!
status: active
url: https://wiki.openstack.org/wiki/Scientific_SIG
Security:
chairs:
- name: Jeremy Stanley
irc: fungi
email: fungi@yuggoth.org
- name: Jay Faulkner
irc: JayF
email: jay@jvf.cc
scope: >
The Security SIG (formerly Security Project) responsibilities include
aiming to improve overall security of the various OpenStack projects,
maintaining the list of security notices in OpenStack, and ensuring
that security incidents are handled in a coordinated fashion. This
involves maintaining the OSSN (OpenStack Security Notes) and OSSA
(OpenStack Security Advisories), which are primarily handled under
the OpenStack Vulnerability Managment Team (VMT), a more
autonomous subgroup of the Security SIG.
status: active
url: https://wiki.openstack.org/wiki/Security-SIG
Testing and Collaboration Tools:
chairs:
- name: Jeremy Stanley
irc: fungi
email: fungi@yuggoth.org
scope: >
The Testing and Collaboration Tools (TaCT) SIG maintains, in cooperation
with the OpenDev project, the tooling and infrastructure needed to support
the development process and testing of the OpenStack project.
url: tact-sig.html
status: active

82
reference/sigs/tact-sig.rst Normal file
View file

@ -0,0 +1,82 @@
===============================================
OpenStack Testing and Collaboration Tools SIG
===============================================
The Testing and Collaboration Tools (TaCT) SIG maintains, in
cooperation with the OpenDev project, the tooling and infrastructure
needed to support the development process and testing of the
OpenStack project.
Contact
-------
* #openstack-infra channel on the OFTC IRC network
(`logs <http://eavesdrop.openstack.org/irclogs/%23openstack-infra/>`_)
* openstack-discuss@lists.openstack.org mailing list with ``[tact-sig]``
in the subject line
(`subscribe <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss>`_,
`archives <http://lists.openstack.org/pipermail/openstack-discuss/>`_)
Participants
------------
The TaCT SIG consists of many former Infra team collaborators:
people who review OpenStack job configuration changes, people who
dig into problems with test frameworks to unblock the integrated
gate queue, people who figure out strange Python packaging related
issues, people who help work out lapsed control of Launchpad admin
groups... also, the person selected by the TC to serve as
OpenStack's representative on the OpenDev Advisory Council is
expected to be heavily involved. Many of these activities are
closely related to work the Quality Assurance team is doing, so
folks who are active in QA participate in this SIG as well.
History
-------
The OpenStack Infrastructure team, and the CI team before it,
traditionally existed to care for the continuous integration and
collaboration infrastructure on which the OpenStack community
relies. With the rise of the `OpenDev Collaboratory
<https://opendev.org/>`_ as a distinct effort outside of (but still
primarily in service of) OpenStack, the majority of the team's
former systems administration activities were no longer occurring
under the authority of OpenStack. Most of the software and
configuration management repositories previously in the care of the
Infra team were also no longer official OpenStack deliverables, as
they became part of OpenDev as well (and their biggest development
effort, `Zuul+Nodepool <https://zuul-ci.org/>`_, was already spun
out as an independent Open Infrastructure Project even earlier
still).
With these responsibilities moved elsewhere, the existence of a
formal team was less of a necessity. What remained was a need to
support OpenStack's project-specific testing and collaboration
tooling and services, primarily job configuration and other things
which shouldn't currently be generalized into components of the
OpenDev Collaboratory. To this end, a Testing and Collaboration
Tools (TaCT) SIG was created to serve the role previously occupied
by the OpenStack Infrastructure team.
Naming
------
The choice to rename was, in large part, because the term
"infrastructure" perpetually confused newcomers to the community,
and the SIG's formation was an opportunity to use something less
overloaded.
OpenSearch
----------
This service collects CI job results in one place, so the developer
will be able to filter them by time or other criteria, see simple
visualization for most common errors etc.
To check the OpenSearch service, you need to login with credentials
that are described below:
* url: https://opensearch.logs.openstack.org/_dashboards/app/discover?security_tenant=global
* username: `openstack`
* password: `openstack`
* tenant: `global` (if prompted)

1
reference/technical-committee-repos.yaml
View file

@ -14,7 +14,6 @@ Technical Committee:
- repo: openstack/goal-tools
- repo: openstack/governance
- repo: openstack/governance-website
- repo: openstack/governance-sigs
- repo: openstack/ideas
- repo: openstack/openstack
- repo: openstack/openstack-manuals