Open Stack

---
John Belamaric
(240) 383-6963

> On Feb 11, 2016, at 5:37 AM, Ihar Hrachyshka <ihrachys at 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 <carl at ecbaldwin.net> wrote:
>> On Thu, Feb 4, 2016 at 8:12 PM, Armando M. <armamig at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev