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 <cl...@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) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev