Description of problem: Our "NETWORKING WITH OPEN VIRTUAL NETWORK" Guide [1] is focused on overcloud deployments with ML2/OVN mechanism driver. On the other hand, ML2/OVN is default mechanism driver in RHOSP 16. As a result, some customers would deploy their overclouds without providing any additional OVN-related environment files. It looks like that in this case they will get semi-functional overcloud because OVNCMSOptions would not be defined for controller role and OVN routers could be scheduled on Compute node, which doesn't have br-ex. One of the customers reported such situation, which would be fixed by adding definitions like [2], but this still looks like a valid bug... [1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html-single/networking_with_open_virtual_network/index#deploying-dvr-ovn [2] parameter_defaults: NeutronMechanismDrivers: ovn OVNVifType: ovs OVNNeutronSyncMode: log OVNQosDriver: ovn-qos NeutronTypeDrivers: 'geneve,vlan,flat' NeutronNetworkType: ['geneve' , 'vlan', 'flat'] NeutronServicePlugins: 'qos,ovn-router,trunk,segments' NeutronVniRanges: ['1:65536', ] NeutronPluginExtensions: "qos,port_security,dns" NeutronRpcWorkers: 1 ControllerParameters: OVNCMSOptions: "enable-chassis-as-gw"
This is specific to network deployment not the framework itself, moving to Networking DFG.
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 (Moderate: Red Hat OpenStack 16.1.9 (openstack-tripleo-heat-templates) security update), 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/RHSA-2022:8796