remove support for port & portgroup's extra[vif_port_id]

[Ruby Loo]

The ability to attach/detach a VIF to/from a port or portgroup via the object's extra['vif_port_id'] entry was deprecated in Ocata [1]. Support for this was slated to be removed in Pike.

We are now in the Queen's cycle and this was mentioned at the Denver PTG [2]; let's remove support for it.

The Plan:
=========

In Queens:
---------
- at API level, copy any settings (non-None) to port or port group's extra['vif_port_id'] to that object's internal_info['tenant_vif_port_id']
- add a migration that is invoked via 'ironic-dbsync online_data_migrations' to go through the port and port groups in the database, and copy/save-to-DB any settings (non-None) in the object's extra['vif_port_id'] to that object's internal_info['tenant_vif_port_id']

In Rocky:
---------
In API request, if the user updates extra['vif_port_id']:
- if API version is < 1.28 (before we added vifs endpoints), we must still support attaching via extra['vif_port_id'] -- so we copy it to internal_info['tenant_vif_port_id'] (as was done in Queens)
- if API version is >= 1.28, we let the user update extra['vif_port_id'] but don't do anything with it (no copying to internal_info).

In conductor, remove any code that touches the port or port group's extra['vif_port_id']; the code should only be looking at that object's internal_info['tenant_vif_port_id'].

- Note that we cannot delete/remove an object's extra['vif_port_id'] entry, since extra was/is meant for our users to use, never for our code. Our code did clear it, but after we remove support for .extra[], we must not clear it any more.

How it'll work
--------------
1. Our users/operators will upgrade from Ocata to Queens

2. In Queens:
- if they try to set extra['vif_port_id'], it will get copied to internal_info
- before they upgrade to Rocky, they must run ironic-dbsync online_data_migrations
- they may try to set extra['vif_port_id'] *after* they run ironic-dbsync online_data_migrations

3. Operator upgrades to Rocky release. At this point, we know that all extra['vif_port_id'] got copied to internal_info

4. Rocky release:
- ignores extra['vif_port_id'] if API version >=1.28. User can set/modify it via API, but we just leave the value there for user purposes.
- supports extra['vif_port_id'] if API version < 1.28

==============

[1] https://docs.openstack.org/releasenotes/ironic/ocata.html#deprecation-notes
[2] https://etherpad.openstack.org/p/ironic-queens-ptg-ongoing-work

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/511636

[Ruby Loo (rloo)]

This was mentioned in the Denver PTG (Sept 2017) [1]:

We need a migration for VIFs
- port.extra[vif_port_id] ----> port.internal_info[tenant_vif_port_id]
  if in active else port.internal_info[provisioning/cleaning_vif_port_id]
  if in provisioning/cleaning
- it also can be network interface specific
- rloo will make sure it gets done

I looked through the code:
- the 'flat' interface uses port.extra[vif_port_id] or port.internal_info[tenant_vif_port_id] for provisioning and config '[neutron]cleaning_network' for cleaning.
- the 'neutron' interface uses the configs '[neutron] provisioning_network' & 'cleaning_network' for provisioning and cleaning respectively.

I'm also not sure what the 'it also can be network interface specific' means. (Unless it means what I just noted above). I looked at the network interfaces we have in tree.

[1] https://etherpad.openstack.org/p/ironic-queens-ptg-ongoing-work

[Ruby Loo (rloo)]

Vasyl raised a good point, should we remove the ability to attach vifs via a port or port group's .extra['vif_port_id'] if the API version is < 1.28.

1.28 is when the vifs endpoint was added [1]

The spec doesn't mention anything about this [2]

We (myself, Vasyl, and Dmitry) had a brief discussion on IRC about this [3] and decided that it should be supported if version > 1.28.

[1] https://docs.openstack.org/ironic/latest/contributor/webapi-version-history.html#id5

[2] http://specs.openstack.org/openstack/ironic-specs/specs/7.0/interface-attach-detach-api.html#upgrades-and-backwards-compatibility

[3] http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2017-10-25.log.html#t2017-10-25T13:15:45

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/511636
Committed: https://git.openstack.org/cgit/openstack/ironic/commit/?id=37b85b6a399dba120de49d9056529852b2284793
Submitter: Zuul
Branch: master

commit 37b85b6a399dba120de49d9056529852b2284793
Author: Ruby Loo <email address hidden>
Date: Thu Oct 12 18:30:52 2017 -0400

    Copy port[group] VIF info from extra to internal_info

    For API versions >= 1.28, Port & portgroup's .extra['vif_port_id'] was
    deprecated in Ocata. Before we can remove support for this, we need to
    copy that information to the object's internal_info['tenant_vif_port_id'].

    This copy/migration is done at the API layer when the user specifies the
    .extra[] value, as well as when the 'ironic db-sync online_data-migrations'
    is run.

    In order to know whether the ports and port groups have been migrated,
    their IronicObject versions are incremented.

    This also fixes it so that for API versions < 1.28, the deprecation
    warning is not shown, since we still need to support extra['vif_port_id']
    in this case.

    When a port or portgroup's .extra['vif_port_id'] is removed via a
    PATCH API request, that VIF is removed from that object's internal_info.

    Change-Id: I69468c935e68dd9d37a474c318c3ceb9cdfc5868
    Partial-Bug: 1722850

[Ruby Loo (rloo)]

Looks like this was finished/removed in Wallaby: https://docs.openstack.org/releasenotes/ironic/wallaby.html#relnotes-17-0-0-stable-wallaby-upgrade-notes