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 advan
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 cor
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,
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
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
__
+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 u
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 -
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
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 definetel
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 servic
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 opens
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
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
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
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 h
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
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 tota
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 mention
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 ar
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
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:/
21 matches
Mail list logo
