I think we all agree that it makes sense to split Ansible roles in different repositories. What else do we have ? A good first step would be to try and do an inventory. I've started throwing together an etherpad [1] since the ML is probably not a good medium for this. It's not complete, I have to run for now but once we know what we have, perhaps it can give us a good perspective of how things should be organized. [1]: https://etherpad.openstack.org/p/rdo-inventory David Moreau Simard Senior Software Engineer | Openstack RDO dmsimard = [irc, github, twitter] On Sat, Mar 12, 2016 at 8:32 AM, Michael Scherer <mscherer(a)redhat.com&gt; wrote: > Hi, > > so we were planning to discuss the topic since a long time, but didn't > found the time until last week (after last cloud outage). > > So we made a meeting on how would it be the best to open the > infrastructure and decided to first start by a github org. > ( see https://github.com/rdo-infra ) > > Now, the hard question is "how do we organize it", which requires to > know what we have to organise. > > From my side, we have the ansible playbook I use to deploy > rdoproject.org. I do have a set of external role I reuse for others > projects (and would like to keep that way, since this make my job easier > for others projects) > > I know that David also use ansible for others stuff, and I am not sure > what else is missing (jenkins job builder file, more ?) > > Any opinions ? > (next question will be "how much repo and how do we split them") > -- > Michael Scherer > Sysadmin, Community Infrastructure and Platform, OSAS > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com

- rdobase make sense, but I still like to have stuff more split. See https://github.com/gluster/gluster.org_ansible_configuration/tree/master/... for what i use (I should also place one for ssh keys) and https://github.com/gluster/gluster.org_ansible_configuration/blob/master/...

- I would also like to discuss if we can pin dependencies (all or just part of them), either by tagging version, or using branch. I am not sure ansible-galaxy do support it now (or at least fully support what I want), but I am quite sure this is planned (as it was discussed during a meeting last month in London). So we should maybe investigate that model.

From looking at the documentation [2], it looks like it is possible to

Also, for various work reasons, I was also looking at transitioning my duty and part of the project (better now than later) to a new member of my team, as I do have some more urgent stuff to finish, and need to scale myself (so i figured that it would be better to do that in a project where he wouldn't be alone). I will give details later, and let Rich help for that. Of course, people can still ping me anyway but the idea is to have more than just me from the OSAS/sysadmin side.

On 12/03/16 23:32, Michael Scherer wrote: > Hi, > > so we were planning to discuss the topic since a long time, but didn't > found the time until last week (after last cloud outage). > > So we made a meeting on how would it be the best to open the > infrastructure and decided to first start by a github org. > ( see https://github.com/rdo-infra ) > > Now, the hard question is "how do we organize it", which requires to > know what we have to organise. > > From my side, we have the ansible playbook I use to deploy > rdoproject.org. I do have a set of external role I reuse for others > projects (and would like to keep that way, since this make my job easier > for others projects) > > I know that David also use ansible for others stuff, and I am not sure > what else is missing (jenkins job builder file, more ?) > > Any opinions ? > (next question will be "how much repo and how do we split them") > > > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com > Hi Michael, I'm very interested in this initiative, and moving forward I hope myself and my team (RHOS Operations) hope to play a bigger part in RDO Infrastructure management. Is there any reason we have created another github community rather than using redhat-openstack? It seems that we already have so many different github namespaces, keeping track of them all starts to become unwieldy. As always we should try and reuse ansible/puppet code/roles from their upstream location wherever possible. My team will be looking at building out and RDO installation for use by the RDO community (more information to be forthcoming), and our plan is to have a repos for the ansible playbooks we use for ad hoc system management and orchestration, as well as another git repo for the tripleo heat templates we use to deploy the cloud. I think for all the ansible work, having a central ansible repo with the inventory and playbooks for the environment make sense, with the roles themselves in other repos (either in our git space or from their original upstream location), pulled in via ansible galaxy (a requirements.yml which directly references the git locations of all the modules). What do you think? Regards, Graeme -- Graeme Gillies Principal Systems Administrator Openstack Infrastructure Red Hat Australia _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com