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.
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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
