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