Open Stack

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160211/a94f2868/attachment.html>