On Thu, Jan 5, 2017 at 10:28 PM, Zane Bitter <zbit...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Rabi Misra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
