Open Stack

On Thu, Feb 11, 2016 at 10:04 AM, Armando M. <armamig at gmail.com> wrote:
> 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.

I had a long discussion with Armando about this.  I was pretty
stubborn but there was one point that came up that got through and got
me thinking.  Basically, it is that having the ability to migrate to
pluggable IPAM in Mitaka could be a key component to giving users a
path to migrate to a 3rd party pluggable implementation.  Without it,
3rd parties will have to support two kinds of migration:  one for each
of the drivers currently available.

The only way to get something in to Mitaka is do to an offline
migration.  I agree that we shouldn't do the full automatic switch
this late in the cycle.

So, is this worth getting in to Mitaka to help this use case?  If it
is a significantly important component of migrating to 3rd party IPAM
then maybe the answer should be yes.  If it is just to help get people
to the pluggable internal implementation in Mitaka then I'd say no
because it it doesn't provide any user visible advantage and it
doesn't yet have the gate testing miles on it that the old
implementation has.

Carl