Bug 1877756
| Summary: | [OSP16.1] Bad container name when syncing Neutron DB into OVN DBs | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Roman Safronov <rsafrono> |
| Component: | python-networking-ovn | Assignee: | Jakub Libosvar <jlibosva> |
| Status: | CLOSED ERRATA | QA Contact: | Roman Safronov <rsafrono> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 16.1 (Train) | CC: | apevec, bhaley, jlibosva, lhh, majopela, scohen, spower |
| Target Milestone: | z2 | Keywords: | Regression, Triaged |
| Target Release: | 16.1 (Train on RHEL 8.2) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-networking-ovn-7.3.1-1.20200902233412.4e24f4c.1.el8ost | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-10-28 15:39:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
it looks for image name but with tls, there are two containers [root@controller-0 ~]# podman ps | grep neutron-server a582971532f5 undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-server-ovn:16.1_20200813.1 kolla_start 25 minutes ago Up 25 minutes ago neutron_server_tls_proxy 58d8f7caf289 undercloud-0.ctlplane.redhat.local:8787/rh-osbs/rhosp16-openstack-neutron-server-ovn:16.1_20200813.1 kolla_start 25 minutes ago Up 25 minutes ago neutron_api Verified on RHOS-16.1-RHEL-8-20201005.n.0 which uses python3-networking-ovn-migration-tool-7.3.1-1.20200902233412.4e24f4c.1.el8ost.noarch.rpm Verified that the issue does not happen and migration to OVN completed successfully. Note, I tested on a non-TLS environment because it was also affected by the issue. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Red Hat OpenStack Platform 16.1 bug fix and enhancement advisory), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:4284 |
Description of problem: OVN migration with TLS-everywhere fails on sync neutron db with OVN db From migration log: TASK [migration : Sync neutron db with OVN db (container) - Run 1] *************************************************************************************************************************** task path: /home/stack/ovn_migration/playbooks/roles/migration/tasks/sync-dbs.yml:7 Thursday 10 September 2020 09:17:03 +0000 (0:00:00.977) 0:45:34.054 **** META: noop META: noop fatal: [controller-0]: FAILED! => {"changed": true, "cmd": ["docker", "exec", "a582971532f5\n58d8f7caf289", "neutron-ovn-db-sync-util", "--config-file", "/etc/neutron/neutron.conf", "--config-file", "/etc/neutron/plugins/ml2/ml2_conf.ini", "--ovn-neutron_sync_mode", "repair"], "delta": "0:00:00.097683", "end": "2020-09-10 09:17:04.102952", "msg": "non-zero return code", "rc": 125, "start": "2020-09-10 09:17:04.005269", "stderr": "Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.\nError: no container with name or ID a582971532f5\n58d8f7caf289 found: no such container", "stderr_lines": ["Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.", "Error: no container with name or ID a582971532f5", "58d8f7caf289 found: no such container"], "stdout": "", "stdout_lines": []} Version-Release number of selected component (if applicable): RHOS-16.1-RHEL-8-20200903.n.0 How reproducible: 100%, tried twice (with DVR and w/o DVR), happened in both cases Steps to Reproduce: 1. Install HA ML2OVS environment with TLS-everywhere 2. Run migration to ML2OVN according to the official documentation Actual results: Migration failed due to failed db sync, ping to the workload fip lost Expected results: DB sync succeeds, ping to fip works, migration proceeds successfully Additional info: