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. C. DB triggers. 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
