Salvatore Orlando <salv.orla...@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 <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
