Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>