Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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?
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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.commailto: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.commailto: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.commailto: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.orgmailto:OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.orghttp://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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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.commailto: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.commailto: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.orgmailto:OpenStack-dev@lists.openstack.orghttp://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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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
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.orghttp://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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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
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] [neutron] [IPv6] New API format for extra_dhcp_opts
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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
Germy,
We considered this but not all option are address based, therefore we
cannot determine the IP version by opt value only.
I am not familiar about how the format was original determined either.
Maybe someone who works on this format before can help clarify?
Xu Han
On 09/26/2014 03:17 PM, Germy Lure wrote:
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
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?
Thanks,
Xu Han
___
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
Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts
On Sep 26, 2014, at 2:39 AM, 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?
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
