Open Stack

Eugene Nikanorov <enikanorov at mirantis.com> wrote:
> Hi neutron and lbaas folks.
> 
> Recently I briefly looked at one of lbaas proposed into feature branch.
> I see migration IDs there are lined into a general migration sequence.
> 
> I think something is definitely wrong with this approach as feature-branch
> components are optional, and also master branch can't depend on revision IDs in
> feature-branch (as we moved to unconditional migrations)
> 
> So far the solution to this problem that I see is to have separate migration
> script, or in fact, separate revision sequence. The problem is that DB models
> in feature branch may depend on models of master branch, which means that each
> revision of feature-branch should have a kind of "minimum required" revision
> of the master branch.
> The problem that revision IDs don't form linear order, so we can't have
> 'minimum' unless that separate migration script may analyze master branch
> migration sequence and find minimum required migration ID.
> 
> Thoughts?

Here is my thought. Others may have better ideas.

In the feature branch maintain just one migration. Call it lbaasv2.
This migration is all the schema differences from master's head.

The lbaasv2 migration must be moved to after master's head every time the head
gets updated by a sync from master.

Every time some DB changes occur in the feature branch, update the lbaasv2
migration with the changes. (Do not create a new migration.)

When it's time to promote the feature to neutron master, the lbaasv2 migration
will integrate with the master timeline.