On 11 February 2016 at 07:01, John Belamaric <jbelama...@infoblox.com> wrote:
> > > --- > 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. > That's not entirely true, is it? There are config variables to change and it opens up the possibility of a scenario that the operator may not care about. > > > >> 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 >
__________________________________________________________________________ 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