<div dir="ltr">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.<div><br></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As an example:</div><div><br></div><div><font face="courier new, monospace">MASTER ---> X -> X+1 -> ... -> X+n</font></div><div><font face="courier new, monospace"> \</font></div><div><font face="courier new, monospace">FEATURE \-> Y -> Y+1 -> ... -> Y+m</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">At every rebase of rebase the migration timeline for the feature branch could be rearranged as follows:<br></font><div><font face="courier new, monospace"><br></font></div></div><div><div><font face="courier new, monospace">MASTER ---> X -> X+1 -> ... -> X+n ---></font></div><div><font face="courier new, monospace"> \</font></div><div><font face="courier new, monospace">FEATURE \-> Y=X+n -> Y+1 -> ... -> Y+m = X+n+m</font></div></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">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.</font></div><div><font face="arial, helvetica, sans-serif">I have not tried this, but I reckon that conceptually it should work.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Salvatore</font></div><div><font face="courier new, monospace"><br></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 September 2014 08:16, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If these are just feature branches and they aren't intended to be<br>
deployed for long life cycles, why don't we just skip the db migration<br>
and enable auto-schema generation inside of the feature branch? Then a<br>
migration can be created once it's time to actually merge into master.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 23, 2014 at 9:37 PM, Brandon Logan<br>
<<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> Well the problem with resequencing on a merge is that a code change for<br>
> the first migration must be added first and merged into the feature<br>
> branch before the merge is done. Obviously this takes review time<br>
> unless someone of authority pushes it through. We'll run into this same<br>
> problem on rebases too if we care about keeping the migration sequenced<br>
> correctly after rebases (which we don't have to, only on a merge do we<br>
> really need to care). If we did what Henry suggested in that we only<br>
> keep one migration file for the entire feature, we'd still have to do<br>
> the same thing. I'm not sure that buys us much other than keeping the<br>
> feature's migration all in one file.<br>
><br>
> I'd also say that code in master should definitely NOT be dependent on<br>
> code in a feature branch, much less a migration. This was a requirement<br>
> of the incubator as well.<br>
><br>
> So yeah this sounds like a problem but one that really only needs to be<br>
> solved at merge time. There will definitely need to be coordination<br>
> with the cores when merge time comes. Then again, I'd be a bit worried<br>
> if there wasn't since a feature branch being merged into master is a<br>
> huge deal. Unless I am missing something I don't see this as a big<br>
> problem, but I am highly capable of being blind to many things.<br>
><br>
> Thanks,<br>
> Brandon<br>
><br>
><br>
> On Wed, 2014-09-24 at 01:38 +0000, Doug Wiegley wrote:<br>
>> Hi Eugene,<br>
>><br>
>><br>
>> Just my take, but I assumed that we’d re-sequence the migrations at<br>
>> merge time, if needed. Feature branches aren’t meant to be optional<br>
>> add-on components (I think), nor are they meant to live that long.<br>
>> Just a place to collaborate and work on a large chunk of code until<br>
>> it’s ready to merge. Though exactly what those merge criteria are is<br>
>> also yet to be determined.<br>
>><br>
>><br>
>> I understand that you’re raising a general problem, but given lbaas<br>
>> v2’s state, I don’t expect this issue to cause many practical problems<br>
>> in this particular case.<br>
>><br>
>><br>
>> This is also an issue for the incubator, whenever it rolls around.<br>
>><br>
>><br>
>> Thanks,<br>
>> doug<br>
>><br>
>><br>
>><br>
>><br>
>> On September 23, 2014 at 6:59:44 PM, Eugene Nikanorov<br>
>> (<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>) wrote:<br>
>><br>
>> ><br>
>> > Hi neutron and lbaas folks.<br>
>> ><br>
>> ><br>
>> > Recently I briefly looked at one of lbaas proposed into feature<br>
>> > branch.<br>
>> > I see migration IDs there are lined into a general migration<br>
>> > sequence.<br>
>> ><br>
>> ><br>
>> > I think something is definitely wrong with this approach as<br>
>> > feature-branch components are optional, and also master branch can't<br>
>> > depend on revision IDs in<br>
>> > feature-branch (as we moved to unconditional migrations)<br>
>> ><br>
>> ><br>
>> > So far the solution to this problem that I see is to have separate<br>
>> > migration script, or in fact, separate revision sequence. The<br>
>> > problem is that DB models in feature branch may depend on models of<br>
>> > master branch, which means that each revision of feature-branch<br>
>> > should have a kind of "minimum required" revision of the master<br>
>> > branch.<br>
>> > The problem that revision IDs don't form linear order, so we can't<br>
>> > have 'minimum' unless that separate migration script may analyze<br>
>> > master branch migration sequence and find minimum required migration<br>
>> > ID.<br>
>> ><br>
>> ><br>
>> > Thoughts?<br>
>> ><br>
>> ><br>
>> > Thanks,<br>
>> > Eugene.<br>
>> > _______________________________________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> ><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Kevin Benton<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>