> On 8/10/18, 3:20 AM, "Paul Belanger" <pabelan...@redhat.com> wrote:
>    This is basically what I do with roles i write, allow the user to decide 
> to step
>    over specific tasks. For example, I have created nodepool_task_manager 
> variable
>    with the following:
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/defaults/main.yaml#n16
> http://git.openstack.org/cgit/openstack/ansible-role-nodepool/tree/tasks/main.yaml
>    Been using it for a few years now, works much better then tags for me.  The
>    phases are pre, install, configure, service right now.

Hi folks,

I'm really happy that this conversation is happening. Thanks to Alex for 
raising it!

The task routing pattern is a reasonably good one, and is something which OSA 
is very likely to move towards in the future. Something else which I've always 
liked about the pattern used by the role's Paul has put together is that they 
clearly state the input expectation - for example, the role does not manage apt 
repositories, or implement any apt refreshes. This is the kind of thing that I 
think is going to be important - the role should be clear about what it does, 
clear about the inputs it expects, and the outputs of it. This will mean that 
the internals of the role can change, but those inputs are like an API - if you 
give the role that, it must always output the same result.

I can see it possibly being useful to include things like how to test the 
service in the service role, how to evaluate the health, how to enact an 
upgrade, how to enact a fast-forward upgrade, etc. But a good start initially 
would be to define some standards which inform the development of the roles.

Within OSA, for better or worse, we have a mix of role types - some are 
'utility', built for include_role usage. An example is 
http://git.openstack.org/cgit/openstack/ansible-role-systemd_service - give it 
the right vars, and it lays down the type of system service unit that you asked 
for in a standard way. We also make use of the 
http://git.openstack.org/cgit/openstack/ansible-config_template action plugin 
*everywhere* because it allows us not to be bothers with variables for every 
tunable under the sun - we only need variables for specific things that glue 
services together, or implement 'sensible defaults'.

We then have what I might call 'integration' roles - these are roles like 
http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova which does 
all things nova, and uses include_role to bring in various utility roles. We 
try to follow the idea that a single role operates on a single host, and try to 
avoid orchestration across multiple hosts inside a role, but it's not always 
that simple for it to be cut and dried and I'm starting to think we might want 
to change that, for upgrades especially. Laying down something like keystone or 
nova, with all the options like federation or the nova drivers, is a complex 
thing to do. Putting it all in one role makes the role hard to understand, but 
at least it's obvious where you go to find it.

I guess what I'm trying to get across is that trying to build commonly used 
roles is not going to be a simple process. All projects have very different 
styles, and very different ways of putting a service like nova down. However, 
we should start somewhere - break it down into a set of utility roles we'd like 
to see available, figure out the standards that matter for input/output and 
Ansible version support, figure out the release and branching strategy for 
them, get them done and move to using them and retire any previously 
implemented roles which duplicate their purpose, then target the next set.

I think it would be beneficial to get in a room at the PTG and figure out where 
we start, and agree on some standards. I'd like to see a strong facilitator for 
the session who can ensure that we keep things on topic and productive.

Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to