Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting
On Wed, Aug 13, 2014 at 10:05:26AM EDT, Kyle Mestery wrote: Tuesday 1400UTC How do we want to handle the overlap with the IPv6 subteam meeting? -- 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] Rotating the weekly Neutron meeting
On Wed, Aug 13, 2014 at 03:28:34PM EDT, Kevin Benton wrote: Maybe the ipv6 subteam meeting could alternate as well... OK, I can bring it up in the IRC meeting. I know our current time is early for US PST and very late for Asia, so maybe we can find a time that gives them a break :) -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator
Hi, The QoS API extension has lived in Gerrit/been in review for about a year. It's gone through revisions, summit design sessions, and for a little while, a subteam. I would like to request incubation in the upcoming incubator, so that the code will have a more permanent home where we can collaborate and improve. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Allowing Plugins in tree that explicitly do not support IPv6
Hi, The amount of tests that we are having to add skips to for the One Convergence plugin has grown quite a bit lately. http://git.openstack.org/cgit/openstack/neutron/tree/neutron/tests/unit/oneconvergence/test_nvsd_plugin.py#n58 This is the only plugin that inherits from the NeutronDbPluginV2 class and has completely disabled creating Subnets that have an ip_version of 6. http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/oneconvergence/plugin.py#n228 I hate to single out this plugin. Before this development cycle, open source plugins would allow the creation of Subnets with ip_version set to 6, and then have lots of bugs which would prevent any instances from actually obtaining IPv6 addresses and routing. But we didn't have to explicitly skip tests every time someone wanted to fix bugs - like the following patch. https://review.openstack.org/#/c/116317/ Also, I want to highlight some meeting minutes, where it was discussed that in the K release, all plugins will be required to support IPv6. I hope we can discuss this, build consensus, and ensure that the K release requirement is reasonable. http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-14-21.02.html Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Moving meeting time to 1500 UTC on Tuesdays on #openstack-meeting-alt?
Any objection? We need to move the time since the main meeting conflicts with our current time slot. Discussion from today's meeting: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-09-02-13.59.log.html -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for the meeting today
The agenda for today is pretty light - if there is anything that people would like to discuss, please feel free to add. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_12._2013 -- 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] Does any plugin require hairpinning to be enabled?
Hi, I have registered two blueprints, one in Nova and one in Neutron to make it a VIF attribute that the libvirt driver in Nova will honor. https://blueprints.launchpad.net/neutron/+spec/vif-attribute-for-hairpinning https://blueprints.launchpad.net/nova/+spec/nova-hairpin-vif-attribute -- 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] Change I5b2313ff: Create a new attribute for subnets, to store v6 dhcp options
On Tue, Dec 17, 2013 at 07:39:14PM +0100, Ian Wells wrote: 1. The patch ties Neutron's parameters specifically to dnsmasq. It would be, I think, impossible to reimplement this for isc-dhcpd, for instance. While I agree in theory with this point - there are currently no active blueprints to add another DHCP server to Neutron. The isc-dhcp one has been stalled for quite a long time. Frankly, if we can think of better names for the modes that we're looking to have happen for v6 provisioning, that doesn't rely directly on dnsmasq-isms, I'm all ears. Feel free to propose better names for the modes and we'll create a map between the modes and what you pass to dnsmasq. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for today's meeting
Hi, Agenda for today's meeting is pretty light - if you have something you'd like to discuss please add it to the wiki page https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Dec_19_2013 I would also ask that when we conduct the meeting - we stick to the agenda that has been posted, and hold any other discussions until the open discussion period. The quicker we get through the agenda, the more time we have at the end for open discussion. See you all soon! -- 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
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] Agenda for today's meeting
Minutes from the meeting: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-19-21.00.html -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Meeting time - change to 1300 UTC or 1500 UTC?
Thoughts? I know we have people who are not able to attend at our current time. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] No IRC Meeting this week
See you all next week! -- 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][Testr] Brand new checkout of Neutron... getting insane unit test run results
+1 for this - I've been seeing this error as well, when running tox -e py27 from fresh clones - I've been using tox -e py26 as a workaround. -- 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] Meeting time - change to 1300 UTC or 1500 UTC?
OK - if nobody has any objections, we'll start the new meetings up at 1500 UTC - that appears to be the time that everyone is OK with? -- 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] Meeting time - change to 1300 UTC or 1500 UTC?
Spoke too soon – I think 1500 UTC on Thursdays is already taken, we'd have to change days. -- 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][Testr] Brand new checkout of Neutron... getting insane unit test run results
It looks like the problem is that there is a dependency on pyudev which only works properly on Linux. The neutron setup_hook does properly install pyudev on Linux (explains why the tests run in the gate), but would not work properly on windows or OS X. I assume folks are trying to run the tests on not Linux? Neutron may want to do something similar to what Nova does when libvirt is not importable, https://git.openstack.org/cgit/openstack/nova/tree/nova/tests/virt/libvirt/test_libvirt.py#n77 and use a fake in order to get the tests to run properly anyways. +1 to this suggestion. I used to have a work around where I'd modify the requirements.txt to comment out the pyudev dependency, until e1165ce removed it from the requirements file. That at least allowed me to set Neutron up and run the majority of the unit tests. -- 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] Meeting time - change to 1300 UTC or 1500 UTC?
Looking at the calendar, our options for 1500 UTC require us to change the day that we meet. The following days are available: * Tuesdays * Fridays Thoughts? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Meeting Agenda - Jan 2nd 2014 2100 UTC
Happy New Year! Since we're still hashing out the logistics of changing our meeting time, we'll meet at 2100 UTC - and hopefully transition to a new meeting day and time by next week. I have created a section in the wiki for today's agenda: https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Jan_2nd Please feel free to add items to the agenda and we'll 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] Availability of external testing logs
+1 to this, there are IPv6 patches that have been -1'd by this system that I believe prevents them from being reviewed, since most people skip over changes that have a -1 from Jenkins jobs. I also attempted to Reach out mid December to the owner of Tail-F, but have not yet received a response. It is possible that he/she did reply and it got filed in the wrong folder, and I hope this is the case. https://review.openstack.org/#/q/topic:bp/dnsmasq-mode-keyword,n,z Sean M. Collins From: Dave Cahill [dcah...@midokura.com] Sent: Monday, January 06, 2014 4:36 AM To: OpenStack Development Mailing List (not for usage questions) Cc: to...@tail-f.com Subject: Re: [openstack-dev] [Neutron] Availability of external testing logs Hi, Tail-F NCS Jenkins seems to still be causing issues. It voted -1 on some patches today [1][2] which seem to be fine according to all other jobs. It gives no information on what went wrong, so it's essentially a dead end. I've CCed the owner of the job according to the list Anita posted [3], so hopefully they can disable voting. Salvatore mentioned on IRC that it might make sense to ask the infra team to nullify the access credentials for the job if no response is forthcoming from the job owner. Thanks, Dave. [1] https://review.openstack.org/#/c/48574/ [2] https://review.openstack.org/#/c/53052/ [3] https://review.openstack.org/#/admin/groups/91,members On Tue, Dec 31, 2013 at 12:24 PM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: On Mon, Dec 23, 2013 at 11:13 AM, Sean Dague s...@dague.netmailto:s...@dague.net wrote: On 12/23/2013 12:10 PM, Collins, Sean wrote: On Sun, Dec 22, 2013 at 12:30:50PM +0100, Salvatore Orlando wrote: I would suggest that external jobs should not vote until logs are publicly accessible, otherwise contributors would have no reason to understand where the negative vote came from. +1 I've had Tail-F NCS Jenkins -1 some things that the OpenStack Jenkins has +1'd, and other times where I've seen it +1 things that OpenStack Jenkins -1'd. Agreed. I also think we need to have these systems prove themselves on reliability before they post votes back. A mis configured CI system can easily -1 the entire patch stream, and many of us use -Verified-1 as a filter criteria on reviews, which effectively makes that a DOS attack. Detailed public results need to come first. After those look reliable, voting can be allowed. FYI, we are trying to record the requirements at http://ci.openstack.org/third_party.html/, patch: https://review.openstack.org/#/c/63478/ -Sean -- Sean Dague Samsung Research America s...@dague.netmailto:s...@dague.net / sean.da...@samsung.commailto:sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Availability of external testing logs
I believe we have more to lose by leaving the job with verification permissions than we do by revoking them, then reinstating them at a later point, since I-2 is at the end of this month. That way patches that are passing the gate and all other third party tests can start being reviewed by more reviewers and core members who have verification set as a filter in their queue, Sean M. Collins From: Anita Kuno [ante...@anteaya.info] Sent: Monday, January 06, 2014 8:44 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Availability of external testing logs Let me know what you consider a reasonable amount of time to continue waiting for Tail-F NCS Jenkins before we remove verification permissions from the account. We were just talking about this a few hours ago at a Birds of a Feather session. We can get permissions removed from this account. I'd just like to see agreement that we have given this account holder a reasonable amount of time to respond prior to doing so. If the account holder of this account is reading this email, responding to it would certainly be a good idea. Thanks, Anita. On 01/06/2014 08:36 PM, Collins, Sean wrote: +1 to this, there are IPv6 patches that have been -1'd by this system that I believe prevents them from being reviewed, since most people skip over changes that have a -1 from Jenkins jobs. I also attempted to Reach out mid December to the owner of Tail-F, but have not yet received a response. It is possible that he/she did reply and it got filed in the wrong folder, and I hope this is the case. https://review.openstack.org/#/q/topic:bp/dnsmasq-mode-keyword,n,z Sean M. Collins From: Dave Cahill [dcah...@midokura.com] Sent: Monday, January 06, 2014 4:36 AM To: OpenStack Development Mailing List (not for usage questions) Cc: to...@tail-f.com Subject: Re: [openstack-dev] [Neutron] Availability of external testing logs Hi, Tail-F NCS Jenkins seems to still be causing issues. It voted -1 on some patches today [1][2] which seem to be fine according to all other jobs. It gives no information on what went wrong, so it's essentially a dead end. I've CCed the owner of the job according to the list Anita posted [3], so hopefully they can disable voting. Salvatore mentioned on IRC that it might make sense to ask the infra team to nullify the access credentials for the job if no response is forthcoming from the job owner. Thanks, Dave. [1] https://review.openstack.org/#/c/48574/ [2] https://review.openstack.org/#/c/53052/ [3] https://review.openstack.org/#/admin/groups/91,members On Tue, Dec 31, 2013 at 12:24 PM, Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com wrote: On Mon, Dec 23, 2013 at 11:13 AM, Sean Dague s...@dague.netmailto:s...@dague.net wrote: On 12/23/2013 12:10 PM, Collins, Sean wrote: On Sun, Dec 22, 2013 at 12:30:50PM +0100, Salvatore Orlando wrote: I would suggest that external jobs should not vote until logs are publicly accessible, otherwise contributors would have no reason to understand where the negative vote came from. +1 I've had Tail-F NCS Jenkins -1 some things that the OpenStack Jenkins has +1'd, and other times where I've seen it +1 things that OpenStack Jenkins -1'd. Agreed. I also think we need to have these systems prove themselves on reliability before they post votes back. A mis configured CI system can easily -1 the entire patch stream, and many of us use -Verified-1 as a filter criteria on reviews, which effectively makes that a DOS attack. Detailed public results need to come first. After those look reliable, voting can be allowed. FYI, we are trying to record the requirements at http://ci.openstack.org/third_party.html/, patch: https://review.openstack.org/#/c/63478/ -Sean -- Sean Dague Samsung Research America s...@dague.netmailto:s...@dague.net / sean.da...@samsung.commailto:sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
[openstack-dev] [Neutron][IPv6] Meeting time - change to Tuesdays at 1500 UTC
I think we've got consensus. See everyone tomorrow at 1500 UTC in #openstack-meeting-alt -- 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] Availability of external testing logs
How should we handle existing -1's that have been posted? -- 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] Several topics for tomorrow's meeting
I will make sure to add these items to the agenda. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Meeting time - now Tuesdays at 1400 UTC in #openstack-meeting
The 1500 UTC time conflicts with Marconi, although the time was not listed on the Meetings wikipage. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Reminder - new meeting time day - Tuesday 1400UTC
In #openstack-meeting -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Subnet mode - API extension or change to core API?
Hi, I posted a message to the mailing list[1] when I first began work on the subnet mode keyword, asking if anyone had a suggestion about if it should be an API extension or can be a change to the core API. I don't know if adding the dhcp_mode attribute to Subnets should be considered an API extension (and the code should be converted to an API extension) or if we're simply specifying behavior that was originally undefined. In the months since, we have iterated on the commit, and have continued working on IPv6 functionality in Neutron. Nachi recently -1'd the review[2], saying that it needs to be an API extension. I disagree that it should be an API extension, since I have added behavior that sets the subnet_mode keyword to default with the attribute is not specified, for backwards compatibility. Any plugin that inherits from the NeutronDbPluginV2 class will have backwards compatibility. Suggestions? [1]: http://lists.openstack.org/pipermail/openstack-dev/2013-October/017087.html [2]: https://review.openstack.org/#/c/52983/ -- 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][Testr] Brand new checkout of Neutron... getting insane unit test run results
On Wed, Jan 01, 2014 at 07:56:22PM -0800, Clark Boylan wrote: It looks like the problem is that there is a dependency on pyudev which only works properly on Linux. The neutron setup_hook does properly install pyudev on Linux (explains why the tests run in the gate), but would not work properly on windows or OS X. I assume folks are trying to run the tests on not Linux? Neutron may want to do something similar to what Nova does when libvirt is not importable, https://git.openstack.org/cgit/openstack/nova/tree/nova/tests/virt/libvirt/test_libvirt.py#n77 and use a fake in order to get the tests to run properly anyways. Thanks for pointing this out - I've begun work on doing this, and that link was very helpful for figuring out what would need to be done. -- 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] Availability of external testing logs
Can we get the -1 from Tail-F cleared from this review? https://review.openstack.org/#/c/56184/17 -- 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] Availability of external testing logs
Yeah - it appears that even if you clear a -1 the countdown clock still keeps ticking, one of my reviews[0] just expired this morning. I'll bring it up at the IPv6 meeting to restore any patches in our topic that are currently abandoned so that you can clear them. [0] https://review.openstack.org/#/c/56381/9 Sean M. Collins From: Torbjorn Tornkvist [kruska...@gmail.com] Sent: Wednesday, January 15, 2014 6:40 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Availability of external testing logs On 2014-01-14 16:04, Collins, Sean wrote: Can we get the -1 from Tail-F cleared from this review? https://review.openstack.org/#/c/56184/17 I've been trying to do this but it fails. Possibly because it is 'Abandoned' ? See below: $ ssh -p 29418 ncsopenstack gerrit review -m 'Clearing out wrong -1 vote ' --verified=0 26a6c6 X11 forwarding request failed on channel 0 error: Change is closed one or more approvals failed; review output above Cheers, Tobbe ___ 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] Subnet mode - API extension or change to core API?
On Mon, Jan 13, 2014 at 07:32:29PM +0100, Ian Wells wrote: To fill others in, we've had discussions on the rest of the patch and Shixiong is working on it now, the current plan is: New subnet attribute ipv6_address_auto_config (not catchy, but because of Hi, will this patch replace https://review.openstack.org/#/c/52983/ or be based on it? Let me know since I need to update that review to address reviewer suggestions. -- 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] A pair of mode keywords
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] A pair of mode keywords
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 that it'll work with postgres, I think I have a closing brace misplaced, so it's not defining the Enum type correctly, and we have to get bug #1270212 resolved, since that's making the unit tests fail. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Developer documentation - linking to slideshares?
Hi, Some Neutron developers have some really great slides from some of the summits, and I'd like to link them in the documentation I am building as part of a developer doc blueprint, with proper attribution. https://blueprints.launchpad.net/neutron/+spec/developer-documentation I'm hoping to add Salvatore Orlando's slides on building a plugin from scratch, as well as Yong Sheng Gong's deep dive slides as references in the documentation. First - do I have permission from the previously mentioned? Second - is there any licensing that would make things complicated? As I add more links, I will make sure to ask for permission on the mailing list. Also, if you have done a presentation and have slides that help explain the internals of Neutron, I would love to add it as a reference. --- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for Feb 4 - 1400 UTC - in #openstack-meeting
Hi, I've posted a preliminary agenda for the upcoming IPv6 meeting. See everyone soon! https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_Feb_4th --- 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] Developer documentation - linking to slideshares?
On Tue, Feb 04, 2014 at 07:52:22AM -0600, Anne Gentle wrote: Currently the docs contributor sign the same CLA as code contributors. I'd encourage you to use the docs to really explain not just link to slide decks. There's a better chance of maintenance over time. Agreed - I plan on writing up docs, but when I find something really good on a slide I'd like to be able to have a reference to it in the footnotes - I suppose a works cited section, so I'm not plagiarizing. I had been using a wiki page for a collection of videos at https://wiki.openstack.org/wiki/Demo_Videos. But it ages with time. Awesome - I'll make sure to add that link to some kind of further reading section. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Devstack for IPv6 in the Comcast lab
Hi, During our last meeting, there was an action item to share the Devstack configuration that we have in the lab. Anthony Veiga, Paul Richie, and other members of the infrastructure team did the majority of the work involved in setting up the lab, while I was given the easier task of just modifying DevStack to build Neutron networks that fit our physical layout. https://github.com/netoisstools/devstack/compare/openstack-dev:stable%2Fhavana...comcast_havana This Devstack branch works in conjuction with a branch of Neutron that has the IPv6 patches that only used one IPv6 subnet keyword. https://github.com/netoisstools/neutron/tree/comcast_milestone_proposed Hopefully I can build some documentation that explains our physical layout for this lab, as well as rebasing these branches to use the newer code and blueprints we've been working on. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Using Python-Neutronclient from Python - docstrings needed?
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
... tenant_id=os.environ['OS_TENANT_ID'],
... username=os.environ['OS_USERNAME'],
... password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
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] [Nova] Gate broken
Ah, so they fixed the issue the blog post by AppNeta[0] brought up. Very Cool! http://www.appneta.com/blog/s3-list-get-bucket-default/ https://github.com/boto/boto/issues/2078 -- 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] Using Python-Neutronclient from Python - docstrings needed?
Do you have plans to submit these back upstream? It would be a great first
start, perhaps we could add these as examples underneath the JSON
request/reponse in http://api.openstack.org/api-ref-networking.html
Sean M. Collins
From: Rajdeep Dua [dua_rajd...@yahoo.com]
Sent: Saturday, February 08, 2014 11:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Using Python-Neutronclient from Python -
docstrings needed?
Sean,
We have written a few docs for writing these samples
http://python-api-guide.cfapps.io/content/neutron.html
You can find get the source here https://github.com/rajdeepd/openstack-samples
Thanks
Rajdeep
On Sunday, February 9, 2014 12:57 AM, Collins, Sean
sean_colli...@cable.comcast.com wrote:
Hi,
I was writing a small script yesterday to parse a list of IP blocks and
create security groups and rules, by using python-neutronclient.
To be honest, it was very difficult - even though I have actually
written extensions to Python-Neutronclient for the QoS API.
For those that are trying to use the client from inside their code,
they end up getting zero help as to how to actually call any of the
functions, and what parameters they take.
neutron = client.Client('2.0', auth_url=os.environ['OS_AUTH_URL'],
...tenant_id=os.environ['OS_TENANT_ID'],
...username=os.environ['OS_USERNAME'],
...password=os.environ['OS_PASSWORD'])
help(neutron)
| create_credential = function with_params
|
| create_firewall = function with_params
|
| create_firewall_policy = function with_params
|
| create_firewall_rule = function with_params
|
| create_floatingip = function with_params
|
| create_health_monitor = function with_params
|
| create_ikepolicy = function with_params
|
| create_ipsec_site_connection = function with_params
|
| create_ipsecpolicy = function with_params
|
| create_member = function with_params
|
| create_metering_label = function with_params
Since there was nothing there, I decided to go check the source of
python-neutronclient and see if there are any examples.
https://github.com/openstack/python-neutronclient/blob/master/doc/source/index.rst
If you read closely enough, you'll find out that the function takes a
dictionary, that looks very similar to the request/response examples
listed in the API documentation. So, I went over and checked it out.
http://docs.openstack.org/api/openstack-network/2.0/content/POST_security-groups-v2.0_createSecGroup_v2.0_security-groups_security-groups-ext.html
So from there, I was able to remember enough that each of these
functions takes a single argument, that is a dictionary, that mimics
the same structure that you see in the API documentation, so from there
it was just some experimentation to get the structure right.
Honestly it wasn't easy to remember all this stuff, since
it had been a couple months since I had worked with
python-neutronclient, and it had been from inside the library itself.
This was my first experience using it on the outside and it was pretty
tough - so I'm going to try and look into how we can improve the
docstrings for the client object, to make it a bit easier to figure out.
Thoughts?
--
Sean M. Collins
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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][QoS] It's back from the dead!
Hi, I'd like to apologize for the long delays in updating the QoS API patch sets - I am working on cleaning them up so that they are ready for review. -- 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][QoS] It's back from the dead!
No surprise, the code is quite stale, so bear with me while I debug the failures. -- 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] Monitoring IP Availability
On Thu, Feb 20, 2014 at 12:53:51AM +, Vilobh Meshram wrote: Hello OpenStack Dev, We wanted to have your input on how different companies/organizations, using Openstack, are monitoring IP availability as this can be useful to track the used IP’s and total number of IP’s. A while ago I added hooks to Nova-network to forward floating-ip allocations into an existing management system, since this system was the source of truth for IP address management inside Comcast. -- 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] ERROR: InvocationError: when running tox
Yes - it's a problem with non-Linux platforms not being able to install pyudev, which is a requirement for the linuxbridge plugin, which makes testr barf when it hits an ImportError. http://lists.openstack.org/pipermail/openstack-dev/2014-January/023268.html In the past, I've run tox -e py26 as a workaround, since for some reason testr shrugs off the ImportError in python 2.6. -- 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] ERROR: InvocationError: when running tox
Sorry - fired off this e-mail without looking too closely at your log output - I just saw the escape characters and the long lines from tox and it reminded me of the last discussion we had about it. It's probably not the same error as I was describing. That's the tough thing that I strongly dislike about Testr - when it fails, it fails spectacularly and it's very hard to determine what happened, for mere idiots like myself. -- 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] Sent the first batch of invitations to Atlanta's Summit
Make sure that you also log in, or have your username and password handy before you redeem it. If you click a link to send a password reset, you'll lose your session, and the invite code is a one-time use – I had to dig through my history to get the URL back, since the back button did not work correctly. -- 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] tox error
Shixiong Shang and I ran into this problem with Tox today while we were pair programming, and I've also seen similar barfs on my DevStack lab boxes - it's quite a mess. Frankly I've moved to using nosetests as a workaround, and have added it to the developer docs. We really do need to figure out how to make Tox and Testr give more useful failure output - it's so huge it makes my iTerm2 window lock up when I try and do an incremental search on the output. Help from a Testr / Tox guru would be appreciated. -- 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] New Subnet options editable?
On Mon, Mar 03, 2014 at 10:51:59AM +0800, Xuhan Peng wrote: Abishek, The two attributes are editable if you look at Sean's patch https://review.openstack.org/#/c/52983/27/neutron/api/v2/attributes.py. The allow_put is set to be True for these two attributes. Xuhan +1 - the attributes can be updated after creation. We may need to examine our patches to make sure that dnsmasq is restarted correctly when these attributes are updated. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Update the Wiki with links to blueprints and reviews
Hi All, We've got a lot of work in progress, so if you have a blueprint or bug that you are working on (or know about), let's make sure that we keep track of them. Ideally, for bugs, add the ipv6 tag https://bugs.launchpad.net/neutron/+bugs?field.tag=ipv6 For blueprints and code reviews, please add them to the Wiki https://wiki.openstack.org/wiki/Neutron/IPv6 -- 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] Update the Wiki with links to blueprints and reviews
On Tue, Mar 04, 2014 at 04:06:02PM +, Robert Li (baoli) wrote: Hi Sean, I just added the ipv6-prefix-delegation BP that can be found using the search link on the ipv6 wiki. More details about it will be added once I find time. Perfect - we'll probably want to do a session at the summit on it. -- 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][Security Group] BP: Support ICMP type filter by security group
On Tue, Mar 04, 2014 at 12:01:00PM -0500, Brian Haley wrote: On 03/03/2014 11:18 AM, Collins, Sean wrote: On Mon, Mar 03, 2014 at 09:39:42PM +0800, Xuhan Peng wrote: Currently, only security group rule direction, protocol, ethertype and port range are supported by neutron security group rule data structure. To allow If I am not mistaken, I believe that when you use the ICMP protocol type, you can use the port range specs to limit the type. https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_db.py#L309 http://i.imgur.com/3n858Pf.png I assume we just have to check and see if it applies to ICMPv6? I tried using horizon to add an icmp type/code rule, and it didn't work. Before: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN After: -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN -A neutron-linuxbri-i4533da4f-1 -p icmp -j RETURN I'd assume I'll have the same error with v6. I am curious what's actually being done under the hood here now... Looks like _port_arg just returns an empty array when hte protocol is ICMP? https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L328 Called by: https://github.com/openstack/neutron/blob/master/neutron/agent/linux/iptables_firewall.py#L292 -- 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] Change in openstack/neutron[master]: Permit ICMPv6 RAs only from known routers
On Tue, Mar 04, 2014 at 02:08:03PM EST, Robert Li (baoli) wrote:
Hi Xu Han Sean,
Is this code going to be committed as it is? Based on this morning's
discussion, I thought that the IP address used to install the RA rule
comes from the qr-xxx interface's LLA address. I think that I'm confused.
Xu Han has a better grasp on the query than I do, but I'm going to try
and take a crack at explaining the code as I read through it. Here's
some sample data from the Neutron database - built using
vagrant_devstack.
https://gist.github.com/sc68cal/568d6119eecad753d696
I don't have V6 addresses working in vagrant_devstack just yet, but for
the sake of discourse I'm going to use it as an example.
If you look at the queries he's building in 72252 - he's querying all
the ports on the network, that are q_const.DEVICE_OWNER_ROUTER_INTF
(network:router_interface). The IP of those ports are added to the list of
IPs.
Then a second query is done to find the port connected from the router
to the gateway, q_const.DEVICE_OWNER_ROUTER_GW
('network:router_gateway'). Those IPs are then appended to the list of
IPs.
Finally, the last query adds the IPs of the gateway for each subnet
in the network.
So, ICMPv6 traffic from ports that are either:
A) A gateway device
B) A router
C) The subnet's gateway
Will be passed through to an instance.
Now, please take note that I have *not* discussed what *kind* of IP
address will be picked up. We intend for it to be a Link Local address,
but that will be/is addressed in other patch sets.
Also this bug: Allow LLA as router interface of IPv6 subnet
https://review.openstack.org/76125 was created due to comments to 72252.
If We don't need to create a new LLA for the gateway IP, is the fix still
needed?
Yes - we still need this patch - because that code path is how we are
able to create ports on routers that are a link local address.
This is at least my understanding of our progress so far, but I'm not
perfect - Xu Han will probably have the last word.
--
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][Testr] Brand new checkout of Neutron... getting insane unit test run results
On Mon, Jan 13, 2014 at 05:16:16PM EST, Mark McClain wrote: I’d rather us explicitly skip the tests if the module is not available. mark Just wanted to close the loop on this - thanks to Darragh O'Reilly, who submitted https://review.openstack.org/#/c/66609/, which removes the Pyudev dependency for the Linuxbridge agent. This has corrected the issue where tox barfs when Pyudev is not found. -- 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] Change in openstack/neutron[master]: Permit ICMPv6 RAs only from known routers
Hi Robert, I'm reaching out to you off-list for this: On Wed, Mar 05, 2014 at 09:48:46AM EST, Robert Li (baoli) wrote: As a result of this change, it will end up having two LLA addresses in the router's qr interface. It would have made more sense if the LLA will be replacing the qr interface's automatically generated LLA address. Was this not what you intended, when you -1'd the security group patch because you were not able to create gateways for Neutron subnets with a LLA address? I am a little frustrated because we scrambled to create a patch so you would remove your -1, then now your suggesting we abandon it? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Developer documentation
Hi, I know everyone is very busy working on the I-3 release, but I wanted solicit feedback on my developer documentation review. https://review.openstack.org/#/c/72428/ Currently, we have a couple +1's and a +2 from Nachi - Akihirio Motoki and Henry Gessau brought up valid points about the TESTING file, but I felt that they can be addressed in other patchsets - since I don't feel confident in making the changes that they suggested, and some of the comments refer to issues that exist in the In addition, we're almost to the goal line - I'd rather get some docs merged and update in another patchset, rather than update this review with another patchset, that clears out all the +2's and +1's and then wait for everyone to circle back and re-approve. I understand this is a unusual request and I am asking for special treatment, but Neutron is severely lacking in documentation for new developers and I think this patch moves us closer to fixing it. Thoughts? -- 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] Developer documentation
On Fri, Mar 07, 2014 at 02:20:24PM EST, Miguel Angel Ajo wrote: Good work on the documentation, it's something that will really help new neutron developers. Thank you everyone! I am very happy! I'll start cranking out some patchsets to address some of the comments that Henry Gessau, Akihiro Motoki and others highlighted. -- 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 and IPv6 for IceHouse?
Hi, We have a number of patches that are in in review for IPv6 support in Neutron. https://wiki.openstack.org/wiki/Neutron/IPv6 Currently, we have two patches that have landed in Neutron and Nova that allows IPv6 to function correctly, when you have an external gateway/router set up and sending ICMPv6 RA packets. We are working on a series of patches that will make Neutron create IPv6 subnets, and launch dnsmasq with the correct configuration. Please join us on IRC, and post/read threads with the subject line of [Neutron][IPv6]. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam Sean M. Collins From: Martinx - ジェームズ [thiagocmarti...@gmail.com] Sent: Saturday, March 08, 2014 3:11 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Neutron and IPv6 for IceHouse? Hello Stackers! Please, forgive me to ask this here but, I'm about to lose my budget to deploy OpenStack in my ISP, because it does not support IPv6. There is no more IPv4 around here and I can not grow without IPv6. Please, I'm begging for you guys, pleeease, release IceHouse with IPv6! Otherwise, I'll lose the opportunity and there will be no more OpenStack around here... The company is about to give it up and look for another solution... I'll lost more than a year of development and a lot of time and money... I know that none of you are responsible for this, of course, this is my own problem but, I'm just trying to show for you guys, that IPv6 is a requirement, OpenStack can not live without it any longer (I believe)... Wait six more months is just out of the table (for me and for my company)... I am not a coder but, I have a huge lab and I'm good in testing and debugging softwares, please, let me know if there is anything that I can do, to make this [Neutron with IPv6] a reality. Is it working with Devstack?! Thanks! Thiago ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and IPv6 for IceHouse?
Also, I posted an e-mail to the mailing list that discusses a branch of Neutron and Nova, that can be used with DevStack, which contains patches for using IPv6 with non-openstack gateways and routers - it contains patches that we have currently under review. http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html Sean M. Collins From: Martinx - ジェームズ [thiagocmarti...@gmail.com] Sent: Saturday, March 08, 2014 3:11 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Neutron and IPv6 for IceHouse? Hello Stackers! Please, forgive me to ask this here but, I'm about to lose my budget to deploy OpenStack in my ISP, because it does not support IPv6. There is no more IPv4 around here and I can not grow without IPv6. Please, I'm begging for you guys, pleeease, release IceHouse with IPv6! Otherwise, I'll lose the opportunity and there will be no more OpenStack around here... The company is about to give it up and look for another solution... I'll lost more than a year of development and a lot of time and money... I know that none of you are responsible for this, of course, this is my own problem but, I'm just trying to show for you guys, that IPv6 is a requirement, OpenStack can not live without it any longer (I believe)... Wait six more months is just out of the table (for me and for my company)... I am not a coder but, I have a huge lab and I'm good in testing and debugging softwares, please, let me know if there is anything that I can do, to make this [Neutron with IPv6] a reality. Is it working with Devstack?! Thanks! Thiago ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron and IPv6 for IceHouse?
Yes, you can test these patches that are under review, but be prepared to do some debugging/hacking. They were not merged for I-3 since there is still work being done on them. There is also some patches that are under review to start bringing up Neutron routers and do RAs, but it is still under development. See the IPv6 section of the wiki for a full list. Sean M. Collins From: Martinx - ジェームズ [thiagocmarti...@gmail.com] Sent: Saturday, March 08, 2014 8:01 PM To: Collins, Sean Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Neutron and IPv6 for IceHouse? Mmm... But can I test those patches that are still under review, with Devstack? I meant, I would like to start testing a IPv6 provided by Neutron + RA, not by external provider. Tks! Thiago On 8 March 2014 21:58, Collins, Sean sean_colli...@cable.comcast.commailto:sean_colli...@cable.comcast.com wrote: Also, I posted an e-mail to the mailing list that discusses a branch of Neutron and Nova, that can be used with DevStack, which contains patches for using IPv6 with non-openstack gateways and routers - it contains patches that we have currently under review. http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html Sean M. Collins From: Martinx - ジェームズ [thiagocmarti...@gmail.commailto:thiagocmarti...@gmail.com] Sent: Saturday, March 08, 2014 3:11 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Neutron and IPv6 for IceHouse? Hello Stackers! Please, forgive me to ask this here but, I'm about to lose my budget to deploy OpenStack in my ISP, because it does not support IPv6. There is no more IPv4 around here and I can not grow without IPv6. Please, I'm begging for you guys, pleeease, release IceHouse with IPv6! Otherwise, I'll lose the opportunity and there will be no more OpenStack around here... The company is about to give it up and look for another solution... I'll lost more than a year of development and a lot of time and money... I know that none of you are responsible for this, of course, this is my own problem but, I'm just trying to show for you guys, that IPv6 is a requirement, OpenStack can not live without it any longer (I believe)... Wait six more months is just out of the table (for me and for my company)... I am not a coder but, I have a huge lab and I'm good in testing and debugging softwares, please, let me know if there is anything that I can do, to make this [Neutron with IPv6] a reality. Is it working with Devstack?! Thanks! Thiago ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][IPv6] IRC meeting today?
It starts at 10AM EST, due to daylight savings. See you in a couple minutes Sean M. Collins From: Shixiong Shang [sparkofwisdom.cl...@gmail.com] Sent: Tuesday, March 11, 2014 9:15 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Neutron][IPv6] IRC meeting today? Do we have IRC meeting today? Didn’t see anybody in the chat room…..:( Shixiong Shixiong Shang !--- Stay Hungry, Stay Foolish ---! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][QOS]How is the BP about ml-qos going?
On Mon, Mar 10, 2014 at 11:13:47PM EDT, Yuzhou (C) wrote: Hi stackers, The progress of the bp about ml2-qos is code review for long time. Why didn't the implementation of qos commit the neutron master ? For a while, I did not believe that this API extension would ever get merged, so I continued to do improvements and bug fixes and push them to the Comcast GitHub repo for Neutron, to support our deployment, but I did not update the reviews in Gerrit. I recently revived the reviews - and have pushed some updates. I hope to get this merged for the J release, and have scheduled a summit session for Atlanta to discuss. Anyone who knows the history can help me or give me a hint how to find the discuss mail? Search for posts tagged [QoS] - that should get most of them. -- 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] Developer documentation
I put together another review that starts to document the HTTP API layer and structure. https://review.openstack.org/#/c/79675/ I think it's pretty dense - there's a ton of terminology and concepts about WSGI and python that I sort of skim over - it's probably not newbie friendly just yet - comments and suggestions welcome - especially on how to introduce WSGI and everything else without making someone's head explode. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Developer Documentation - Architecture design docs in Google docs
Hi, I just read through some of the design docs that were linked to the DVR blueprints - and realized we probably have a ton of Neutron developer documentation and architecture stuff in Google docs. Should we try and gather them all up and place links to them in the Developer Documentation - or perhaps even bring them into the developer documentation tree (if they are not currently undergoing discussion and development)? -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Prefix delegation - API Attributes
Hi, Anthony Veiga and I did a small bit of whiteboarding this morning to sketch out what a prefix delegation would look like in the Neutron API. https://wiki.openstack.org/wiki/Neutron/IPv6/PrefixDelegation -- 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] Using Python-Neutronclient from Python - docstrings needed?
On Fri, Mar 21, 2014 at 08:35:05PM EDT, Rajdeep Dua wrote: Sean, If you can point me to the project file in github which needs to be modified , i will include these docs Thanks Rajdeep I imagine inside the openstack-manuals git repo https://github.com/openstack/openstack-manuals Possibly inside the doc/user-guide tree. Although others may have better suggestions. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs
During the review[0] of the patch that only allows RAs from known
addresses, Robert Li brought up a bug in Neutron, where a
IPv6 Subnet could be created, with a link local address for the gateway,
that would fail to create the Neutron router because the IP address that
the router's port would be assigned, was a link local
address that was not on the subnet.
This may or may have been run before force_gateway_on_subnet flag was
introduced. Robert - if you can give us what version of Neutron you were
running that would be helpful.
Here's the full text of what Robert posted in the review, which shows
the bug, which was later filed[1].
This is what I've tried, creating a subnet with a LLA gateway address:
neutron subnet-create --ip-version 6 --name myipv6sub --gateway fe80::2001:1
mynet :::/64
Created a new subnet:
+--++
| Field | Value |
+--++
| allocation_pools | {start: :::1, end:
::::::fffe} | | cidr | :::/64 | |
dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1 | |
host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | | ip_version |
6 | | name | myipv6sub | | network_id | 9c25c905-da45-4f97-b394-7299ec586cff
| | tenant_id | fa96d90f267b4a93a5198c46fc13abd9 |
+--++
openstack@devstack-16:~/devstack$ neutron router-list
+--+-+-+
| id | name | external_gateway_info
|
+--+-+-+
| 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {network_id:
02673c3c-35c3-40a9-a5c2-9e5c093aca48, enable_snat: true}
|
+--+-+-+
openstack@devstack-16:~/devstack$ neutron router-interface-add
7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub
400-{u'NeutronError': {u'message': u'Invalid input for operation: IP address
fe80::2001:1 is not a valid IP for the defined subnet.', u'type':
u'InvalidInput', u'detail': u''}}
During last week's meeting, we had a bit of confusion near the end of the
meeting[2] about the following bug, and the fix[3].
If I am not mistaken - the fix is so that when you create a v6 Subnet
with a link local address, then create a Neutron router to serve as the
gateway for that subnet - the operation will successfully complete and a
router will be created.
We may need to take a look at the code that create a router - to ensure
that only one gateway port is created, and that the link local address
from the subnet's 'gateway' attribute is used as the address.
This is at least my understanding of the problem as it stands today -
and that this bug and fix does not involve any external gateways or
physical devices that Neutron does not control - this is exclusively
about Neutron routers.
[0]: https://review.openstack.org/#/c/72252/
[1]: https://bugs.launchpad.net/neutron/+bug/1284518
[2]:
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-03-18-14.02.log.html
[3]: https://review.openstack.org/#/c/76125/
--
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] Ubuntu PPA with IPv6 enabled, need help to achieve it
On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote: Awesome guys! I'll do it! OK - so keep an eye on: https://review.openstack.org/#/c/70649/ Once it is rebased to solve the merge conflicts, and all the tests pass, then perhaps we can look into any of this backporting or PPA business. So keep your powder dry ;) -- 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] Ubuntu PPA with IPv6 enabled, need help to achieve it
On Thu, Apr 03, 2014 at 02:28:39AM EDT, Sebastian Herzberg wrote: Concerning dnsmasq: There is still no 2.66 version in the repos for Ubuntu 12.04. You always need to remove 2.59 and dpkg a newer version into it. I think it was resolved with this bug: https://bugs.launchpad.net/neutron/+bug/129 -- 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] Ubuntu PPA with IPv6 enabled, need help to achieve it
Sorry - not resolved: being tracked. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] [IPv6] Supporting upstream RAs
I am currently working on a patch that allows upstream RAs and SLAAC configuration. Currently testing it in devstack - it's based on chunks of patchset 33 of this review that were skipped when Mark McClain committed patchset 34. https://review.openstack.org/#/c/56184/ Xu Han and Dazhao - do I have your permission to post a rebased version of this patch into Gerrit - I have set myself as the author and added you both as Co-Authors. -- 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] Supporting upstream RAs
Hi Martin, I previously posted to the mailing list with some information about our IPv6 lab environment and devstack setup. http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html Keep in mind that code differs from what was eventually merged in upstream, so I would ask for your patience while I rebase some patches and submit them for review, to work with the two new IPv6 attributes. Please join us on the IRC channel tomorrow, if you are available. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for tomorrow - please add topics
Hi, I've added a section for tomorrow's agenda, please do add topics that you'd like to discuss. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_8th -- 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] Debugging Devstack Neutron with Pycharm
I think we need to pick either one or the other. We currently have two places where debugging is documented, the OpenStack wiki and in the Neutron tree http://git.openstack.org/cgit/openstack/neutron/tree/TESTING.rst#n143 Sean M. Collins From: Gal Sagie [gsa...@vmware.com] Sent: Wednesday, June 11, 2014 8:36 AM To: ges...@cisco.com Cc: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Debugging Devstack Neutron with Pycharm Thanks a lot, this works, i will update the wiki. Gal. From: Henry Gessau ges...@cisco.com To: openstack-dev@lists.openstack.org Sent: Wednesday, June 11, 2014 2:41:47 PM Subject: Re: [openstack-dev] [Neutron] Debugging Devstack Neutron with Pycharm Gal Sagie wrote: I am trying to debug devstack Neutron with Pycharm, i have found here (https://wiki.openstack.org/wiki/NeutronDevelopment#How_to_debug_Neutron_.28and_other_OpenStack_projects_probably_.29) That i need to change the neutron server code to this=eventlet.monkey_patch() To: eventlet.monkey_patch(os=False, thread=False) I don't need to do this. But I do need to go into the PyCharm settings under Python Debugger and enable Gevent compatible debugging. I have done so, debug seems to run, but when i am trying to initiate commands from the CLI i get this: gal@ubuntu:~/devstack$ neutron net-list Connection to neutron failed: Maximum attempts reached Are you sure you have sourced openrc correctly for the credentials? (the server seems to run ok...) Any help is appreciated as i am trying to learn and understand main flows by debugging the code locally. First I start devstack in offline mode. OFFLINE=True ./stack.sh Once it is running I go to the neutron window in screen. There I stop neutron-server with ctrl-C, and press up-arrow to view the start command. To run neutron-server in the PyCharm debugger edit the Run/Debug configuration with the following settings: Script: /usr/local/bin/neutron-server Script params: --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini # I got this from the screen window where I stopped neutron Working directory: /opt/stack/neutron Now restart neutron from PyCharm instead of screen. ___ 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] Do you have problem accessing IRC
On Tue, Jun 17, 2014 at 10:10:26AM EDT, Shixiong Shang wrote: Trying to join the weekly meeting, but my IRC client kept complaining…Is it just me? If you have problems, you can always use the web client: http://webchat.freenode.net/ -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][QoS] Meeting agenda for Today's meeting
Hi, I have posted a preliminary agenda for today. I will be unable to attend the meeting, Kevin Benton will be chairing the meeting today. Please do add items to the agenda that you wish to discuss! https://wiki.openstack.org/wiki/Meetings/NeutronQoS -- 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] High bandwidth routers
You can use the provider networking API extension for Neutron, in order to utilize non-openstack L3 hardware. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][ML2] Migration bug - Bug #1332564
Hi, Anthony Veiga and I are currently working on migrating a lab environment from Neutron Havana w/ OVS plugin to Icehouse w/ ML2 plugin and ran into a bug[0]. Now the patch that adds the ml2 migration[1] mentions that it was tested without any data, and that it is waiting on grenade support for neutron to be merged. Firstly, who has strong mysql-fu to pair up and track down why the foreign key statement is failing in 1332564, and secondly what can I do to help add grenade support for the OVS/LB - ML2 migration? This is a critical bug and I can probably devote a great deal of my time to fixing this. [0]: https://bugs.launchpad.net/neutron/+bug/1332564 [1]: https://review.openstack.org/#/c/76533/10 -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Volunteer to run tomorrow's IRC meeting?
Hi, I am currently at a book sprint and will probably not be able to run the meeting, if someone could volunteer to chair the meeting and run it, that would be great. Any takers? -- 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] Volunteer to run tomorrow's IRC meeting?
On Mon, Jul 07, 2014 at 11:01:52PM PDT, Kevin Benton wrote: I can lead it, but I'm not sure if there is anything new to discuss since the QoS spec is still under review. Did you have any specific agenda items that you wanted to cover? Ah. The QoS IRC meeting will also need to be chaired in my absence, although lately there has not been a lot of participation. This is partly my fault since I didn't start the meeting on time last week, but I wonder if we should continue the IRC meeting? -- 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] cloud-init IPv6 support
On Mon, Jul 07, 2014 at 03:29:31PM EDT, Scott Moser wrote: I think it's also important to realize that the metadata service isn't OpenStack invented, it's an AWS API. Which means I don't think we really Thats incorrect. The metadata service that lives at http://169.254.169.254/ and http://169.254.169.254/ec2 is a mostly-aws-compatible metadata service. The metadata service that lives at http://169.254.169.254/openstack is 100% Openstack Invented. The URL structure and schema of data within may be 100% openstack invented, but the idea of having a link local address that takes HTTP requests and returns metadata was (to my knowledge) an Amazon EC2 idea from the beginning. There have been some good arguments and workarounds for the fact that Amazon EC2 is not dual-stacked. My concern is that when Amazon finally brings IPv6 to EC2, if we are trying to anticipate what they are going to do on items like the metadata API, and we guess wrong, we're going to have to make breaking changes. For now, I think we should document that only config drive for metadata works in an IPv6 environment, and wait for Amazon to make changes to their metadata API to enable IPv6 support, for those who wish for AWS compatibility. -- 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] [Infra][Neutron] Request voting for Tail-f CI account
From: Luke Gorrie l...@snabb.comailto:l...@snabb.co Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, July 21, 2014 3:22 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [Infra][Neutron] Request voting for Tail-f CI account The account has a rich history :-). Initially we brought it online back around Nov 2013 early in the Icehouse cycle. That didn't work out so well: we had a bunch of operational issues and as OpenStack newbies we were oblivious to the impact they had on other people's workflows -- we were mortified to learn that we had created a disruption. Since then we have been more conservative which is why the account was mostly idle until June. The fact that I tried to reach out to the person who was listed as the contact back in November to try and resolve the –1 that this CI system gave, and never received a response until the public mailing list thread about revoking voting rights for Tail-F, makes me believe that the Tail-F CI system is still not ready to have that kind of privilege. Especially if the account was idle from around February, until June – that is a huge gap, if I understand correctly? -- 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] [Infra][Neutron] Request voting for Tail-f CI account
On Wed, Jul 23, 2014 at 11:19:13AM EDT, Luke Gorrie wrote: Tail-f NCS: I want to keep this feature well maintained and compliant with all the rules. I am the person who wrote this driver originally, I have been the responsible person for 90% of its lifetime, I am the person who setup the current CI, and I am the one responsible for smooth operation of that CI. I am reviewing its results with my morning coffee and have been doing so for the past 6 weeks. I would like to have it start voting and I believe that it and I are ready for that. I am responsive to email, I am usually on IRC (lukego), and in case of emergency you can SMS/call my mobile on +41 79 244 32 17. So... Let's be friends again? (and do ever cooler stuff in Kilo?) Luke was kind enough to reach out to me, and we had a discussion in order to bury the hatchet. Posting his contact details and being available to discuss things has put my mind at ease, I am ready to move forward. -- 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] [Spec freeze exception] Support Stateful and Stateless DHCPv6 by dnsmasq
On Wed, Jul 23, 2014 at 12:06:06AM EDT, Xu Han Peng wrote: I would like to request one Juno Spec freeze exception for Support Stateful and Stateless DHCPv6 by dnsmasq BP. This BP is an important part if IPv6 support in Juno. Router advertisement support by RADVD has been merged and this BP is planned for configure OpenStack dnsmasq to co-work with router advertisement from either external router or OpenStack managed RADVD to get IPv6 network fully functional. This BP also supports dnsmasq to work independently for DHCPv6 subnet. Without this BP, only SLAAC mode is enabled without any stateful/stateless DHCPv6 support. The spec is under review: https://review.openstack.org/#/c/102411/ Code change for this BP is submitted as well for a while: https://review.openstack.org/#/c/106299/ Thanks, Xu Han I'd like to +1 this request, if this work landed in Juno, this would mean Neutron would have 100% support for all IPv6 subnet attribute settings, since slaac support landed in J-2. I know that we're competing for bandwidth and asking for special consideration, but I feel it's my role to advocate for the devs on the subteam. Thank you for the consideration! -- 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] Hide ipv6 subnet API attributes
On Tue, Jul 29, 2014 at 04:40:33AM EDT, Nir Yechiel wrote: Now with the Juno efforts to provide IPv6 support and some features (provider networks SLAAC, RADVD) already merged, is there any plan/patch to revert this Icehouse change [1] and make the 'ra_mode' and 'ipv6_address_mode' consumable? There are currently no plans, since all of the changes that implement IPv6 functionality have been landing in Juno. I suggest upgrading to Juno when it is released. -- 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] [Nova][Neutron][Technical Committee] nova-network - Neutron. Throwing a wrench in the Neutron gap analysis
On Tue, Aug 05, 2014 at 12:50:45PM EDT, Monty Taylor wrote: However, I think the cost to providing that path far outweighs the benefit in the face of other things on our plate. Perhaps those large operators that are hoping for a Nova-Network-Neutron zero-downtime live migration, could dedicate resources to this requirement? It is my direct experience that features that are important to a large organization will require resources from that very organization to be completed. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Vagrant Devstack projects - time to consolidate?
Hi, I've noticed a proliferation of Vagrant projects that are popping up, is there any interest from other authors in trying to consolidate? https://github.com/bcwaldon/vagrant_devstack https://github.com/sdague/devstack-vagrant http://openstack.prov12n.com/how-to-make-a-lot-of-devstack-with-vagrant/ https://github.com/jogo/DevstackUp https://github.com/search?q=vagrant+devstackref=cmdform -- 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] Ubuntu PPA with IPv6 enabled, need help to achieve it
Many of those patches are stale - please join us in the subteam IRC meeting if you wish to coordinate development of IPv6 features, so that we can focus on updating them and getting them merged. At this point simply applying them to the Icehouse tree is not enough. -- 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] Vagrant Devstack projects - time to consolidate?
Maybe it would be good to get an ad-hoc IRC meeting together to figure out what the must have features are that inspired everyone to write these. If we can come up with a way to overlap those all sanely, moving to stackforge and doing this via gerrit would be something I'd be into. -Sean +1 to this idea. I found vagrant_devstack a while ago and started using it and then started documenting it for our development team at Comcast, it has been very helpful for getting new developers started. Having something in Stackforge would be great, so that we can consolidate all our knowledge and energy. -- 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] Vagrant Devstack projects - time to consolidate?
On Fri, Apr 11, 2014 at 02:24:10PM EDT, Sean Dague wrote: Honestly, multi provisioner support is something I think shouldn't be done. Agreed - in addition let's keep this in perspective - we're just adding a little bit of glue to prep the VM for the running of DevStack, which does the heavy lifting. Being opinionated is good when it comes to providing tools to make things easy to onboard people. The provisioner in infra is puppet. Learning puppet lets you contribute to the rest of the openstack infra, and I expect to consume some piece of that in this process. +1000 on this - if there's already a provisioner that is used for infra, let's re-use some of that knowledge and expertise. -- 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] Ubuntu PPA with IPv6 enabled, need help to achieve it
On Fri, Apr 11, 2014 at 11:09:18PM EDT, Thomas Goirand wrote: On 04/11/2014 10:52 PM, Collins, Sean wrote: Many of those patches are stale - please join us in the subteam IRC meeting if you wish to coordinate development of IPv6 features, so that we can focus on updating them and getting them merged. At this point simply applying them to the Icehouse tree is not enough. When and where is the next meeting? https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam 1400 UTC on Tuesdays in #openstack-meeting -- 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][QoS] API Design Document v2
Hi, Sorry for the late response. Currently I am working on just getting support for a single QoS policy on a network or port merged, before we get into more complex operations. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for April 15th
Feel free to update the agenda with items for discussion https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_15th -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Meeting Minutes
Meeting minutes: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-04-15-14.00.html See you next week! -- 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] Neutron Mid-Cycle Meeting
I just want to quickly caution about having these meetings in person since not everyone will be able to attend - the summits are probably where we will have the most Neutron developers able to attend. It's not that I oppose the idea - but there must be adequate facilities for people to attend and participate remotely - and that they are not considered an afterthought. -- 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] Neutron BP review process for Juno
Nice!! nwdiag would make things really easy. -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][IPv6] Agenda for tomorrow's meeting
You know the drill - fill in anything you wish to discuss. https://wiki.openstack.org/wiki/Meetings/Neutron-IPv6-Subteam#Agenda_for_April_21st -- 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] [VPNaaS] - IPSec by default on each Tenant router, the beginning of the Opportunistic Encryption era (rfc4322 ?)...
Have you considered filing a blueprint for this? It'd be good to keep this on the radar. https://wiki.openstack.org/wiki/Blueprints#Neutron -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
