[Rdo-list] Configuration publishing, organisation of the repo

[Graeme Gillies]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
> 
> To unsubscribe: rdo-list-unsubscribe at 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