Bug 1647964 - OVN Images not being pulled in on stack update
Summary: OVN Images not being pulled in on stack update
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-common
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 14.0 (Rocky)
Assignee: Steve Baker
QA Contact: Alexander Chuzhoy
URL:
Whiteboard:
Depends On:
Blocks: 1546994 1925290
TreeView+ depends on / blocked
 
Reported: 2018-11-08 15:59 UTC by Daniel Alvarez Sanchez
Modified: 2022-03-11 15:07 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-20 22:36:41 UTC
Target Upstream Version:
Embargoed:
majopela: needinfo-
majopela: needinfo-


Attachments (Terms of Use)
Heat template env files (7.46 KB, application/octet-stream)
2018-11-27 15:37 UTC, daniel parkes
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-13519 0 None None None 2022-03-11 15:07:29 UTC

Description Daniel Alvarez Sanchez 2018-11-08 15:59:14 UTC
Description of problem:
When deploying fresh setup using OVN, the neutron driver gets automatically detected (I assume thanks to this patch [0]). However, if a setup with ML2/OVS is updated to a different Neutron mechanism driver, OVN images are not pulled in.

This is affecting the ML2/OVS to ML2/OVN migration since we can't change the mechanism driver from TripleO.


[0] https://github.com/openstack/tripleo-common/commit/5304f97288d252de942d1c3a6a602e82499bc4e0#diff-5686866f4a979cffdb87197ecf7841ce

Comment 1 Miguel Angel Ajo 2018-11-08 16:34:09 UTC
UPDATE:

We tried, after changing neutron_driver to ovn in the containers-prepare-parameter.yaml

parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      ceph_image: rhceph
      ceph_namespace: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888
      ceph_tag: 3-13
      name_prefix: openstack-
      name_suffix: ''
      namespace: docker-registry.engineering.redhat.com/rhosp14
      neutron_driver: ovn
      openshift_base_image: ose
      openshift_cockpit_image: registry-console
      openshift_cockpit_namespace: registry.access.redhat.com/openshift3
      openshift_cockpit_tag: v3.10
      openshift_etcd_image: etcd
      openshift_etcd_namespace: registry.access.redhat.com/rhel7
      openshift_etcd_tag: latest
      openshift_gluster_block_image: rhgs-gluster-block-prov-rhel7
      openshift_gluster_image: rhgs-server-rhel7
      openshift_gluster_namespace: registry.access.redhat.com/rhgs3
      openshift_gluster_tag: latest
      openshift_heketi_image: rhgs-volmanager-rhel7
      openshift_heketi_namespace: registry.access.redhat.com/rhgs3
      openshift_heketi_tag: latest
      openshift_namespace: registry.access.redhat.com/openshift3
      openshift_tag: v3.10
      tag: 2018-11-06.1


to run:

 openstack tripleo container image prepare --environment-file /home/stack/containers-prepare-parameter.yaml


Which detected the new containers, and uploaded the images to the local registry, 

but then when we run 


$  openstack overcloud deploy \
--timeout 100 \
--templates /usr/share/openstack-tripleo-heat-templates \
--stack overcloud \
--libvirt-type kvm \
--ntp-server clock.redhat.com \
-e /home/stack/virt/config_lvm.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /home/stack/virt/inject-trust-anchor.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/nodes_data.yaml \
-e ~/containers-prepare-parameter.yaml \
-e /home/stack/virt/extra_templates.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-ha.yaml \
-e /home/stack/ovn-extras.yaml \
--log-file overcloud_deployment_48.log



(undercloud) [stack@undercloud-0 ~]$ date
Thu Nov  8 11:31:02 EST 2018
(undercloud) [stack@undercloud-0 ~]$ cd /tmp/tripleoclient-cpjNA2/
(undercloud) [stack@undercloud-0 tripleoclient-cpjNA2]$ cat tripleo-heat-templates/environments/containers-default-parameters.yaml  | grep Ovn
(undercloud) [stack@undercloud-0 tripleoclient-cpjNA2]$ cat tripleo-heat-templates/environments/containers-default-parameters.yaml  | grep ovn
  DockerNovaVncProxyImage: registry.access.redhat.com/rhosp14/openstack-nova-novncproxy:latest
(undercloud) [stack@undercloud-0 tripleoclient-cpjNA2]$ ls -la tripleo-heat-templates/environments/containers-default-parameters.yaml
-rw-rw-r--. 1 stack stack 14711 Nov  8 11:14 tripleo-heat-templates/environments/containers-default-parameters.yaml


The containers-default-parameters.html doesn't have the right files

Comment 2 Miguel Angel Ajo 2018-11-12 12:38:59 UTC
No folks, this is not DFG:Networking, we know nothing about the logic in tripleo that handles the container images, it's not a *networking specific* issue.

It's blocking us.

Comment 3 Steve Baker 2018-11-12 20:58:52 UTC
Can you please provide the following:
- package versions of openstack-tripleo-common and openstack-tripleo-heat-templates
- attach the files in /home/stack/virt to this bug so I can attempt to reproduce.

If you want to do some more local diagnosis then you can run prepare on its own with this command:

openstack tripleo container image prepare \
-e /home/stack/virt/config_lvm.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /home/stack/virt/network/network-environment.yaml \
-e /home/stack/virt/inject-trust-anchor.yaml \
-e /home/stack/virt/hostnames.yml \
-e /home/stack/virt/nodes_data.yaml \
-e ~/containers-prepare-parameter.yaml \
-e /home/stack/virt/extra_templates.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-ha.yaml \
-e /home/stack/ovn-extras.yaml \
--dry-run

Comment 5 daniel parkes 2018-11-27 15:37:34 UTC
Created attachment 1508935 [details]
Heat template env files

Comment 9 Steve Baker 2019-01-28 21:51:55 UTC
Currently the ovn detection[1] depends on the string 'ovn' being found in the NeutronMechanismDrivers parameter.

Can you confirm that your NeutronMechanismDrivers parameter has this, and that this logic is appropriate for the OVS->OVN migration flow?

[1] http://git.openstack.org/cgit/openstack/tripleo-common/tree/tripleo_common/image/kolla_builder.py#n108

Comment 10 Steve Baker 2019-03-21 22:53:32 UTC
Do you have any updates on this?

Comment 11 Alex Schultz 2019-06-20 22:36:41 UTC
Closing bug due to lack of updates. If this problem still exists, please provide the additional information requested.


Note You need to log in before you can comment on or make changes to this bug.