Open Stack

Robert,

I think the CLI will look something like based on Mark's suggestion:

neutron port-create extra_dhcp_opts 
opt_name=<dhcp_option_name>,opt_value=<value>,version=4(or 6) <network>

This extra_dhcp_opts can be repeated and version is optional (no version 
means version=4).

Xu Han

On 09/29/2014 08:51 PM, Robert Li (baoli) wrote:
> Hi Xu Han,
>
> My question is how the CLI user interface would look like to 
> distinguish between v4 and v6 dhcp options?
>
> Thanks,
> Robert
>
> On 9/28/14, 10:29 PM, "Xu Han Peng" <pengxuhan at gmail.com 
> <mailto:pengxuhan at gmail.com>> wrote:
>
>     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
>>>     <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.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> 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/20140930/d3ae6de0/attachment.html>