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