[openstack-dev] [Heat] [TripleO] Rolling updates spec re-written. RFC

Robert Collins robertc at robertcollins.net
Wed Feb 5 01:24:40 UTC 2014


On 4 February 2014 08:51, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from Robert Collins's message of 2014-02-03 10:47:06 -0800:
>> Quick thoughts:
>>
>>  - I'd like to be able to express a minimum service percentage: e.g. I
>> know I need 80% of my capacity available at anyone time, so an
>> additional constraint to the unit counts, is to stay below 20% down at
>> a time (and this implies that if 20% have failed, either stop or spin
>> up more nodes before continuing).
>>
>
> Right will add that.

Thanks.

> One thing though, all failures lead to rollback. I put that in the
> 'Unresolved issues' section. Continuing a group operation with any
> failures is an entirely different change to Heat. We have a few choices,
> from a whole re-thinking of how we handle failures, to just a special
> type of resource group that tolerates failure percentages.

Lets tackle that in a future iteration - it seems orthogonal to me.

>> The wait condition stuff seems to be conflating in the 'graceful
>> operations' stuff we discussed briefly at the summit, which in my head
>> at least is an entirely different thing - it's per node rather than
>> per group. If done separately that might make each feature
>> substantially easier to reason about.
>
> Agreed. I think something more generic than an actual Heat wait condition
> would make more sense. Perhaps even returning all of the active scheduler
> tasks which the update must wait on would make sense. Then in the
> "graceful update" version we can just make the dynamically created wait
> conditions depend on the update pattern, which would have the same effect.

Its not clear to me what would be more generic than a heat wait condition ;).

> With the "maximum out of service" addition, we'll also need to make sure
> that upon the "must wait for these" things completing we evaluate state
> again before letting the update proceed.

How about - sketching:

Resources:
  NovaCompute0:
    Type: OS::Nova::Server
    Properties:
      action-readiness:
        handle: MyWaitConditionHandle
        notify-path: NovaCompute0Config.Metadata.heat-action
  NovaCompute0Config:
    Type: AWS::AutoScaling::LaunchConfiguration
...

Alternatively, have something in the NovaCompute0Config.Metadata
section that is identified as heats signal-to-us marker.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud



More information about the OpenStack-dev mailing list