Open Stack

On 13.02.2016 02:42, Carl Baldwin wrote:
> 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
Hi Carl,

Your idea sounds workable to me. However I think a simpler way exists.

Significant part of 'built-in' ipam tables are continued to be updated even
if reference ipam driver is used (or any another driver).
It happens because these tables are API exposed, so they still have to
receive updates.

To be specific, next models from 'built-in' are related to ipam in some way:
- Subnet;
- IPAllocationPool;
- IPAllocation;
- IPAvailabilityRange;
Only IPAvailabilityRange stops to receive updates when switch to pluggable
ipam backend occurs.  And IPAvailabilityRange can be rebuilt based on
information
from IPAllocationPool and IPAllocation models [1].
It gives us ability to rebuild all the needed ipam information in
'built-in' tables even
if ipam driver is used.

I am trying to implement this approach in current version of migration
to pluggable ipam [2]
to allow safe switch back to 'built-in' implementation from pluggable.
'--rebuild' flag forces ip availability ranges recalculation relying
only on tables that are up to date
independently of backend currently used.

So to remove built-in ipam implementation we need:
- Remove old 'built-in' ipam implementation with IPAvailabilityRange table;
- Make ipam_driver default to 'internal'
- Run 'neutron-populate-ipam-data --rebuild'

'neutron-populate-ipam-data --rebuild'  clean ups all tables for
'internal' ipam driver
and rebuild them from Subnet, IPAllocation and IPAllocationPool. Then it
triggers
IPAvailabilityRange recalculation based on IPAllocation and
IPAllocationPool info.

[1]
https://github.com/openstack/neutron/blob/master/neutron/db/ipam_non_pluggable_backend.py#L86
[2] https://review.openstack.org/#/c/277767/
> __________________________________________________________________________
> 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