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 <[email protected]> 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 <[email protected]> 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 > <[email protected]> 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 > >> ([email protected]) 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 > >> > [email protected] > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > >> _______________________________________________ > >> OpenStack-dev mailing list > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > -- > Kevin Benton > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
