ansible musings...

[Xavier Lamien]

On Thu, Feb 21, 2013 at 11:25 PM, Kevin Fenzi <kevin at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130222/fa2b8c01/attachment.html>