Apparently I've mistakenly though that feature branch will form separate optional component. If it will eventually be a part of neutron - then it's fine.
Thanks, Eugene. On Wed, Sep 24, 2014 at 1:30 PM, 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
