Open Stack

Currently the extra_dhcp_opts has the following API interface on a port:

{
     "port":
     {
         "extra_dhcp_opts": [
             {"opt_value": "testfile.1","opt_name": "bootfile-name"},
             {"opt_value": "123.123.123.123", "opt_name": "tftp-server"},
             {"opt_value": "123.123.123.45", "opt_name": 
"server-ip-address"}
         ],
         ....
      }
}

During the development of DHCPv6 function for IPv6 subnets, we found 
this format doesn't work anymore because an port can have both IPv4 and 
IPv6 address. So we need to find a new way to specify extra_dhcp_opts 
for DHCPv4 and DHCPv6, respectively. ( 
https://bugs.launchpad.net/neutron/+bug/1356383)

Here are some thoughts about the new format:

Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or 
v6) so we can distinguish opts for v4 or v6 by parsing the opt_name. For 
backward compatibility, no prefix means IPv4 dhcp opt.

         "extra_dhcp_opts": [
             {"opt_value": "testfile.1","opt_name": "bootfile-name"},
             {"opt_value": "123.123.123.123", "opt_name": 
"*v4:*tftp-server"},
             {"opt_value": "[2001:0200:feed:7ac0::1]", "opt_name": 
"*v6:*dns-server"}
         ]

Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For 
backward compatibility, both old format and new format are acceptable, 
but old format means IPv4 dhcp opts.

         "extra_dhcp_opts": {
              "ipv4": [
                     {"opt_value": "testfile.1","opt_name": 
"bootfile-name"},
                     {"opt_value": "123.123.123.123", "opt_name": 
"tftp-server"},
              ],
              "ipv6": [
                     {"opt_value": "[2001:0200:feed:7ac0::1]", 
"opt_name": "dns-server"}
              ]
         }

The pro of Option1 is there is no need to change API structure but only 
need to add validation and parsing to opt_name. The con of Option1 is 
that user need to input prefix for every opt_name which can be error 
prone. The pro of Option2 is that it's clearer than Option1. The con is 
that we need to check two formats for backward compatibility.

We discussed this in IPv6 sub-team meeting and we think Option2 is 
preferred. Can I also get community's feedback on which one is preferred 
or any other comments?

Thanks,
Xu Han
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140926/47b2ce90/attachment.html>