Open Stack

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