<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 11:25 PM, Kevin Fenzi <span dir="ltr"><<a href="mailto:kevin@scrye.com" target="_blank">kevin@scrye.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Greetings.<br>
<br>
The upstream ansible folks have been discussing a 'best practices' doc<br>
at:<br>
<a href="https://github.com/ansible/ansible/blob/devel/docsite/rst/bestpractices.rst" target="_blank">https://github.com/ansible/ansible/blob/devel/docsite/rst/bestpractices.rst</a><br>
<br>
and I have been pondering how we want to setup things on our ansible<br>
instance before we add a bunch more things to it.<br>
<br>
So, some outstanding questions for comment/discussion:<br>
<br>
a) I think I like the idea of splitting out per role trees for things.<br>
But we need to decide what level of granularity a 'role' is.<br>
<br>
For example, mirrormanager in puppet is a single module.<br>
However, it's really:<br>
<br>
mirrormanager proxy setup files<br>
mirrormanager mirrorlist server web app<br>
mirrormanager web app (the admin part)<br>
mirrormanager backend scripts (crawler, creating lists, etc)<br>
<br>
So, for our purposes should we have mirrormanager all in the same<br>
'role' tree? or should we split it out by functionality?<br></blockquote><div><br></div><div style>like it too, the 'role' tree. it'd be more productive to go to one place to deal with related stuff.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Many roles won't have this issue, as they will be simpler.<br>
<br>
b) What would be the workflow for staging with ansible?<br>
Ie, I want to make some config changes only in staging and iron them<br>
out and then merge them back to production when ready. Do we copy the<br>
role and modify? Do we require only changing vars and seperate files?<br></blockquote><div><br></div><div style>How about a dedicated branch for staging where we can merge it into master when ready (just like puppet's)</div>
<div style>Also, I think git flow coud be a good candidate here to work on a specific 'role' or such.</div><div style>ie, you have staging branch in sync with master, you git flow config start mm_proxy_update, do your cooking, then</div>
<div style>publish your mm_proxy_update branch, then ansible it for testing. If everything went well, you merge your branch into staging/master</div><div style>depending of the purpose.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Will be thinking on it more, but input welcome.<br>
<span class="HOEnZb"><font color="#888888"><br>
kevin<br>
</font></span><br>_______________________________________________<br>
infrastructure mailing list<br>
<a href="mailto:infrastructure@lists.fedoraproject.org">infrastructure@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/infrastructure" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/infrastructure</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>
Xavier.t Lamien<br>--<br><a href="http://fedoraproject.org/wiki/XavierLamien">http://fedoraproject.org/wiki/XavierLamien</a><br>GPG-Key ID: F3903DEB<br>Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB
</div></div>