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<mailto: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

Reply via email to