If Neutron is ready for more Alembic features I could in theory begin work on 
https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support
 .    Folks should ping me on IRC regarding this.


On Sep 24, 2014, at 5:30 AM, Salvatore Orlando <sorla...@nicira.com> wrote:

> Relying again on automatic schema generation could be error-prone. It can 
> only be enabled globally, and does not work when models are altered if the 
> table for the model being altered already exists in the DB schema.
> 
> I don't think it would be a big problem to put these migrations in the main 
> sequence once the feature branch is merged back into master.
> Alembic unfortunately does not yet do a great job in maintaining multiple 
> timelines. Even if only a single migration branch is supported, in theory one 
> could have a separate alembic environment for the feature branch, but that in 
> my opinion just creates the additional problem of handling a new environment, 
> and does not solve the initial problem of re-sequencing migrations.
> 
> Re-sequencing at merge time is not going to be a problem in my opinion. 
> However, keeping all the lbaas migrations chained together will help. You can 
> also do as Henry suggests, but that option has the extra (possibly 
> negligible) cost of squashing all migrations for the whole feature branch at 
> merge time.
> 
> As an example:
> 
> MASTER  ---> X -> X+1 -> ... -> X+n
>         \
> FEATURE  \-> Y -> Y+1 -> ... -> Y+m
> 
> At every rebase of rebase the migration timeline for the feature branch could 
> be rearranged as follows:
> 
> MASTER  ---> X -> X+1 -> ... -> X+n --->
>                                      \
> FEATURE                               \-> Y=X+n -> Y+1 -> ... -> Y+m = X+n+m
> 
> And therefore when the final merge in master comes, all the migrations in the 
> feature branch can be inserted in sequence on top of master's HEAD.
> I have not tried this, but I reckon that conceptually it should work.
> 
> Salvatore
> 
> 
> On 24 September 2014 08:16, Kevin Benton <blak...@gmail.com> wrote:
> If these are just feature branches and they aren't intended to be
> deployed for long life cycles, why don't we just skip the db migration
> and enable auto-schema generation inside of the feature branch? Then a
> migration can be created once it's time to actually merge into master.
> 
> On Tue, Sep 23, 2014 at 9:37 PM, Brandon Logan
> <brandon.lo...@rackspace.com> wrote:
> > 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
> >> (enikano...@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@lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> --
> Kevin Benton
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to