hi there,
thanks for sharing this, I have a
On 04/03/2015 12:31 AM, Zane Bitter wrote:
A few of us have been looking for a way to perform software updates to
servers in a TripleO Heat/Puppet-based overcloud
[...]
Here's a trivial example of what this deployment might look like:
update_config:
type: OS::Heat::SoftwareConfig
properties:
config: {get_file: do_sw_update.sh}
inputs:
- name: update_after_time
description: Timestamp of the most recent update request
update_deployment:
type: OS::Heat::SoftwareDeployment
properties:
actions:
- UPDATE
config: {get_resource: update_config}
server: {get_resource: my_server}
input_values:
update_after_time: {get_param: update_timestamp}
[...]
heat stack-update my_overcloud -f $TMPL -P "update_timestamp=$(date)"
leaving the ResourceGroup/AutoScalingGroup to more knowledgeable people
on a side and trying instead to translate the templating approach into
user features, if I read it correctly this would also make it possible to:
1. perform a config update without a software update as long as the
update_timestamp param remains unchanged
2. perform software updates of each ResourceGroup independently from the
others by using as many update_timestamp params
3. use different update.sh scripts per ResourceGroup
are the above correct?
My single minor concern is about the update script itself which, if not
left for editing to the user but bundled instead with t-h-t , should be
clever enough to cope with different distros and distro versions because
we can't know that from the template ... but this can be achieved by
abstracting it on top of Puppet itself it seems (or whichever other
config management tool is deployed)
--
Giulio Fidente
GPG KEY: 08D733BA
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
