On Thu, Feb 21, 2013 at 11:25 PM, Kevin Fenzi <[email protected]> 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 > [email protected] > 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
_______________________________________________ infrastructure mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/infrastructure
