Open Stack

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