[openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

Jesse Pretorius jesse.pretorius at gmail.com
Mon Feb 8 11:52:03 UTC 2016


Darragh - thanks for sharing your thoughts. We look forward to working with
you!

On 1 February 2016 at 14:20, Bailey, Darragh <dbailey at hpe.com> wrote:

>
> My initial thoughts are that the first 2 places to focus for alignment
> (assuming people agree with the idea of life cycle phases) would be:
>
> a) abstract the different life cycle phases we have for HLM to be
> controlled by a role var. (I'll elaborate more below)
>

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.


> b) Move the current var access in the defaults.yml that has knowledge of
> config-processor output structure to be abstracted at the site level so
> you can use the same roles whether it's with data from the hlm config
> processor or another source (reusability is key). I guess could use
> wrapper roles, but I think that's less desirable except for handling
> edge cases or transition.
>

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'.

The same pattern should perhaps also be applied to playbooks - some should
be part of the API contract, and some not.

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.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-February/085810.html

Jesse
IRC: odyssey4me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160208/b8f8954e/attachment-0001.html>


More information about the OpenStack-dev mailing list