Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?
Darragh - thanks for sharing your thoughts. We look forward to working with you! On 1 February 2016 at 14:20, Bailey, Darragh 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 __ 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
Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?
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.
>
signature.asc
Description: OpenPGP digital signature
__
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
Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?
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. -- Kevin Carter IRC: Cloudnull On 01/29/2016 01:30 PM, Bailey, Darragh wrote: > Hi, > > > Those present at some of the Ansible collaboration sessions at Tokyo may > recall a mention about Helion Lifecycle Manager (HLM), which constituted > a collection of ansible playbooks and particular patterns used by the > HPE Helion OS 2.0 release to deploy clouds. > > We promised at the time that we'd get the code out there to start some > discussions on where we could collaborate better with openstack-ansible. > > I've already mentioned it to a few folks in IRC, however I think it's > worth sharing out a bit further. > > The initial code for the difference ansible components has been uploaded > to GitHub under https://github.com/hpe-helion-os earlier this month. > > > https://github.com/hpe-helion-os/helion-input-model > Defines a cloud though a combination of service input definitions > (relatively static) and a topology that controls how network and the > services are laid out control the shape and size of the cloud desired. > > > https://github.com/hpe-helion-os/helion-configuration-processor > The processing engine that consumes the desired cloud topology > configuration from the input model, and generates all the hosts and > variables that are consumed by the ansible playbooks/roles to deploy the > requested cloud. > > > https://github.com/hpe-helion-os/helion-ansible > Contains all the ansible playbooks/roles used to deploy HPE's HOS 2.0. > This is run against the output of the helion-configuration-processor to > execute the build/upgrade of the cloud specification. > > > Obviously lots of discussions to be had and work to be done, and > hopefully with some help we should have a good idea by Austin as to what > will be needed to integrate some of the concepts into the existing > openstack-ansible project. > > > Enjoy the weekend :-) > __ 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
[openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?
Hi, Those present at some of the Ansible collaboration sessions at Tokyo may recall a mention about Helion Lifecycle Manager (HLM), which constituted a collection of ansible playbooks and particular patterns used by the HPE Helion OS 2.0 release to deploy clouds. We promised at the time that we'd get the code out there to start some discussions on where we could collaborate better with openstack-ansible. I've already mentioned it to a few folks in IRC, however I think it's worth sharing out a bit further. The initial code for the difference ansible components has been uploaded to GitHub under https://github.com/hpe-helion-os earlier this month. https://github.com/hpe-helion-os/helion-input-model Defines a cloud though a combination of service input definitions (relatively static) and a topology that controls how network and the services are laid out control the shape and size of the cloud desired. https://github.com/hpe-helion-os/helion-configuration-processor The processing engine that consumes the desired cloud topology configuration from the input model, and generates all the hosts and variables that are consumed by the ansible playbooks/roles to deploy the requested cloud. https://github.com/hpe-helion-os/helion-ansible Contains all the ansible playbooks/roles used to deploy HPE's HOS 2.0. This is run against the output of the helion-configuration-processor to execute the build/upgrade of the cloud specification. Obviously lots of discussions to be had and work to be done, and hopefully with some help we should have a good idea by Austin as to what will be needed to integrate some of the concepts into the existing openstack-ansible project. Enjoy the weekend :-) -- Regards, Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" - Unknown signature.asc Description: OpenPGP digital signature __ 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
