On 09/02/2016 01:53 PM, Doug Hellmann wrote:
Excerpts from Thierry Carrez's message of 2016-09-02 12:15:33 +0200:
Sean Dague wrote:
Putting DB trigger failure analysis into the toolkit required to manage
an upgrade failure is a really high bar for new ops.
I agree with Sean: increasing the variety of technologies used increases
the system complexity, which in turn requires more skills to fully
understand and maintain operationally. It should only be done as a last
resort, with pros and cons carefully weighted. We really should involve
operators in this discussion to get the full picture of arguments for
and against.
Yes, I would like to understand better what aspect of the approach
taken elsewhere is leading to the keystone team exploring other
options. So far I'm not seeing much upside to being different, and I'm
hearing a lot of cons.
I continue to maintain that the problems themselves being discussed at
https://review.openstack.org/#/c/331740/ are different than what has
been discussed in detail before. To be "not different", this spec
would need to no longer discuss the concept of "we need N to be reading
from and writing to the old column to be compatible with N-1 as shown in
the below diagram...Once all the N-1 services are upgraded, N services
should be moved out of compatibility mode to use the new column. ".
To my knowledge, there are no examples of code in Openstack that
straddles table and column changes directly in the SQL access layer as
this document describes. There's still a handful of folks including
myself that think this is a new kind of awkwardness we've not had to
deal with yet. My only ideas on how to reduce it is to put the N-1/N
differences on the write side, not the read side, and triggers are *not*
the only way to do it. But if "being different" means, "doing it on
the write side", then it seems like that overall concept is being
vetoed. Which I actually appreciate knowing up front before I spend a
lot of time on it.
Doug
__________________________________________________________________________
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
__________________________________________________________________________
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
