On Thu, Feb 21, 2013 at 11:25 PM, Kevin Fenzi <kevin@scrye.com> wrote:
Greetings.

The upstream ansible folks have been discussing a 'best practices' doc
at:
https://github.com/ansible/ansible/blob/devel/docsite/rst/bestpractices.rst

and I have been pondering how we want to setup things on our ansible
instance before we add a bunch more things to it.

So, some outstanding questions for comment/discussion:

a) I think I like the idea of splitting out per role trees for things.
But we need to decide what level of granularity a 'role' is.

For example, mirrormanager in puppet is a single module.
However, it's really:

mirrormanager proxy setup files
mirrormanager mirrorlist server web app
mirrormanager web app (the admin part)
mirrormanager backend scripts (crawler, creating lists, etc)

So, for our purposes should we have mirrormanager all in the same
'role' tree? or should we split it out by functionality?

like it too, the 'role' tree. it'd be more productive to go to one place to deal with related stuff.
 

Many roles won't have this issue, as they will be simpler.

b) What would be the workflow for staging with ansible?
Ie, I want to make some config changes only in staging and iron them
out and then merge them back to production when ready. Do we copy the
role and modify? Do we require only changing vars and seperate files?

How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's)
Also, I think git flow coud be a good candidate here to work on a specific 'role' or such.
ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then
publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master
depending of the purpose.


Will be thinking on it more, but input welcome.

kevin

_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure



--
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB