Bug 1823334

Description of problem:
After successfully stack update (from mistral perspective[1]), we noticed that all overcloud nodes exist with neutron-ovs service containers and all the contorller nodes are exist with tenant network namespace containers for existing tenant networks and routers.

As OVN migration script executed task separately, so there is no clarity of the role "ForceNeutronDriverUpdate" THT parameter.

If "ForceNeutronDriverUpdate" THT parameter is expected to update the configuration file with ml2-ovn then it is also recommended to delete the existing ml2-ovs resources during the stack update.

Version-Release number of selected component (if applicable):
Red Hat OpenStack Platform release 16.0.1 (Train)

ansible-role-tripleo-modify-image-1.1.1-0.20200122200932.58d7a5b.el8ost.noarch
puppet-tripleo-11.4.1-0.20200205150840.71ff36d.el8ost.noarch
openstack-tripleo-puppet-elements-11.2.2-0.20200128210949.d668f88.el8ost.noarch
python3-tripleoclient-12.3.2-0.20200130192329.78ac810.el8ost.noarch
openstack-tripleo-common-containers-11.3.3-0.20200206225551.18d4fbc.el8ost.noarch
python3-tripleo-common-11.3.3-0.20200206225551.18d4fbc.el8ost.noarch
openstack-tripleo-common-11.3.3-0.20200206225551.18d4fbc.el8ost.noarch
ansible-tripleo-ipsec-9.2.0-0.20191022054642.ffe104c.el8ost.noarch
openstack-tripleo-validations-11.3.2-0.20200206065551.1a9b92a.el8ost.noarch
openstack-tripleo-heat-templates-11.3.2-0.20200211065546.d3d6dc3.el8ost.noarch
tripleo-ansible-0.4.2-0.20200207140443.b750574.el8ost.noarch
python3-tripleoclient-heat-installer-12.3.2-0.20200130192329.78ac810.el8ost.noarch
openstack-tripleo-image-elements-10.6.1-0.20191022065313.7338463.el8ost.noarch
python3-networking-ovn-migration-tool-7.1.0-0.20200204065607.57ac389.el8ost.noarch

How reproducible: 100% reproduced in scale lab.

Steps to Reproduce:
1. Executed the migration steps as per official documentation.
	https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/networking_with_open_virtual_network/index#migrating-ml2ovs-to-ovn

2. Migration steps are break as it depends on the exit status of overcloud deployment command.
	https://bugzilla.redhat.com/show_bug.cgi?id=1818866
3. But referring to ansible mistral log, the stack is updated successfully.

Actual results:
After the update, we noticed that the neutron-ovs service containers and existing neutron namespace containers still exist in overcloud nodes.

Expected results:
ForceNeutronDriverUpdate THT parameter should cleanup the ml2-ovs resources as it is updating ml2-ovn resources.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1818866