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 <sorla...@nicira.com>
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 <blak...@gmail.com> 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
>> <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
>> >> > OpenStack-dev@lists.openstack.org
>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev@lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to