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

[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  
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

[Shixiong Shang]

Excellent! Thanks for your confirmation, Sean!


> On Feb 2, 2014, at 12:53 PM, "Collins, Sean" 
>  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

[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

[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" 
>  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

[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

[Shixiong Shang]

+1 for the ones “ipv6_” prefix.





On Jan 27, 2014, at 1:15 PM, Veiga, Anthony  
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

[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

[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

[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
 wrote:

> Any decisions yet?
> Shixiong
> On Jan 23, 2014, at 7:45 AM, Veiga, Anthony  
> 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  
>>> 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 
  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 Shang]

Any decisions yet?

Shixiong






On Jan 23, 2014, at 7:45 AM, Veiga, Anthony  
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  
>> 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 
>>>  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

[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 
mailto: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 
mailto: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

[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 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

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

[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  
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

[Shixiong Shang]

That is correct, Xu Han!



> On Jan 22, 2014, at 11:14 AM, "Xuhan Peng"  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  wrote:
>>> On 21 January 2014 22:46, Veiga, Anthony  
>>> 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

[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" 
>  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

[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

[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  wrote:

> On 21 January 2014 22:46, Veiga, Anthony 
> 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

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

[Ian Wells]

On 21 January 2014 22:46, Veiga, Anthony 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

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

[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  
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" 
>  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
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jan 21, 2014, at 10:42 AM, Xuhan Peng  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 
>>>  wrote:
>>> 
>>> 
>>> Begin forwarded message:
>>> 
 From: Shixiong Shang 
 Subject: Re: Cannot make it today at 4pm EST
 Date: January 17, 2014 at 3:09:56 PM EST
 To: "Veiga, Anthony" 
 Cc: "Ian Wells (iawells)" 
 
 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
 
 
 
 
 
 
 
 
 
 
 
 
 
 On Jan 14, 2014, at 4:47 PM, Veiga, Anthony 
  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 rou

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

[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" 
>  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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On Jan 21, 2014, at 10:42 AM, Xuhan Peng  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 
>>>  wrote:
>>> 
>>> 
>>> Begin forwarded message:
>>> 
 From: Shixiong Shang 
 Subject: Re: Cannot make it today at 4pm EST
 Date: January 17, 2014 at 3:09:56 PM EST
 To: "Veiga, Anthony" 
 Cc: "Ian Wells (iawells)" 
 
 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
 
 
 
 
 
 
 
 
 
 
 
 
 
> On Jan 14, 2014, at 4:47 PM, Veiga, Anthony 
>  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: , Anthony 
>> Date: Tuesday, 14 January 2014 21:3

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

[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