Open Stack

Robyn Bergeron wrote:
> [...]
> 1:  I've always wished for an obvious, official-ish space for
> Ansible-related information inside of OpenStack. There are a multitude
> of projects (openstack-ansible, kolla, ARA, potentially triple-o,
> openstack-infra, bifrost, zuul, etc.) making use of Ansible in
> OpenStack; plus openstack-related work in Ansible (modules) that are
> useful to point out to end-users, plus many operators and end-users with
> Ansible-y ways of deploying, maintaining, upgrading, managing,
> operating, and consuming OpenStack. There's never been a unified space
> in OpenStack with all the Ansible-related information or pointers an end
> user or operator might be searching for; there are plenty of places to
> land, and plenty of friendly folks willing to point people in the right
> direction, but a shorter, less potentially-confusing path would be awesome.
> 
> But it's never quite been a "needs an OpenStack project of its own" type
> of a problem. 
> 
> Having a source of "unopinionated," all-Ansible-related information
> inside of OpenStack that can be collectively maintained by OpenStack
> developers and users, that clearly states the various Ansible-y
> OpenStack projects, resources, and associated tools (modules, playbooks,
> etc.) for all potential users who may already have an affinity for
> Ansible would be (I believe, anyway) incredibly useful for that
> audience. And I think would be the minimum viable output I would hope
> for in a SIG effort; I think it would also be the logical doorway for
> finding new users and contributors to collaborate with and have better
> user/developer feedback loops around Ansible + OpenStack in general.
> Since communicating across that many groups can be daunting,
> particularly for new folks. 
> 
> 2: Given the number of projects with varying degrees of Ansible usage
> inside of OpenStack -- as well as a collection of folks hailing from
> many of those teams who together maintain the OpenStack modules in
> Ansible's community, and plenty of operators and end users using Ansible
> to deploy / manage / consume OpenStack clouds -- well, there are plenty
> of opportunities for collaboration across these groups. This is the
> place where having a SIG could be really really useful and productive.
> 
> * More coordinated collaboration around reusable Ansible components
> (roles, playbooks, etc.) for Ansible-y projects in OpenStack, as well as
> for end users (frequent OpenStack tasks, etc.)
> * Growing the base of contributors and expertise around the existing and
> future OpenStack modules in Ansible (and the underlying shade library).
> (This is a crew of a few folks right now -- 5 or 6 at most, most of whom
> already have plennnnnnnnnty to do.)
> * Have a general space (irc, mailing list, whatever is most appropriate)
> where developers and operators / end users can ask a broad pool of
> Ansible/OpenStack knowledgeable folks questions -- and know that it's
> the most welcoming space for those questions (vs. -devel and
> cross-posting to 6 or seven groups, or not all devel folks being on the
> operators' list, etc.). Also an opportunity to help everyone build best
> practices knowledge.
> * While I know that at some point in the future, the -infra discussion
> around "starting to test certain types changes to Ansible itself inside
> of OpenStack-infra / Zuul" (3rd party dependency type things) may become
> a reality -- having a unified space to discuss those changes, and/or
> wishes that would help OpenStack in general, would be useful. 

+1 -- I finally took the time to read your email and I don't see any
reason why we should not have an Ansible SIG.

I like that it has potential to serve as a convenient information point
for users, a funnel for our requirements back to upstream, a
collaboration venue for the various openstack teams using Ansible as a
technology, and generally make it even easier to bridge the two
communities (although they are already pretty close). It transcends the
barriers between cloud users, ops and devs, which is why the SIG concept
applies well to it.

> [...] 
> All that said -- we have, in Ansible, *also* introduced a similar
> concept -- albeit called "working groups" in Ansible-land. Ansible,
> being a younger project, has less governance, and (while yes,
> bikeshedding exists, including around "what does a working group do" and
> requirements) thus for us, right now, having a Working Group consists of:
> 
> * Request a working group by providing the name, names of at least 2
> folks wanting to participate, and the description of what you're doing,
> which gets you wiki space, an IRC channel + a bot, and a landing page in
> the ansible/community repo on github.)
> * Fill out the wiki with any additional information (what you're working
> on, if/when you have meetings and if there's an agenda, any ideas or
> goals) so folks can find it and participate. (And referring folks to the
> Working Group space in the appropriate developer or user documentation
> if necessary.)

In terms of process, we are currently pretty close to the process you
describe: basically define a scope for the group, a [prefix] to use on
the SIG ML, contact point(s), IRC channel and run with it. We are
currently collating information on
https://wiki.openstack.org/wiki/OpenStack_SIGs (though once the content
settles we'll likely move that to a git-driven website to add a layer of
peer-review of proposed changes).

> [...]
> Sorry for the long mail (I am only semi-famous for this) -- but thought
> having some of this might help the folks taking the lead in
> meta-sig-land have a concrete example in mind of what someone might want
> to do. :)

It helps, thanks!

-- 
Thierry Carrez (ttx)