[openstack-dev] [heat] Rolling upgrades vs. duplication of prop data
Rabi Mishra
ramishra at redhat.com
Fri Jan 6 04:56:43 UTC 2017
On Thu, Jan 5, 2017 at 10:28 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 05/01/17 11:41, Crag Wolfe wrote:
>
>> Hi,
>>
>> I have a patch[1] to support the de-duplication of resource properties
>> data between events and resources. In the ideal rolling-upgrade world,
>> we would be writing data to the old and new db locations, only reading
>> from the old in the first release (let's assume Ocata). The problem is
>> that in this particular case, we would be duplicating a lot of data, so
>> [1] for now does not take that approach. I.e., it is not rolling-upgrade
>> friendly.
>>
>> So, we need to decide what to do for Ocata:
>>
>> A. Support assert:supports-upgrade[2] and resign ourselves to writing
>> duplicated resource prop. data through Pike (following the standard
>> strategy of write to old/new and read from old, write to old/new and
>> read from new, write/read from new over O,P,Q).
>>
>> B. Push assert:supports-upgrade back until Pike, and avoid writing
>> resource prop. data in multiple locations in Ocata.
>>
>
> +1
>
> Rabi mentioned that we don't yet have tests in place to claim the tag in
> Ocata anyway, so I vote for making it easy on ourselves until we have to.
> Anything that involves shifting stuff between tables like this inevitably
> gets pretty gnarly.
>
>
Yeah, as per governance requirements to claim the tag we would need gate
tests to validate that mixed-version services work together properly[1]. We
would probably need a multi-node grenade job running services of n-1/n
releases.
I could not find one for any other project to refer to, though there are
few projects that already have this tag.
[1]
https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html#requirements
C. DB triggers.
>
> -2! -2!
>
>
> I vote for B. I'm pretty sure there is not much support for C (count me
>> in that group :), but throwing it out there just in case.
>>
>> Thanks,
>>
>> --Crag
>>
>> [1] https://review.openstack.org/#/c/363415/
>>
>> [2] https://review.openstack.org/#/c/407989/
>>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170106/1639000d/attachment.html>
More information about the OpenStack-dev
mailing list