Open Stack

On Fri, Feb 12, 2016 at 5:01 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>>> It is only internal implementation changes.
>>>
>>> That's not entirely true, is it? There are config variables to change and
>>> it opens up the possibility of a scenario that the operator may not care
>>> about.
>>>
>>
>> If we were to remove the non-pluggable version altogether, then the
>> default for ipam_driver would switch from None to internal. Therefore, there
>> would be no config file changes needed.
>>
>> I think this is correct.
>> Assuming the migration path to Neutron will include the data
>> transformation from built-in to pluggable IPAM, do we just remove the old
>> code and models?
>> On the other hand do you think it might make sense to give operators a
>> chance to rollback - perhaps just in case some nasty bug pops up?
>
>
> They can always revert to a previous release. And if we enable the new
> implementation start of Newton, we’ll have enough time to fix bugs that will
> pop up in gate.

So, to do this, we have to consider two classes of current users.
Since the pluggable implementation has been available, I think that we
have to assume someone might be using it.  Someone could easily have
turned it on in a green-field deployment.  If we push the offline
migration in to Mitaka as per my last email then we'll likely get a
few more of these but it doesn't really matter, the point is that I
think we need t assume that they exist.

1) Users of the old baked-in implementation
  - Their current data is stored in the old tables.

2) User of the new pluggable implementation
 - Their current data is stored in the new tables.

So, how does an unconditional migration work?  We can't just copy the
old tables to the new tables because we might clobber data for the
users in #2.  I've already heard that conditional migrations are a
pain and shouldn't be considered.  This seems like a problem.

I had an idea that I wanted to share but I'm warning you, it sounds a
little crazy even to me.  But, maybe it could work.  Read through it
for entertainment purposes if nothing else.

Instead of migrating data from the old tables to the new.  What if we
migrated the old tables in place in a patch set that removed all of
the old code?  The table structure is nearly identical, right?  The
differences, I imagine, could be easily handled by an alembic
migration.  Correct me if I'm wrong.

Now, we still have a difference between users in groups #1 and #2
above.  To keep them separate, we would call the new built-in
pluggable driver "built-in", "neutron", or whatever.  The name isn't
important except that it can't be "internal".

1) Users who were migrated to the new baked-in implementation.
  - Their current data is still in the old tables but they have been
migrated to look just like the new tables.
  - They have still not set "ipam_driver" in their config so they get
the new default of "built-in".

2) Early adopters of built-in pluggable ipam
  - Their current data is still in the new tables
  - They have their config set to "internal" already

So, now we have to deal with two identical pluggable implementations:
one called "built-in" and the other called "internal" but otherwise
they're identical in every way.  So, to handle this, could we
parameterize the plugin so that they share exactly the same code while
"internal" is deprecated?  Just the table names would be
parameterized.

We have to eventually reconcile users in group #1 with #2.  But, now
that the tables are identical we could provide an offline migration
that might be as simple as deleting the "old" tables and renaming the
"new" tables.  Now, only users in group #2 are required to perform an
offline migration.

Carl