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