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
