OpenStack SIGs

The OpenStack SIGs (Special Interest Groups) are a form of working group in OpenStack that is an emanation of the community as a whole and is not directly tied to a specific governance body.

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.




API Chris Dent
Ed Leafe
Michael McCune

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.

Ansible Mohammed Naser
Kevin Carter

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.

Auto-scaling Rico Lin
Duc Truong
Zane Bitter

Auto-scaling SIG scope is to improve experience on develop, operate, and use autoscaling 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 features.

Bare Metal Chris Hoge

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.

Containers Jean-Philippe Evrard

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.

Extended Maintenance Tony Breeds

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.

FEMDC Adrien Lebre
Paul-Andre Raymond

The goal of the FEMDC SIG (formerly Fog/Edge/Massively Distributed Clouds Working Group) is to debate and investigate how OpenStack can address Fog/Edge Computing use-cases (i.e. the supervision and use of a large number of remote data centers through a collaborative distributed OpenStack system).

First Contact Kendall Nelson
Matt Oliver

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.

K8s Chris Hoge
David Lyle
Robert Morse

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.

Meta Amy Marrich
Rico Lin

A SIG for SIGs so to speak. A SIG to discuss OpenStack SIGs themselves, to encourage workgroups to become SIGs, accompany them along the way, give them tools and processes to be efficient. More generally, this SIG will discuss how to best close the loop between users and developers of OpenStack.

Operation Docs Chris Morgan
Sean McGinnis

The Operation Docs SIG is for those interested in operator guide documentation to make running OpenStack clouds easier and more efficient.

Public Cloud Tobias Rydberg
Howard Huang

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.

Resource Management Howard Huang
Chris Dent
Jay Pipes

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.

Scientific Blair Bethwaite
Stig Telfer
Martial Michel

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!

Security Gage Hugo

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.

Self-healing Adam Spiers
Eric Kao

Coordinate the use and development of several OpenStack projects which can be combined in various ways to manage OpenStack infrastructure in a policy-driven fashion, reacting to failures and other events by automatically healing and optimising services.

SIG communications


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.

Instant Messaging

IRC is the preferred method of communication as it aligns with historical and current OpenStack community best practices for simple messaging, and is also required for TC governed projects.

It is understood that for some IRC does not come with enough features by default and programming a bot to offer additional features is beyond some; skill or patience to create/maintain. If a SIG does decide to use an alternative to IRC, we ask that in keeping with the Four Opens, in particular Open Community, that you do so by ensuring meeting logs are stored/archived.


Free team accounts with Slack are not sufficient enough to meet archiving/storage of logs alone. A great alternative is to connect Slack with IRC and then follow the instructions for logging an IRC channel. Refer to for a Slack+IRC connector; a docker image is also available at

Process to create a SIG

To propose creation of a SIG, please propose a change to the sigs.yaml file in the openstack/governance-sigs repository. That change will be reviewed by members of the Meta SIG. If you have questions, please ask them on the openstack-discuss mailing-list with subject prefix [meta-sig].