interface network assignments not associating static addresses

[Allain Legacy]

Brief Description
-----------------
Attempting to move a network from one interface to another (e.g., from 'lo' to 'enp0s8') does not properly delete/re-create the static address assignments.

Severity
--------
Critical, this impacts final system configuration following initial configuration with the Ansible playbook.

Steps to Reproduce
------------------
Ideally, these are the steps required to move a network from one interface to another:

system host-if-modify controller-0 enp0s3 -c platform
system host-if-modify controller-0 enp0s8 -c platform
system interface-network-list controller-0
system interface-network-remove 326ea696-d35b-445f-bb07-489f96974036
system interface-network-remove f5a8b2d7-7c4f-4b73-9389-c347bab58339
system interface-network-assign controller-0 enp0s8 mgmt
system interface-network-assign controller-0 enp0s8 cluster-host
system interface-network-assign controller-0 enp0s3 oam
system host-addr-list controller-0

But, the network-assign/-remove commands are not currently dealing with the static addresses correctly, so we have to revert back to the old method of doing this which is:

system host-if-modify controller-0 lo -c none
system host-if-modify controller-0 enp0s3 -c platform --networks oam
system host-if-modify controller-0 enp0s8 -c platform --networks mgmt
system host-if-modify controller-0 enp0s8 -c platform --networks cluster-host

Unfortunately, because of a couple of different issues in the sysinv-api those commands do not properly setup the static addresses on the right interface. Those issues will be addressed in this bug, but fixing the ideal network-assign/-remove commands will be addressed in a separate feature.

Expected Behavior
------------------
After running either set of commands on controller-0 the host-addr-list system command should reflect that the static addresses have been moved from the old interface to the new interface.

Actual Behavior
----------------
The static addresses are still listed against the old interface.

Reproducibility
---------------
100%

System Configuration
--------------------
Standard 2+2

Branch/Pull Time/Commit
-----------------------
BUILD_ID="20190501T013000Z"

Last Pass
---------
Unknown

Timestamp/Logs
--------------
2019-05-03 12:48:03.199 15509 ERROR sysinv.objects.interface [-] DetachedInstanceError unable to get networks for <sysinv.db.sqlalchemy.models.VirtualInterfaces object at 0x7fefc47d2110>
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface Traceback (most recent call last):
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface File "/usr/lib64/python2.7/site-packages/sysinv/objects/interface.py", line 84, in get_networks
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface if getattr(db_object, 'interface_networks', None):
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 237, in __get__
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface return self.impl.get(instance_state(instance), dict_)
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/attributes.py", line 584, in get
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface value = self.callable_(state, passive)
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/strategies.py", line 530, in _load_for_state
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface (orm_util.state_str(state), self.key)
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface DetachedInstanceError: Parent instance <VirtualInterfaces at 0x7fefc47d2110> is not bound to a Session; lazy load operation of attribute 'interface_networks' cannot proceed
2019-05-03 12:48:03.199 15509 TRACE sysinv.objects.interface
2019-05-03 12:48:03.543 13086 WARNING sysinv.conductor.manager [req-b4dff6a5-295e-4262-8cc7-6d67e356f11e admin admin] No mgmt interface configured for ihost controller-0 while updating mgmt IP address

Test Activity
-------------
Developer Testing

[Ghada Khalil (gkhalil)]

Marking as release gating / high priority as it affects deployments with Ansible

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/657644

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/657645

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/657644
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=8527d5192bb7eaaa06a7386db41d06e7cb10ee7a
Submitter: Zuul
Branch: master

commit 8527d5192bb7eaaa06a7386db41d06e7cb10ee7a
Author: Allain Legacy <email address hidden>
Date: Tue May 7 07:35:55 2019 -0500

    fix static address assignment on interface network change

    There are cases where changing the network assignments for an interface
    results in an inconsistent set of static addresses for a host. For
    example, when setting multiple networks on a single interface it is
    possible, depending on the order of the networks, that the api fails
    to identify which interface is the host's mgmt interface. This is
    because of how the "networktype" attribute is used to identify
    specific interfaces. If the network has modified to add both the
    "cluster-host", and "mgmt" networks, but the "cluster-host" network was
    added first then that interface will not be identified as the "mgmt"
    interface.

    Since "networktype" is eventually going away, and since at the time
    when that information is needed we already know the target interface,
    there is no need to search (again) for the proper interface to use.

    This is only problematic from the CLI if the networks are not added in
    the expected order, but from the API any operation that adds both
    networks at the same time may result in unexpected behaviour.

    Change-Id: I86c8be4d0eb3b10b872b427bd05b3f5bfca4776a
    Closes-Bug: 1827882
    Signed-off-by: Allain Legacy <email address hidden>

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/657645
Committed: https://git.openstack.org/cgit/starlingx/config/commit/?id=8e0278f52532aa019ac76ebc4503d4359e11c7a4
Submitter: Zuul
Branch: master

commit 8e0278f52532aa019ac76ebc4503d4359e11c7a4
Author: Allain Legacy <email address hidden>
Date: Tue May 7 07:39:30 2019 -0500

    add joined query to the interface network associations

    There is currently no explicit eager join between the interface resource
    and the interface-network resource in the data model. The API uses the
    DB data outside of the scope of the active DB session therefore if it
    attempts to reach across a foreign key relationship, and if the DB
    session has expired (or has been re-used), then the access results in an
    exception which results in an empty network list for an interface.

    Having incorrect data in the network list can lead subsequent API code
    to take an unexpected path and cause the original user request to fail.
    Since we know that whenever an interface is queried that we will be
    querying the related interface-network resources then it is better to
    add an explicit load operation on the model backref so that the DB
    session does not need to be accessed a second time outside of its valid
    scope.

    Change-Id: I56d880659ec2412b391d5bb8700a74fa7f288cbb
    Closes-Bug: 1827882
    Signed-off-by: Allain Legacy <email address hidden>