OpenStack SIGs (Special Interest Groups) are teams within the community where we collaborate to bring unified discussions for all community members who share a common interest. As examples SIGs can be but are not limited to being a first stage in the development of new projects, feature requests, standards adoption, policy implementation, adjacent community work, and just general discussion(s). Here is the list of current SIGs:
|Status||SIG||Scope||ML prefix||Contact||Other resources|
|active||API||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.||[api]||Chris Dent, Ed Leafe, Michael McCune||Meeting |
|active||Scientific||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!||[scientific]||Blair Bethwaite, Stig Telfer, Martial Michel||Wiki, IRC meetings|
|active||FEMDC||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).||[femdc]||Adrien Lebre, Paul-André Raymond||Wiki, IRC meetings|
|forming||Ansible||Facilitate cross-project collaboration amongst Ansible-related OpenStack projects and efforts, and to provide a broader feedback loop between operators and users of Ansible in OpenStack clouds and developers of Ansible-related tools for deploying, operating, and managing services in OpenStack Clouds. The Ansible SIG also facilitates awareness of improvements, project timelines, or issues relating to OpenStack in the Ansible project community, and aspires to grow the collective pool of contributors across both open source projects.||[ansible]||Robyn Bergeron (rbergeron)|
|forming||K8s||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.||[k8s]||Chris Hoge (hogepodge)|
|forming||Public Cloud||...||[publiccloud]||Tobias Rydberg, Howard Huang, Sean Handley|
|forming||Longer support for releases||...||[lts]||tbd|
|active||Self healing SIG||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. The proposal to create the SIG is currently awaiting more feedback on the name and scope.||[self-healing]||Adam Spiers (aspiers)||Sydney Forum session|
|active||Meta||The 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.||[meta]||Melvin Hillsman (mrhillsman), Thierry Carrez (ttx)|
SIGs are not restricted in the methods and tools they use to communicate. We do however want to provide guidelines which may help those SIGs who need direction and/or assistance for onboarding.
In an effort to reduce the work on individuals writing and/or reading summaries for SIGs we are offering to follow a great tradition started for openstack-dev ML by having a bi-weekly summary sent out. In order to succeed here we have an etherpad - https://etherpad.openstack.org/p/openstack-sigs-weekly - which will be compiled bi-weekly and sent to the openstack-sigs ML and other relevant places. We ask that SIG leaders provide updates as they see fit to the etherpad; this is not a requirement.
IRC is the preferred method of communication as it aligns with historical and current OpenStack community best practices for simple messaging; 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 https://github.com/ekmartin/slack-irc for a Slack+IRC connector; a docker image is also available at https://github.com/mrhillsman/dockerize-slack-irc
Currently we have the OpenStack-SIGs mailing list which you can sign up for here: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs When using the mailing list, be sure to add the tag [topic] at the beginning of your subject line. An example of this can be found here: http://lists.openstack.org/pipermail/openstack-sigs/2017-July/000000.html ( the [Openstack-sigs] tag in the example is added by the Mailman software that drives OpenStack mailing lists )
Future potential SIGs
Contact: Luke Hinds
Currently a project team, the Security Team's focus is not the production of software, but more generally the improvement of the state of security in all aspects of OpenStack. As a SIG, it could potentially better gather all security-conscious people in all our community. Conversion under discussion at http://lists.openstack.org/pipermail/openstack-dev/2017-October/124053.html