Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
On Wed, Dec 18, 2013 at 10:29:35PM -0500, Shixiong Shang wrote: It is up to Sean to make the call, but I would love to see IBM team in the meeting. Agreed - If we can find a time that works for USA, Europe and China that would be great. How good/bad is 1500 UTC? I don't trust my math :) -- 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] Three SLAAC and DHCPv6 related blueprints
Perfect! Will you be at the IRC meeting to discuss these? I've added them to the agenda in the hopes that we can discuss -- 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] Three SLAAC and DHCPv6 related blueprints
I will surely be there this afternoon, Sean! Look forward to it! On Dec 19, 2013, at 12:22 PM, Collins, Sean sean_colli...@cable.comcast.com wrote: Perfect! Will you be at the IRC meeting to discuss these? I've added them to the agenda in the hopes that we can discuss -- 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] Three SLAAC and DHCPv6 related blueprints
Xuhan, check the other thread - would 1500UTC suit? On 19 December 2013 01:09, Xuhan Peng pengxu...@gmail.com wrote: Shixiong and guys, The sub team meeting is too early for china IBM folks to join although we would like to participate the discussion very much. Any chance to rotate the time so we can comment? Thanks, Xuhan On Thursday, December 19, 2013, Shixiong Shang wrote: Hi, Ian: I agree with you on the point that the way we implement it should be app agnostic. In addition, it should cover both CLI and Dashboard, so the system behavior should be consistent to end users. The keywords is just one of the many ways to implement the concept. It is based on the reality that dnsmasq is the only driver available today to the community. By the end of the day, the input from customer should be translated to one of those mode keywords. It doesn't imply the same constants have to be used as part of the CLI or Dashboard. Randy and I had lengthy discussion/debating about this topic today. We have straw-man proposal and will share with the team tomorrow. That being said, what concerned me the most at this moment is, we are not on the same page. I hope tomorrow during sub-team meeting, we can reach consensus. If you can not make it, then please set up a separate meeting to invite key placeholders so we have a chance to sort it out. Shixiong On Dec 18, 2013, at 8:25 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Ian, thanks for asking! I replied in the other thread. It works for me! On Fri, Dec 20, 2013 at 8:23 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: Xuhan, check the other thread - would 1500UTC suit? On 19 December 2013 01:09, Xuhan Peng pengxu...@gmail.com wrote: Shixiong and guys, The sub team meeting is too early for china IBM folks to join although we would like to participate the discussion very much. Any chance to rotate the time so we can comment? Thanks, Xuhan On Thursday, December 19, 2013, Shixiong Shang wrote: Hi, Ian: I agree with you on the point that the way we implement it should be app agnostic. In addition, it should cover both CLI and Dashboard, so the system behavior should be consistent to end users. The keywords is just one of the many ways to implement the concept. It is based on the reality that dnsmasq is the only driver available today to the community. By the end of the day, the input from customer should be translated to one of those mode keywords. It doesn't imply the same constants have to be used as part of the CLI or Dashboard. Randy and I had lengthy discussion/debating about this topic today. We have straw-man proposal and will share with the team tomorrow. That being said, what concerned me the most at this moment is, we are not on the same page. I hope tomorrow during sub-team meeting, we can reach consensus. If you can not make it, then please set up a separate meeting to invite key placeholders so we have a chance to sort it out. Shixiong On Dec 18, 2013, at 8:25 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- 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 ___ 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] Three SLAAC and DHCPv6 related blueprints
Hey Shixiong, This is intended as a replacement for [1], correct? Do you have code for this already, or should we work with Sean's patch? There's a discussion document at [2], which is intended to be more specific behind the reasoning for the choices we make, and the interface offered to the user for these features. I'd be grateful if you could read and comment on it. -- Ian. [1] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword [2] https://docs.google.com/document/d/1rOBOOu_OwixMStm6XJOb5PKkJA6eFbL_XCE7wlTfaPY On 18 December 2013 04:19, Randy Tuttle randy.m.tut...@gmail.com wrote: Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing the modes via the neutron client cli, but have we seen how those modes are provided through the dashboard? Randy Sent from my iPhone On Dec 17, 2013, at 9:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ 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] Three SLAAC and DHCPv6 related blueprints
Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. Let us discuss that on Thursday’s IRC meeting. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. Thank you for sharing! Shixiong On Dec 18, 2013, at 6:30 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: Hey Shixiong, This is intended as a replacement for [1], correct? Do you have code for this already, or should we work with Sean's patch? There's a discussion document at [2], which is intended to be more specific behind the reasoning for the choices we make, and the interface offered to the user for these features. I'd be grateful if you could read and comment on it. -- Ian. [1] https://blueprints.launchpad.net/neutron/+spec/dnsmasq-mode-keyword [2] https://docs.google.com/document/d/1rOBOOu_OwixMStm6XJOb5PKkJA6eFbL_XCE7wlTfaPY On 18 December 2013 04:19, Randy Tuttle randy.m.tut...@gmail.com wrote: Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing the modes via the neutron client cli, but have we seen how those modes are provided through the dashboard? Randy Sent from my iPhone On Dec 17, 2013, at 9:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ 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] Three SLAAC and DHCPv6 related blueprints
On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.comwrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- 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] Three SLAAC and DHCPv6 related blueprints
Shixiong and guys,
The sub team meeting is too early for china IBM folks to join although we
would like to participate the discussion very much. Any chance to rotate
the time so we can comment?
Thanks, Xuhan
On Thursday, December 19, 2013, Shixiong Shang wrote:
Hi, Ian:
I agree with you on the point that the way we implement it should be app
agnostic. In addition, it should cover both CLI and Dashboard, so the
system behavior should be consistent to end users.
The keywords is just one of the many ways to implement the concept. It is
based on the reality that dnsmasq is the only driver available today to the
community. By the end of the day, the input from customer should be
translated to one of those mode keywords. It doesn't imply the same
constants have to be used as part of the CLI or Dashboard.
Randy and I had lengthy discussion/debating about this topic today. We
have straw-man proposal and will share with the team tomorrow.
That being said, what concerned me the most at this moment is, we are not
on the same page. I hope tomorrow during sub-team meeting, we can reach
consensus. If you can not make it, then please set up a separate meeting to
invite key placeholders so we have a chance to sort it out.
Shixiong
On Dec 18, 2013, at 8:25 AM, Ian Wells
ijw.ubu...@cack.org.ukjavascript:_e({}, 'cvml', 'ijw.ubu...@cack.org.uk');
wrote:
On 18 December 2013 14:10, Shixiong Shang
sparkofwisdom.cl...@gmail.comjavascript:_e({}, 'cvml',
'sparkofwisdom.cl...@gmail.com');
wrote:
Hi, Ian:
I won’t say the intent here is to replace dnsmasq-mode-keyword BP.
Instead, I was trying to leverage and enhance those definitions so when
dnsmasq is launched, it knows which mode it should run in.
That being said, I see the value of your points and I also had lengthy
discussion with Randy regarding this. We did realize that the keyword
itself may not be sufficient to properly configure dnsmasq.
I think the point is that the attribute on whatever object (subnet or
router) that defines the behaviour should define the behaviour, in
precisely the terms you're talking about, and then we should find the
dnsmasq options to suit. Talking to Sean, he's good with this too, so
we're all working to the same ends and it's just a matter of getting code
in.
Let us discuss that on Thursday’s IRC meeting.
Not sure if I'll be available or not this Thursday, unfortunately. I'll
try to attend but I can't make promises.
Randy and I had a quick glance over your document. Much of it parallels
the work we did on our POC last summer, and is now being addressed across
multiple BP being implemented by ourselves or with Sean Collins and IBM
team's work. I will take a closer look and provide my comments.
That's great. I'm not wedded to the details in there, I'm actually more
interested that we've covered everything.
If you have blueprint references, add them as comments - the
ipv6-feature-parity BP could do with work and if we get the links together
in one place we can update it.
--
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org javascript:_e({}, 'cvml',
'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] Three SLAAC and DHCPv6 related blueprints
It is up to Sean to make the call, but I would love to see IBM team in the meeting. On Dec 18, 2013, at 7:09 PM, Xuhan Peng pengxu...@gmail.com wrote: Shixiong and guys, The sub team meeting is too early for china IBM folks to join although we would like to participate the discussion very much. Any chance to rotate the time so we can comment? Thanks, Xuhan On Thursday, December 19, 2013, Shixiong Shang wrote: Hi, Ian: I agree with you on the point that the way we implement it should be app agnostic. In addition, it should cover both CLI and Dashboard, so the system behavior should be consistent to end users. The keywords is just one of the many ways to implement the concept. It is based on the reality that dnsmasq is the only driver available today to the community. By the end of the day, the input from customer should be translated to one of those mode keywords. It doesn't imply the same constants have to be used as part of the CLI or Dashboard. Randy and I had lengthy discussion/debating about this topic today. We have straw-man proposal and will share with the team tomorrow. That being said, what concerned me the most at this moment is, we are not on the same page. I hope tomorrow during sub-team meeting, we can reach consensus. If you can not make it, then please set up a separate meeting to invite key placeholders so we have a chance to sort it out. Shixiong On Dec 18, 2013, at 8:25 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 18 December 2013 14:10, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, Ian: I won’t say the intent here is to replace dnsmasq-mode-keyword BP. Instead, I was trying to leverage and enhance those definitions so when dnsmasq is launched, it knows which mode it should run in. That being said, I see the value of your points and I also had lengthy discussion with Randy regarding this. We did realize that the keyword itself may not be sufficient to properly configure dnsmasq. I think the point is that the attribute on whatever object (subnet or router) that defines the behaviour should define the behaviour, in precisely the terms you're talking about, and then we should find the dnsmasq options to suit. Talking to Sean, he's good with this too, so we're all working to the same ends and it's just a matter of getting code in. Let us discuss that on Thursday’s IRC meeting. Not sure if I'll be available or not this Thursday, unfortunately. I'll try to attend but I can't make promises. Randy and I had a quick glance over your document. Much of it parallels the work we did on our POC last summer, and is now being addressed across multiple BP being implemented by ourselves or with Sean Collins and IBM team's work. I will take a closer look and provide my comments. That's great. I'm not wedded to the details in there, I'm actually more interested that we've covered everything. If you have blueprint references, add them as comments - the ipv6-feature-parity BP could do with work and if we get the links together in one place we can update it. -- 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] Three SLAAC and DHCPv6 related blueprints
Great Shixiong. I can see that we have BPs from Sean / Da Zhao for providing the modes via the neutron client cli, but have we seen how those modes are provided through the dashboard? Randy Sent from my iPhone On Dec 17, 2013, at 9:07 PM, Shixiong Shang sparkofwisdom.cl...@gmail.com wrote: Hi, team: I created a new blueprint to reflect the work we accomplished in the previous POC to enable dnsmasq in SLAAC mode. In addition, I took the action item two weeks ago from weekly sub-team meeting to explore DHCPv6 options. The goal was to run dnsmasq as DHCPv6 server and provide both optional information and/or IPv6 address to VM in the tenant network. Below you can find the link to the new blueprints, which are all related to the mid-term goal in Sean’s original proposal. https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-slaac https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateful https://blueprints.launchpad.net/neutron/+spec/dnsmasq-ipv6-dhcpv6-stateless Please let me know if you have any questions. Thanks! Shixiong ___ 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
