Open Stack

Yeah, it's my understanding that feature branches are just going to be
used for large code changes that are too hard to manage as strings of
dependent gerrit reviews.

On Wed, Sep 24, 2014 at 3:20 PM, Eugene Nikanorov
<enikanorov at mirantis.com> wrote:
> 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 <sorlando at 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 <blak111 at 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.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
>>>
>>> _______________________________________________
>>> 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