Open Stack

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.ubuntu at cack.org.uk> wrote:

> On 21 January 2014 22:46, Veiga, Anthony <Anthony_Veiga at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/8bb8c8dc/attachment.html>