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 > > OpenStackemail@example.com > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev