Hi, Xu Han, Can we distinguish version by parsing the opt_value? Is there any service binding v4 address but providing service for v6? or v6 for v4?
BTW, Why not the format is directly opt_name_value:opt_value_value, like " server-ip-address":"1.1.1.1"? BR, Germy On Fri, Sep 26, 2014 at 2:39 PM, Xu Han Peng <pengxu...@gmail.com> 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? > > Thanks, > Xu Han > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev