Open Stack

Well the problem with resequencing on a merge is that a code change for
the first migration must be added first and merged into the feature
branch before the merge is done.  Obviously this takes review time
unless someone of authority pushes it through.  We'll run into this same
problem on rebases too if we care about keeping the migration sequenced
correctly after rebases (which we don't have to, only on a merge do we
really need to care).  If we did what Henry suggested in that we only
keep one migration file for the entire feature, we'd still have to do
the same thing.  I'm not sure that buys us much other than keeping the
feature's migration all in one file.

I'd also say that code in master should definitely NOT be dependent on
code in a feature branch, much less a migration.  This was a requirement
of the incubator as well.

So yeah this sounds like a problem but one that really only needs to be
solved at merge time.  There will definitely need to be coordination
with the cores when merge time comes.  Then again, I'd be a bit worried
if there wasn't since a feature branch being merged into master is a
huge deal.  Unless I am missing something I don't see this as a big
problem, but I am highly capable of being blind to many things.

Thanks,
Brandon


On Wed, 2014-09-24 at 01:38 +0000, Doug Wiegley wrote:
> Hi Eugene,
> 
> 
> Just my take, but I assumed that we’d re-sequence the migrations at
> merge time, if needed.  Feature branches aren’t meant to be optional
> add-on components (I think), nor are they meant to live that long.
>  Just a place to collaborate and work on a large chunk of code until
> it’s ready to merge.  Though exactly what those merge criteria are is
> also yet to be determined.
> 
> 
> I understand that you’re raising a general problem, but given lbaas
> v2’s state, I don’t expect this issue to cause many practical problems
> in this particular case.
> 
> 
> This is also an issue for the incubator, whenever it rolls around.
> 
> 
> Thanks,
> doug
> 
> 
> 
> 
> On September 23, 2014 at 6:59:44 PM, 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?
> > 
> > 
> > Thanks,
> > Eugene.
> > _______________________________________________ 
> > OpenStack-dev mailing list 
> > OpenStack-dev at lists.openstack.org 
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> > 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev