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 OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev