Open Stack

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 <pengxuhan at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140926/1599e82f/attachment.html>