> This differs from Nova and Neutron's approaches to solve for rolling > upgrades (which use oslo.versionedobjects), however Keystone is one of > the few services that doesn't need to manage communication between > multiple releases of multiple service components talking over the > message bus (which is the original use case for oslo.versionedobjects, > and for which it is aptly suited). Keystone simply scales horizontally > and every node talks directly to the database.
Yeah, o.vo gives you nothing really if all you want is a facade behind which to hide the application-level migrations. That doesn't mean it would be a bad thing to use, but maybe overkill vs. just writing a couple wrappers. > Database triggers are obviously a new challenge for developers to write, > honestly challenging to debug (being side effects), and are made even > more difficult by having to hand write triggers for MySQL, PostgreSQL, > and SQLite independently (SQLAlchemy offers no assistance in this case), > as seen in this patch: > > https://review.openstack.org/#/c/355618/ > > However, implementing an application-layer solution with > oslo.versionedobjects is not an easy task either; refer to Neutron's > implementation: Yeah, it's not trivial at the application level either but at least it is in python and write-once for any kind of compatible backend. My (extremely limited) experience with stored procedures is that they are very difficult to get right, even as an expert in the technology, which almost none of us are. Application-level migrations are significantly simpler and exist closer to the domain of the rest of the code for a specific new feature. I will offer one bit of anecdotal information that may be relevant: Several of the migrations that nova has done in the past have required things like parsing/generating JSON, and making other API calls to look up information needed to translate from one format to another. That would (AFAIK) be quite difficult to do in the database itself, and may mean you end up with a combination of both approaches in the long run. I don't think that keystone necessarily needs to adopt the same approach as the other projects (especially in the absence of things like cross-version RPC compatibility) and so if stored procedures are really the best fit then that's cool. They will themselves be a landmine in front of me should I ever have to debug such a problem, but if they are significantly better for the most part then so be it. --Dan __________________________________________________________________________ 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
