Thanks guys for the heads up Indeed making it backwards compat by adding the "[ip_]version" key to the dictionary sounds like the best way to go.
Cheers, Lucas On Thu, Oct 2, 2014 at 3:53 AM, Carlino, Chuck <chuck.carl...@hp.com> wrote: > As a 'heads up', adding ironic to the thread since they are a 'key' consumer > of this api. > > > On Oct 1, 2014, at 3:15 AM, Xu Han Peng > <pengxu...@gmail.com<mailto:pengxu...@gmail.com>> wrote: > > ip_version sounds great. > > Currently the opt-names are written into the configuration file of dnsmasq > directly. So I would say yes, they are coming from dnsmasq definitions. > > It will make more sense when ip_version is missing or null, the option apply > to both since we could have only ipv6 or ipv4 address on the port. However, > the validation of opt-value should rule out the ones which are not suitable > for the current address. For example, an IPv6 dns server should not be > specified for IPv4 address port, etc... > > Xu Han > > On 09/30/2014 08:41 PM, Robert Li (baoli) wrote: > Xu Han, > > That looks good to me. To keep it consistent with existing CLI, we should use > ip-version instead of ‘version’. It seems to be identical to prefixing the > option_name with v4 or v6, though. > > Just to clarify, are the available opt-names coming from dnsmasq definitions? > > With regard to the default, your suggestion "version is optional (no version > means version=4)." seems to be different from Mark’s: > 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. > > Thanks, > Robert > > On 9/30/14, 1:46 AM, "Xu Han Peng" > <pengxu...@gmail.com<mailto:pengxu...@gmail.com>> wrote: > > 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" > <pengxu...@gmail.com<mailto:pengxu...@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 > <pengxu...@gmail.com<mailto: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? > > > 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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org<mailto: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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
