Open Stack

Hi Kevin,


At the moment don't think I'll be able to make it, however a number of
my colleagues will be there, so definitely an opportunity.


Be happy to start the discussion here so anyone not attending can get an
idea of where things are going.


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)

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.


---

So what do I mean about the life cycle phases. As part of HLM, the idea
is to install and configure as much as possible across the entire cloud
and then perform the deploy/upgrade as a series of rolling service
starts/restarts at the same point. This differs from a normal
application of roles to nodes where the configure/install/start/restart
is done to each service on the node in sequence.

I'll leave debate of the pros/cons of each approach to another email. I
think the level of control is needed, and also roles should abstract the
information on how it is accomplished. Needing to know whether to
include a specific file from a role to perform a set of actions is
probably not desirable, seems to break the idea of abstraction behind
roles. Provide an interface and entry point with the main.yml, and try
not to care about it being implemented in a specific manner beyond this.

This is more about how we get from having plays that need to know which
file from each role to include to exact a specific phase in the life
cycle (install, configure, start, stop, upgrade, etc), to where if you
include the role by default it goes through all the needed phases, and
if you want to only enact a subset you set a role variable such as:

# play to just install/configure
  roles:
    - { role: myrole, run_mode: [install, configure] }

# play to start
  roles:
   - { role: myrole, run_mode: [start] }

... etc.


I think we already suggested this to the monasca project to facilitate
the separation of applying the lifecycles for HLM while the default
behaviour of just executing all the needed tasks by default to bring the
service up without needing to fork the code. See
https://github.com/hpcloud-mon/ansible-monasca-agent/blob/master/tasks/main.yml


I would modify it to allow a list of phases to be applied by default, so
that the checks could be:

- include: stop.yml
  when: 'Stop' in run_mode


Thoughts?


Regards,
Darragh Bailey
IRC: electrofelix
"Nothing is foolproof to a sufficiently talented fool" - Unknown

On 29/01/16 23:42, Kevin Carter wrote:
> Thanks Bailey for the update. I intend to look over more of what you 
> folks have published really soon. Thanks again for putting all of this 
> out there and I hope to work with you and the team soon on more of the 
> convergence pieces.
> 
> I don't know if you or any of your team are headed to the OPS and or 
> OpenStack-Ansible midcycles in February but I'll be there and would love 
> the opportunity to work with folks while we're all in person.
> 
> Thanks again for publishing and have a good weekend.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160201/db0587cc/attachment.pgp>