Open Stack

On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar <pbondar at infoblox.com> wrote:
> I am trying to bring more attention to [1] to make final decision on
> approach to use.
> There are a few point that are not 100% clear for me at this point.
>
> 1) Do we plan to switch all current clouds to pluggable ipam
> implementation in Mitaka?

I think our plan originally was only to deprecate the non-pluggable
implementation in Mitaka and remove it in Newton.  However, this is
worth some more consideration.  The pluggable version of the reference
implementation should, in theory, be at parity with the current
non-pluggable implementation.  We've tested it before and shown
parity.  What we're missing is regular testing in the gate to ensure
it continues this way.

> yes -->
> Then data migration can be done as alembic_migration and it is what
> currently implemented in [2] PS54.
> In this case during upgrade from Liberty to Mitaka all users are
> unconditionally switched to reference ipam driver
> from built-in ipam implementation.
> If operator wants to continue using build-in ipam implementation it can
> manually turn off ipam_driver in neutron.conf
> immediately after upgrade (data is not deleted from old tables).

This has a certain appeal to it.  I think the migration will be
straight-forward since the table structure doesn't really change much.
Doing this as an alembic migration would be the easiest from an
upgrade point of view because it fits seamlessly in to our current
upgrade strategy.

If we go this way, we should get this in soon so that we can get the
gate and others running with this code for the remainder of the cycle.

> no -->
> Operator is free to choose whether it will switch to pluggable ipam
> implementation
> and when. And it leads to no automatic data migration.
> In this case operator is supplied with script for migration to pluggable
> ipam (and probably from pluggable ipam),
> which can be executed by operator during upgrade or at any point after
> upgrade is done.
> I was testing this approach in [2] PS53 (have unresolved issues in it
> for now).

If there is some risk in changing over then this should still be
considered.  But, the more I think about it, the more I think that we
should just make the switch seamlessly for the operator and be done
with it.  This approach puts a certain burden on the operator to
choose when to do the migration and go through the steps manually to
do it.  And, since our intention is to deprecate and remove the
non-pluggable implementation, it is inevitable that they will have to
eventually switch anyway.

This also makes testing much more difficult.  If we go this route, we
really should be testing both equally.  Does this mean that we need to
set up a whole new job to run the pluggable implementation along side
the old implementation?  This kind of feels like a nightmare to me.
What do you think?

> Or we could do both, i.e. migrate data during upgrade from built-in to
> pluggable ipam implementation
> and supply operator with scripts to migrate from/to pluggable ipam at
> any time after upgrade.
>
> According to current feedback in [1] it most likely we go with script
> approach,
> so would like to confirm if that is the case.
>
> 2) Do we plan to make ipam implementation default in Mitaka for greenfields?

I'll wait to respond to the remainder of this email until after we get
more clarity on your first question.  I'd like to hear from anyone in
the community but especially would like to hear from Salvatore, as the
author of the new implementation, and Armax, as our fearless and
beloved PTL.

Carl

> If answer for this question is the same as for previous (yes/yes,
> no/no), then it doesn't introduce additional issues.
> But if answer is different from previous then it might complicate stuff.
> For example, greyfields might be migrated manually by operator to
> pluggable ipam, or continue to work using built-in implementation after
> upgrade in Mitaka.
> But greenfields might be set to pluggable ipam implementation by default.
>
> Is it what we are going to support?
>
> 3) How the script approach should be tested?
>
> Currently if pluggable implementation is set as default, then grenade
> test fails.
> Data has to be migrated during upgrade automatically to make grenade pass.
> In [1] PS53 I was using alembic migration that internally just call
> external migrate script.
> Is it a valid approach? I expect that better way to test script
> execution during upgrade might exist.
>
> [1] https://bugs.launchpad.net/neutron/+bug/1516156
> [2] https://review.openstack.org/#/c/181023