On Tue, 4 Sep 2018, Eric Fried wrote:
030 is okay as long as nothing goes wrong. If something does it
raises exceptions which would currently fail as the exceptions are
not there. See below for more about exceptions.
Maybe I'm misunderstanding what these migration thingies are supposed to
be doing, but 030 [1] seems like it's totally not applicable to
placement and should be removed. The placement database doesn't (and
shouldn't) have 'flavors', 'cell_mappings', or 'host_mappings' tables in
the first place.
What am I missing?
Nothing, as far as I can tell, but as we hadn't had a clear
plan about how to proceed with the trimming of migrations, I've been
trying to point out where they form little speed bumps as we've
gone through this process and carried them with us. And tried to
annotate where there may present some more, until we trim them.
There are numerous limits to my expertise, and the db migrations is
one of several areas where I decided I wasn't going to hold the ball,
I'd just get us to the game and hope other people would find and
fill in the blanks. That seems to be working okay, so far.
* Presumably we can trim the placement DB migrations to just stuff
that is relevant to placement
Yah, I would hope so. What possible reason could there be to do otherwise?
Mel's plans looks good to me.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
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
