> 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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
