Open Stack

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.logan at 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
>> (enikanorov at 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
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Kevin Benton