Not much to add here - I commented in review.openstack.org/378063<http://review.openstack.org/378063> that they could set the default value of the flag to revert behaviour. - Matt
On Oct 11, 2016, at 10:21 PM, Armando M. <arma...@gmail.com<mailto:arma...@gmail.com>> wrote: On 11 October 2016 at 18:20, Sean M. Collins <s...@coreitpro.com<mailto:s...@coreitpro.com>> wrote: Armando M. wrote: > At this point I feel that changing the pool range is even less justified. > If I had seen bug [4], I would have been against its fix, because you're > absolutely right as the change being not backward compatible. https://review.openstack.org/#/c/356026 was written by someone on the Trove team to help them with their CI jobs IIRC. CC'ing Matthew since he has more context. I went into the Trove channel and asked them about reverting 356026. It doesn't seem like an option at this point. http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%23openstack-trove.2016-09-30.log.html#t2016-09-30T17:53:08 A revert with no follow up is clearly not a viable option most of the times, and we clearly dug ourselves too deep now with [1]. Rather than making the use of subnet pools conditional as done in [1], IMO we should have made [2] conditional to preserve the existing provisioning behavior and let Trove override. [1] Ic89ceca76afda67da5545111972c3348011f294f [2] https://review.openstack.org/#/c/356026/ -- Sean M. Collins __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
