Open Stack

Salvatore Orlando <salv.orlando at gmail.com> wrote:

> The difference lies in the process in my opinion.
> If the switch is added into the migration path then we will tell  
> operators when to switch.
> I was suggesting doing it manual because we just don't know if every  
> operator is happy about doing the switch when upgrading to Newton, but  
> perhaps it is just me over-worrying about operator behaviour.
>

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.

> 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