On Sep 26, 2014, at 2:39 AM, Xu Han Peng <[email protected]> wrote:
> 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?
>
I’m -1 for both options because neither is properly backwards compatible.
Instead we should add an optional 3rd value to the dictionary: “version”. The
version key would be used to make the option only apply to either version 4 or
6. If the key is missing or null, then the option would apply to both.
mark
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
