[openstack-dev] [neutron] [ipam] Migration to pluggable IPAM
armamig at gmail.com
Thu Feb 11 17:04:10 UTC 2016
On 10 February 2016 at 15: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,
> > this is a one-off, once it's done the pain goes away, and we won't be
> > 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?
I believe we have more recovery options out a potentially fatal situation.
In fact the offline script can provide a dry-run option that can just
validate that the migration will succeed before it is even actually
performed; I think that the size and the amount of tables involved in the
data migration justifies this course of action rather than the other. Think
about what Sean said, bugs are always lurking in the dark and as much as we
can strive for correctness, things might go bad. This is not a routine
migration and some operators may not be in a rush to embrace pluggable
IPAM, hence I don't think we are in the position to make the decision on
their behalf and go through the usual fast-path deprecation process.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev