On 09/01/2016 09:45 AM, David Stanek wrote:
> On Thu, Aug 25 at 13:13 -0400, Steve Martinelli wrote:
>> The keystone team is pursuing a trigger-based approach to support rolling,
>> zero-downtime upgrades. The proposed operator experience is documented here:
>>
>> http://docs.openstack.org/developer/keystone/upgrading.html
>>
>
> I wanted to mention a few things. One of the reasons I suggested this
> approach for keystone is that I've had success in the past using a
> combination of triggers and code to do live, online migrations. Many
> times using completely different schemas.
>
> In keystone we are just talking about some simple data transformations
> between columns and things like that. The triggers themselves shouldn't
> get too complicated. If there are cases where triggers won't work, then
> we won't force them. (A current example of this is encrypting
> credentials.)
>
> The online migrations are not required. Operators can still go the old
> route and db_sync while others help test out the cutting edge features.
>
> The triggers are not there during the entire lifecycle of the
> application. The expand phase adds them and the contract removes them.
But you did that for an application where you were on call to handle any
issues, and you knew the data somewhat in advance.
In OpenStack this code would get committed. It would get executed 12 to
18 months later (the average current OpenStack level at the ops meetup
was Kilo/Liberty). It would be executed by people far away, possibly
running in different locales, without an idea about what's in the data set.
Part of OpenStack being a successful open source project is that the
mean expertise of our operators will keep decreasing over time. It will
be deployed and maintained by less and less skilled operators in each
release, because it will be deployed and maintained by more total
operators each release.
Putting DB trigger failure analysis into the toolkit required to manage
an upgrade failure is a really high bar for new ops.
-Sean
--
Sean Dague
http://dague.net
__________________________________________________________________________
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
