<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Darragh - thanks for sharing your thoughts. We look forward to working with you!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On 1 February 2016 at 14:20, Bailey, Darragh <span dir="ltr"><<a href="mailto:dbailey@hpe.com" target="_blank">dbailey@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
My initial thoughts are that the first 2 places to focus for alignment<br>
(assuming people agree with the idea of life cycle phases) would be:<br>
<br>
a) abstract the different life cycle phases we have for HLM to be<br>
controlled by a role var. (I'll elaborate more below)<br></blockquote><div><br></div><div>Agreed, this does seem to be a pattern which is forming within the Ansible community. The debate, as always, is what is considered to be the composable unit. In theory each role should do one thing and should be simple, but roles have an overhead attached to them so it's becoming useful to provide code paths within the role instead of separating each function/life cycle phase (eg: check-prerequisites, install, configure, upgrade, test) that can be activated as necessary. For me, this strikes a nice balance between a sprawling set of roles and an over-complex set of roles. It's easy to use and easy to understand.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
b) Move the current var access in the defaults.yml that has knowledge of<br>
config-processor output structure to be abstracted at the site level so<br>
you can use the same roles whether it's with data from the hlm config<br>
processor or another source (reusability is key). I guess could use<br>
wrapper roles, but I think that's less desirable except for handling<br>
edge cases or transition.<br></blockquote><div><br></div><div>Yes, this would be good. What also seems to be forming as a pattern within the community is a concept of internal vars (vars only for use within the role) and external vars (vars which may be overridden by group_vars, plays, CLI, etc). The internal vars are not subject to deprecation, whereas the external vars are as they effectively fall into something akin to an 'API contract'.</div><div><br></div><div>The same pattern should perhaps also be applied to playbooks - some should be part of the API contract, and some not.</div><div><br></div><div>I'd like us to get a discussion going around these patterns sooner rather than later, which the hope of completing them and setting them as a policy in place for the Newton cycle. Shall we arrange some sort of discussion at the OSA mid-cycle [1] to start this work? We have arranged for the possibility of remote participation if you can't make it to the UK for it.</div><div><br></div><div>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/085810.html">http://lists.openstack.org/pipermail/openstack-dev/2016-February/085810.html</a><br></div><div><br></div><div>Jesse</div><div>IRC: odyssey4me</div></div>
</div></div>