--- John Belamaric (240) 383-6963
> On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > > What’s the user visible change in behaviour after the switch? If it’s only > internal implementation change, I don’t see why we want to leave the choice > to operators. > It is only internal implementation changes. >> The other aspect is the deprecation process. If you add the switch into the >> DB migration path then the whole deprecation becomes superseded as the old >> IPAM logic should be abandoned immediately after that. But perhaps the other >> way of looking at it is that we should make an exception in the deprecation >> process. >> >> Salvatore >> >> On 11 February 2016 at 00:19, Carl Baldwin <c...@ecbaldwin.net> wrote: >> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <arma...@gmail.com> wrote: >> > Technically we can make this as sophisticated and seamless as we want, but >> > this is a one-off, once it's done the pain goes away, and we won't be doing >> > another migration like this ever again. So I wouldn't over engineer it. >> >> Frankly, I was worried that going the other way was over-engineering >> it. It will be more difficult for us to manage this transition. >> >> I'm still struggling to see what makes this particular migration >> different than other cases where we change the database schema and the >> code a bit and we automatically migrate everyone to it as part of the >> routine migration. What is it about this case that necessitates >> giving the operator the option? >> >> Carl >> >> __________________________________________________________________________ >> 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 >> >> __________________________________________________________________________ >> 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 > > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
