[openstack-dev] [Heat]Blueprint for retry function with idenpotency in Heat

Steve Baker sbaker at redhat.com
Thu Oct 17 23:13:45 UTC 2013


On 10/18/2013 01:54 AM, Mitsuru Kanabuchi wrote:
> Hello Mr. Clint,
>
> Thank you for your comment and prioritization.
> I'm glad to discuss you who feel same issue.
>
>> I took the liberty of targeting your blueprint at icehouse. If you don't
>> think it is likely to get done in icehouse, please raise that with us at
>> the weekly meeting if you can and we can remove it from the list.
> Basically, this blueprint is targeted IceHouse release.
>
> However, the schedule is depend on follows blueprint:
>   https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token
>
> We're going to start implementation to Heat after ClientToken implemented.
> I think ClientToken is necessary function for this blueprint, and important function for other callers!
Can there not be a default retry implementation which deletes any
ERRORed resource and attempts the operation again? Then specific
resources can switch to ClientToken as they become available.
> On Wed, 16 Oct 2013 23:32:22 -0700
> Clint Byrum <clint at fewbar.com> wrote:
>
>> Excerpts from Mitsuru Kanabuchi's message of 2013-10-16 04:47:08 -0700:
>>> Hi all,
>>>
>>> We proposed a blueprint that supports API retry function with idenpotency for Heat.
>>> Prease review the blueprint.
>>>
>>>   https://blueprints.launchpad.net/heat/+spec/support-retry-with-idempotency
>>>
>> This looks great. It addresses some of what I've struggled with while
>> thinking of how to handle the retry problem.
>>
>> I went ahead and linked bug #1160052 to the blueprint, as it is one that
>> I've been trying to get a solution for.
>>
>> I took the liberty of targeting your blueprint at icehouse. If you don't
>> think it is likely to get done in icehouse, please raise that with us at
>> the weekly meeting if you can and we can remove it from the list.
>>
>> Note that there is another related blueprint here:
>>
>> https://blueprints.launchpad.net/heat/+spec/retry-failed-update
>>
>>

Has any thought been given to where the policy should be specified for
how many retries to attempt?

Maybe sensible defaults should be defined in the python resources, and a
new resource attribute can allow an override in the template on a
per-resource basis (I'm referring to an attribute at the same level as
Type, Properties, Metadata)





More information about the OpenStack-dev mailing list