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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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 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:
18 matches
Mail list logo
