[Bug 2126923] Re: ovn_dhcp4_global_options doesn't support keys with a list of values

[Matthew Ruffell]

Uploaded to questing, thanks.

Uploading neutron_27.0.0-0ubuntu1.1.dsc
Uploading neutron_27.0.0-0ubuntu1.1.debian.tar.xz
Uploading neutron_27.0.0-0ubuntu1.1_source.buildinfo
Uploading neutron_27.0.0-0ubuntu1.1_source.changes

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to neutron in Ubuntu.
https://bugs.launchpad.net/bugs/2126923

Title:
  ovn_dhcp4_global_options doesn't support keys with a list of values

Status in Ubuntu Cloud Archive:
  In Progress
Status in Ubuntu Cloud Archive caracal series:
  In Progress
Status in Ubuntu Cloud Archive dalmatian series:
  In Progress
Status in Ubuntu Cloud Archive epoxy series:
  In Progress
Status in Ubuntu Cloud Archive flamingo series:
  In Progress
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Committed
Status in neutron source package in Noble:
  In Progress
Status in neutron source package in Questing:
  In Progress

Bug description:
  [ Impact ]

   * The Neutron configuration option `ovn_dhcp4_global_options` does not 
     correctly support multiple values for DHCP keys. When multiple values are 
     specified the neutron-server fails while parsing the configuration and does
     not start.

   * Backporting this fix would allow users to list multiple values in the 
     `ovn_dhcp4_global_options` without requiring configuration workarounds.

   * The uploaded fix allows the config file, `ml2_conf.ini`, to correctly handle 
     multiple values in `ovn_dhcp4_global_options`.

  [ Test Plan ]

   * [0] The following versions of Ubuntu-OpenStack will be tested
         - UCA: jammy-caracal
         - UCA: noble-dalmatian
         - UCA: noble-epoxy
         - UCA: noble-flamingo
         - LTS: noble-caracal
         - LTS: questing-flamingo

   * [1] Deploy an OpenStack environment on the target series using regress-stack
         in a multipass VM. 
         
         For Jammy/Noble, it can be set up following the instructions on the 
         regress-stack README.md. 
         
         For Questing, follow these instructions:
         https://github.com/canonical/se-wiki/wiki/Regress-Stack-How-to
   
   * [2] Check the status of the neutron server to see that it is active/running
         Jammy/Noble: sudo systemctl status neutron-server
         Questing: sudo systemctl status neutron-rpc-server.service
   
   * [3] Edit the `ml2_conf.ini` file and change `ovn_dhcp4_global_options` to
         contain multiple values like `ovn_dhcp4_global_options = foo.bar;baz.qux`
   
   * [4] Stop the neutron-server
         Jammy/Noble: sudo systemctl stop neutron-server
         Questing: sudo systemctl stop neutron-rpc-server.service

   * [5] Start the neutron-server and watch it fail to start
         Jammy/Noble: sudo systemctl start neutron-server
         Questing: sudo systemctl start neutron-rpc-server.service

   * [6] Apply the patch.
     
   * [7] Stop, start, and check status of neutron-server again.
         Before the patch, it will not start correctly. 
         After the patch, it should start correctly.

  [ Where problems could occur ]

   * This change modifies how `ovn_dhcp4_global_options` options are parsed. A
     regression could possibly cause a failure to apply DHCP options all together
     due to an incorrect formatting in options sent to OVN.

  [ Other Info ]

   * Upstream commit to neutron (master): 
     https://review.opendev.org/c/openstack/neutron/+/963944 

  ===========================================================

  [ Original Bug Description ]

  
  When using `ovn_dhcp4_global_options` under `[ovn]` in `ml2_conf.ini` it will cause `neutron server` to crash when attempting to parse the configuration if a key provided contains a list seperated by commas.

  For example if setting `domain_search_list` with more than one domain.

  ```
  [ovn]
  ovn_dhcp4_global_options = domain_search_list:foo.bar,baz.qux
  ```

  Expected output would be that `neutron server` doesn't crash when
  attempting to parse such configuration and correctly applies these
  options within `OVN`.

  Experienced within OpenStack Epoxy.

  Not currently blocking anything as it is possible to patch
  `_get_ovn_dhcpv4_opts` in
  `neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py` with
  the following

  ```
  options['domain_search_list'] = "\"foo.bar,baz.qux\""
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/2126923/+subscriptions