On 08/31/2016 06:18 PM, Monty Taylor wrote:

I said this the other day in the IRC channel, and I'm going to say it
again here. I'm going to do it as bluntly as I can - please keeping in
mind that I respect all of the humans involved.

I think this is a monstrously terrible idea.

There are MANY reasons for this -but I'm going to limit myself to two.

OpenStack is One Project
========================

Nova and Neutron have an approach for this. It may or may not be ideal -
but it exists right now. While it can be satisfying to discount the
existing approach and write a new one, I do not believe that is in the
best interests of OpenStack as a whole. To diverge in _keystone_ - which
is one of the few projects that must exist in every OpenStack install -
when there exists an approach in the two other most commonly deployed
projects - is such a terrible example of the problems inherent in
Conway's Law that it makes me want to push up a proposal to dissolve all
of the individual project teams and merge all of the repos into a single
repo.

So that is fine. However, correct me if I'm wrong but you're proposing just that these projects migrate to also use a new service layer with oslo.versionedobjects, because IIUC Nova/Neutron's approach is dependent on that area of indirection being present. Otherwise, if you meant something like, "use an approach that's kind of like what Nova does w/ versionedobjects but without actually having to use versionedobjects", that still sounds like, "come up with a new idea".

I suppose if you're thinking more at the macro level, where "current approach" means "do whatever you have to on the app side", then your position is consistent, but I think there's still a lot of confusion in that area when the indirection of a versioned service layer is not present. It gets into the SQL nastiness I was discussing w/ Clint and I don't see anyone doing anything like that yet.

Triggers aside since it clearly is "triggering" (ahem) allergic reactions, what's the approach when new approaches are devised that are alternatives to what "exists right now"? E.g. I have yet another proposal in the works that allows for SQL-level translations but runs in the Python application space and does not use triggers. Should I stop right now because Nova/Neutron already have a system that's "good enough"? This would be fine. I find it uncomfortable working in this ambiguous space where some projects rightly proclaim they've solved a problem, and others continue to disregard that and plow forward with other approaches without a universally accepted reason why the current solution is not feasible.



BUT - I also don't think it's a good technical solution. That isn't
because triggers don't work in MySQL (they do) - but because we've spent
the last six years explicitly NOT writing raw SQL. We've chosen an
abstraction layer (SQLAlchemy) which does its job well.

There's a canard in there which is that all along I've been proposing to start adding systems to oslo.db to help produce and maintain triggers which certainly would have among its goals that consuming projects wouldn't be writing raw SQL. That part of the discomfort is more manageable than Clint's, which is that he doesn't want the database doing things with the data other than storing it, and I totally know where he's coming from on that.

The "be more similar" argument would be the only one you have to make. It basically says, "problem X is 'solved', other approaches are now unnecessary". I'm skeptical that I am reading that correctly. I have another approach to the issue of "rolling upgrades where we really need to translate at the SQL layer" that is in some ways similar to what triggers do, but entirely within the abstraction layer that you so appropriately appreciate :). I have a binary decision to make here, "do i work on this new idea that Glance has already expressed an interest in and Keystone might like also? Or do I not, because this problem is solved?". I have other projects to work on, so it's not like I'm looking for more. It's just I'd like to see Glance and others have their rolling upgrades problem solved, at least with the benefit of a fixed and predictable pattern, rather than every schema change being an ongoing seat-of-the-pants type of operation as it is right now.

Finally, it's a known and accepted pattern in large
scale MySQL shops ... Roll out a new version of the app code which
understands both the old and the new schema version, then roll out a
no-downtime additive schema change to the database, then have the app
layer process and handle on the fly transformation if needed.


Right, as I've mentioned previously, I only take issue with the "monolithic app code that speaks both versions of the schema" part. Assuming there's no layer of service indirection where migration issues can be finessed outside of the SQL interaction layer, it means every migration has to be accompanied by a game plan for all the places the SQL interaction logic must be changed and complicated, in totally ad-hoc ways that need to be devised and tested from scratch each time. "Large scale MySQL shops" at least have the benefit that they themselves are running "staging" and "production" in-house and can just push out live patches all day long to stumble around this kind of thing.


__________________________________________________________________________
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

Reply via email to