Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote: In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Yes - that is the intent. I just have to fix an issue with the DB column definitions, so that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Excellent! Thanks for your confirmation, Sean! On Feb 2, 2014, at 12:53 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote: In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Yes - that is the intent. I just have to fix an issue with the DB column definitions, so that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ 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] A pair of mode keywords
I just submitted dnsmasq related code to gerrit: https://review.openstack.org/70649 This submission intended to implement “ipv6-two-attributes” BP and other three blueprints (SLAAC, DHCPv6-Stateful, DHCPv6-Stateless) rooted from it. Please review and let me know what you think. Thanks in advance! Shixiong On Feb 2, 2014, at 12:53 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: On Sat, Feb 01, 2014 at 01:18:09AM -0500, Shixiong Shang wrote: In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Yes - that is the intent. I just have to fix an issue with the DB column definitions, so that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ 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] A pair of mode keywords
Hi, Sean: Thanks a bunch for the new code. I glimpsed it through once and if I understand it correctly, the value of the two parameters are saved as the attributes of a subnet. In other words, I can retrieve the values by: subnet.ipv6_ra_mode subnet.ipv6_address_mode Is that correct? Would you please confirm? Thanks and have a great weekend! Shixiong On Jan 30, 2014, at 6:59 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: I just pushed a new patch that adds the two new attributes to Subnets. https://review.openstack.org/#/c/52983/ It's a very rough draft - but I wanted to get it out the door so people had sufficient time to take a look, so we can discuss at the next IRC meeting. -- Sean M. Collins ___ 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] A pair of mode keywords
I just pushed a new patch that adds the two new attributes to Subnets. https://review.openstack.org/#/c/52983/ It's a very rough draft - but I wanted to get it out the door so people had sufficient time to take a look, so we can discuss at the next IRC meeting. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I vote address them (ipv6_). There's no guarantee of forward compatibility with a new protocol and this way it can't be confused with a (non-existant) selection method for IPv4, either. Also, future updates of other protocols would require a new attribute and break the API less. -Anthony OK - any suggestions for the names of API attributes? The PDF[0] shared does not specify the names of the attributes, so I had two ideas for the names of the two new attributes being added to the Subnet resource: Either prefix them with ipv6 * ipv6_ra_mode * ipv6_address_mode Or don't prefix them: * ra_mode * address_mode Thoughts? [0]: https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf -- Sean M. Collins ___ 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] A pair of mode keywords
Any decisions yet? Shixiong On Jan 23, 2014, at 7:45 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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 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] A pair of mode keywords
Shixiong, I'm fine with the current two modes design. — Xu Han Peng (xuhanp) On Sat, Jan 25, 2014 at 5:17 AM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any decisions yet? Shixiong On Jan 23, 2014, at 7:45 AM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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 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] A pair of mode keywords
An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
An openstack deployment with an external DHCP server is definetely a possible scenario; I don't think it can be implemented out-of-the-box with the components provided by the core openstack services, but it should be doable and a possibly even a requirement for deployments which integrate openstack with systems such as Infoblox. Therefore I would not disregard the possibility of an external DHCP server. Regarding the new attributes, I pretty much agree on them. As there's overlap between enable_dhcp and address_mode, it might be worth defining a strategy for deprecating enable_dhcp by adding inclduing also a 'dhcpv4' valid value for this attribute. We were initially intending to treat enable_dhcp as an on-off flag for IPv6. If it's off, then we won't even bother with the other two attributes. Because of the issues already being discussed elsewhere in Neutron, you can't assign multiple scopes to a subnet so it's safe to assume that there won't be an IPv4 scope in an IPv6 subnet. Salvatore On 23 January 2014 04:21, Shixiong Shang sparkofwisdom.cl...@gmail.commailto:sparkofwisdom.cl...@gmail.com wrote: Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] A pair of mode keywords
On 21 January 2014 22:46, Veiga, Anthony anthony_ve...@cable.comcast.comwrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) So how does this work if I have an external DHCPv6 server and an internal router? (How baroque do we have to get?) enable_dhcp, for backward compatibility reasons, should probably disable *both* RA and DHCPv6, despite the name, so we can't use that to disable the DHCP server. We could add a *third* attribute, which I hate as an idea but does resolve the problem - one flag for each of the servers, one for the mode the servers are operating in, and enable_dhcp which needs to DIAF but will persist till the API is revved. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Sean, I agree with you. I prefer OpenStack as the single source of truth. What end user chooses may be different. But with this pair of keywords, at least we provide comprehensive coverage on all scenarios. For Icehouse, I suggest we only consider the supports for the scenarios that OpenStack has full control of address assignment, plus one or two scenarios Comcast needs, in order to cover most of the deployments. We can leave other cases for future releases, or professional service opportunities. Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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] A pair of mode keywords
That is correct, Xu Han! On Jan 22, 2014, at 11:14 AM, Xuhan Peng pengxu...@gmail.com wrote: Ian, I think the last two attributes PDF from Shixiong's last email is trying to solve the problem you are saying, right? — Xu Han Peng (xuhanp) On Wed, Jan 22, 2014 at 8:15 PM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 21 January 2014 22:46, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) So how does this work if I have an external DHCPv6 server and an internal router? (How baroque do we have to get?) enable_dhcp, for backward compatibility reasons, should probably disable *both* RA and DHCPv6, despite the name, so we can't use that to disable the DHCP server. We could add a *third* attribute, which I hate as an idea but does resolve the problem - one flag for each of the servers, one for the mode the servers are operating in, and enable_dhcp which needs to DIAF but will persist till the API is revved. -- Ian. ___ 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] A pair of mode keywords
Any possibility we can nail the keywords in the next 12 - 24 hrs? So we can decide the scope in Icehouse release and then, discuss who can do what? Shixiong On Jan 22, 2014, at 11:20 AM, Collins, Sean sean_colli...@cable.comcast.com wrote: I don't know if it's reasonable to expect a deployment of OpenStack that has an *external* DHCP server. It's certainly hard to imagine how you'd get the Neutron API and an external DHCP server to agree on an IP assignment, since OpenStack expects to be the source of truth. -- Sean M. Collins ___ 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] A pair of mode keywords
I don't see a second new attribute being proposed - I only see one new one and the existing enable_dhcp attribute. Can we get a writeup of what is being proposed? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
Hi, Anthony: I think we are saying the same thing. Yes, there must be two parameters, and they are independent. What I mean of simplifying referred to the CLI. If user provides RA mode, then the 2nd parameter will have default value if user doesn't specify it. However, user can also indicate different value explicitly. The use cases you pointed out are also called out in the table attached to the end of the email. Anything caught your eyes? Thanks, Anthony! Shixiong On Jan 21, 2014, at 4:46 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) This I agree with. In other words, the original “on” mode captured in “enable_dhcp should provide more granularity. Since the bits in RA will trigger VM to take certain actions (calculate address, solicit DHCPv6, etc.), I think we can simplify it by saying, if OpenStack RA Mode is slacc/dhcpv6-stateful/dhcpv6-stateless, then by default, the 2nd parameters shares the same value. Absolutely not. The reason for separating routing and addressing is because you can't assume that because one piece is present, that the other is too. If I want OpenStack to assign addresses via DHCPv6, then I set the addressing parameter to stateful. But maybe I want the RA to come from my provider network router. In that case, the RA mode is OFF. We MUST separate these, as there are other permutations as well. Thanks! Shixiong PastedGraphic-1.png On Jan 21, 2014, at 10:42 AM, Xuhan Peng pengxu...@gmail.com wrote: I think what will confuse openstack end user/admin will be the difference between the combination of RA mode=slaac, enable_dhcp=off and RA mode=dhcpv6_stateless, enable_dhcp=off. The only difference will be if getting optional info from external DHCPv6 server using DHCPv6 stateless but it's hard to tell from the RA mode unless the admin is very familiar with dnsmasq. I think we are trying to isolate the detail of dnsmasq configuration from the API attribute here based on our previous discussion, but I could not figure out a better mode name here too. Just want to point out this before going to bed. Will be back tomorrow and check on other ones' input on this. On Tue, Jan 21, 2014 at 10:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Begin forwarded message: From: Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today at 4pm EST Date: January 17, 2014 at 3:09:56 PM EST To: Veiga, Anthony anthony_ve...@cable.comcast.com Cc: Ian Wells (iawells) iawe...@cisco.com Hi, Anthony and Ian: Not sure how the API discussion is going with Neutron team. Please let me know what I can help from my side. Last night, I put together this slide to summarize the possible combinations of RA mode and “enable_dhcp” keyword. It is quite clear that the current on/off boolean value won’t be sufficient. However, I think it is still possible to support this pair of keywords within IceHouse timeline while negotiating with Neutron team for more flexible approach in the next major release. If you are thinking along the same line, would you please let me know what I overlooked? Thanks! Shixiong PastedGraphic-1.png On Jan 14, 2014, at 4:47 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: OK, I see that we're back to splitting the RA and DHCP modes, though I'm not sure why - enable_dhcp is bugger all use for anything other than a flat-out disable flag, since it's a boolean, so it's not like we can make much use of it. Otherwise are we talking about whether we have an external router and/or DHCP server? Precisely this. We determined multiple times previously that there is a chance of either of these items being external to OpenStack. Where appropriate, we need to also be able to get out of the way. -- Ian. From: Veiga, Anthony anthony_ve...@cable.comcast.com Date: Tuesday, 14 January 2014 21:34 To: Ian Wells iawe...@cisco.com, Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today at
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
I created a new PDF file to show two parameters (i.e. not referring “enable_dhcp”). Here is the link. I also updated BP too. https://www.dropbox.com/s/rq8xmbruqthef38/IPv6%20Two%20Modes%20v2.0.pdf Shixiong On Jan 21, 2014, at 6:31 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Anthony: I think we are saying the same thing. Yes, there must be two parameters, and they are independent. What I mean of simplifying referred to the CLI. If user provides RA mode, then the 2nd parameter will have default value if user doesn't specify it. However, user can also indicate different value explicitly. The use cases you pointed out are also called out in the table attached to the end of the email. Anything caught your eyes? Thanks, Anthony! Shixiong On Jan 21, 2014, at 4:46 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: Hi, Sean and Xuhan: I totally agree. This is not the ultimate solution with the assumption that we had to use “enable_dhcp”. We haven’t decided the name of another parameter, however, we are open to any suggestions. As we mentioned during the meeting, the second parameter should highlight the need of addressing. If so, it should have at least four values: 1) off (i.e. address is assigned by external devices out of OpenStack control) 2) slaac (i.e. address is calculated based on RA sent by OpenStack dnsmasq) 3) dhcpv6-stateful (i.e. address is obtained from OpenStack dnsmasq acting as DHCPv6 stateful server) 4) dhcpv6-stateless (i.e. address is calculated based on RA sent from either OpenStack dnsmasq, or external router, and optional information is retrieved from OpenStack dnsmasq acting as DHCPv6 stateless server) This I agree with. In other words, the original “on” mode captured in “enable_dhcp should provide more granularity. Since the bits in RA will trigger VM to take certain actions (calculate address, solicit DHCPv6, etc.), I think we can simplify it by saying, if OpenStack RA Mode is slacc/dhcpv6-stateful/dhcpv6-stateless, then by default, the 2nd parameters shares the same value. Absolutely not. The reason for separating routing and addressing is because you can't assume that because one piece is present, that the other is too. If I want OpenStack to assign addresses via DHCPv6, then I set the addressing parameter to stateful. But maybe I want the RA to come from my provider network router. In that case, the RA mode is OFF. We MUST separate these, as there are other permutations as well. Thanks! Shixiong PastedGraphic-1.png On Jan 21, 2014, at 10:42 AM, Xuhan Peng pengxu...@gmail.com wrote: I think what will confuse openstack end user/admin will be the difference between the combination of RA mode=slaac, enable_dhcp=off and RA mode=dhcpv6_stateless, enable_dhcp=off. The only difference will be if getting optional info from external DHCPv6 server using DHCPv6 stateless but it's hard to tell from the RA mode unless the admin is very familiar with dnsmasq. I think we are trying to isolate the detail of dnsmasq configuration from the API attribute here based on our previous discussion, but I could not figure out a better mode name here too. Just want to point out this before going to bed. Will be back tomorrow and check on other ones' input on this. On Tue, Jan 21, 2014 at 10:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Begin forwarded message: From: Shixiong Shang sparkofwisdom.cl...@gmail.com Subject: Re: Cannot make it today at 4pm EST Date: January 17, 2014 at 3:09:56 PM EST To: Veiga, Anthony anthony_ve...@cable.comcast.com Cc: Ian Wells (iawells) iawe...@cisco.com Hi, Anthony and Ian: Not sure how the API discussion is going with Neutron team. Please let me know what I can help from my side. Last night, I put together this slide to summarize the possible combinations of RA mode and “enable_dhcp” keyword. It is quite clear that the current on/off boolean value won’t be sufficient. However, I think it is still possible to support this pair of keywords within IceHouse timeline while negotiating with Neutron team for more flexible approach in the next major release. If you are thinking along the same line, would you please let me know what I overlooked? Thanks! Shixiong PastedGraphic-1.png On Jan 14, 2014, at 4:47 PM, Veiga, Anthony anthony_ve...@cable.comcast.com wrote: OK, I see that we're back to splitting the RA and DHCP modes, though I'm not sure why - enable_dhcp is bugger all use for anything other than a flat-out disable flag, since it's a boolean, so it's not like we can make much use of it. Otherwise are we talking about whether we have an external router and/or DHCP server? Precisely this. We determined multiple times previously that there is a chance of either of these items being
