Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords

2014-02-02 Thread Collins, Sean
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

2014-02-02 Thread Shixiong Shang
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

2014-02-02 Thread Shixiong Shang
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

2014-01-31 Thread Shixiong Shang
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

2014-01-30 Thread Collins, Sean
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

2014-01-27 Thread Collins, Sean
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


Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords

2014-01-27 Thread Veiga, Anthony
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

2014-01-27 Thread Shixiong Shang
+1 for the ones “ipv6_” prefix.





On Jan 27, 2014, at 1:15 PM, Veiga, Anthony anthony_ve...@cable.comcast.com 
wrote:

 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


___
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

2014-01-24 Thread Shixiong Shang
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

2014-01-24 Thread Xuhan Peng
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

2014-01-23 Thread Salvatore Orlando
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

2014-01-23 Thread Veiga, Anthony

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

2014-01-22 Thread Ian Wells
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

2014-01-22 Thread Xuhan Peng
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.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

2014-01-22 Thread Collins, Sean
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

2014-01-22 Thread Shixiong Shang
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

2014-01-22 Thread Shixiong Shang
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

2014-01-22 Thread Shixiong Shang
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

2014-01-21 Thread Collins, Sean
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

2014-01-21 Thread Shixiong Shang
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

2014-01-21 Thread Shixiong Shang
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