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. -- David Stanek web: http://dstanek.com blog: http://traceback.org __________________________________________________________________________ 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
