Open Stack

Mark's suggestion works for me as well. If no one objects, I am going to 
start the implementation.

Thanks,
Xu Han

On 09/27/2014 01:05 AM, Mark McClain wrote:
>
> On Sep 26, 2014, at 2:39 AM, Xu Han Peng <pengxuhan at gmail.com 
> <mailto: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?
>>
>
> 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
> 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/20140929/df6207e7/attachment.html>