> On Feb 4, 2016, at 11:09 AM, Carl Baldwin <c...@ecbaldwin.net> wrote: > > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar <pbon...@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, it certainly should be at parity, and gate testing to ensure it would be best. >> 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. > If we do this, and the operator reverts back to the non-pluggable version, then we will leave stale records in the new IPAM tables. At the very least, we would need a way to clean those up and to migrate at a later time. >> 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? > Originally (as I mentioned in the meeting), I was thinking that we should not automatically migrate. However, I see the appeal of your arguments. Seamless is best, of course. But if we offer going back to non-pluggable, (which I think we need to at this point in the Mitaka cycle), we probably need to provide a script as mentioned above. Seems feasible, though. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
