Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-25 Thread Mike Bayer

If Neutron is ready for more Alembic features I could in theory begin work on 
https://bitbucket.org/zzzeek/alembic/issue/167/multiple-heads-branch-resolution-support
 .Folks should ping me on IRC regarding this.


On Sep 24, 2014, at 5:30 AM, 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 +, 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 

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-24 Thread Kevin Benton
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 +, 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


Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-24 Thread Salvatore Orlando
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 +, 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 

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-24 Thread Eugene Nikanorov
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 +, 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, 

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-24 Thread Kevin Benton
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
enikano...@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 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 +, 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 

Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-23 Thread Henry Gessau
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?

Here is my thought. Others may have better ideas.

In the feature branch maintain just one migration. Call it lbaasv2.
This migration is all the schema differences from master's head.

The lbaasv2 migration must be moved to after master's head every time the head
gets updated by a sync from master.

Every time some DB changes occur in the feature branch, update the lbaasv2
migration with the changes. (Do not create a new migration.)

When it's time to promote the feature to neutron master, the lbaasv2 migration
will integrate with the master timeline.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-23 Thread Doug Wiegley
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.commailto: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


Re: [openstack-dev] [Neutron][LBaaS] Migrations in feature branch

2014-09-23 Thread Brandon Logan
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 +, 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