Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 5:54 PM, Clark Boylan wrote: > I got curious and this is an odd situation. I can't find where 212669 > has a patchset with a parent of the commit for 192032,37 (b7151e4). Git > represents the tree as a DAG with each child commit pointing at its >

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote: > n goes to next occurrence and N (shift+n) to a previous one. These are > same keybindings as in Vim. Actually a lot of Vim-like movements are > functional in new Gerrit and I really like that fact. Thanks. Looking

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:16 AM, Michał Dulko wrote: > n goes to next occurrence and N (shift+n) to a previous one. These are > same keybindings as in Vim. Actually a lot of Vim-like movements are > functional in new Gerrit and I really like that fact. I'll admit that I

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 3:40 PM, Zaro <zaro0...@gmail.com> wrote: > On Tue, Dec 22, 2015 at 4:51 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: >> I noticed another thing. I'm working with a chain of three patches. >> I just updated the patch in the middle [1]

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Wed, Dec 23, 2015 at 1:57 PM, Elizabeth K. Joseph <l...@princessleia.com> wrote: > On Wed, Dec 23, 2015 at 10:11 AM, Carl Baldwin <c...@ecbaldwin.net> wrote: >> I do see that a lot of vim movement does work. I was hoping that >> holding down a movement command like

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

On Mon, Dec 21, 2015 at 6:21 PM, Zaro wrote: > Hit '?' and it says '/' is find, give that a try. '/' isn't really much better. It seems to highlight all of the occurrences but I can't find a way to navigate to the next/previous occurence with the keyboard. I see that the

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

gainst gerrit. What should we do? Should we individually go file bugs against gerrit? Or, should we funnel it through someone working on gerrit in openstack? [1] https://review.openstack.org/#/c/192032/37 [2] https://review.openstack.org/#/c/212669/4 On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

On Fri, Dec 18, 2015 at 12:54 PM, Vladimir Eremin wrote: > Hi Carl, > > As far as I understand Address Scopes, end user’s algorithm will be next: > 1. Administrator creates an address scope and associate an IPv6 subnet pool > with it. > 2. Administrator creates Public

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

I noticed a couple of things today while reviewing a largish page [1]. First, when I search for something using the browser's builtin search (Chrome, Mac OSX Yosemite), it doesn't seem to find occurrences that are not in the visible portion of the page. For example, when I search for DNSDOMAIN, I

Re: [openstack-dev] [OpenStack-Infra] Gerrit Upgrade to ver 2.11, completed.

I also really miss being able to pull up the list of files in diff view with the 'f' key. Any equivalent? Carl On Mon, Dec 21, 2015 at 4:07 PM, Carl Baldwin <c...@ecbaldwin.net> wrote: > I noticed a couple of things today while reviewing a largish page [1]. > First, when I search f

Re: [openstack-dev] [neutron][grenade] l3.filters fail to update at test server

On Thu, Dec 17, 2015 at 5:12 AM, Ihar Hrachyshka wrote: > I believe that we should always unconditionally update filters with new > versions when doing upgrades. Filters should not actually be considered > configuration files in the first place since they are tightly coupled

Re: [openstack-dev] [gate] any project using olso.db test_migrations is currently blocked

On Thu, Dec 17, 2015 at 5:29 AM, Ihar Hrachyshka wrote: > I will update on Neutron side of things since it seems I have some knowledge > from the fields. > > So first, on resources: we have Sachi and lifeless from infra side + Ihar > and pc_m looking into expanding

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

On Thu, Dec 17, 2015 at 1:30 PM, Vladimir Eremin wrote: > Hi > > For now, when end user is creating IPv6-enabled tenant network and attaching > it to the virtual router, there is only way to set up external infrastructure > to put traffic back to the router is using DHCPv6

Re: [openstack-dev] [Neutron] [IPv6] [radvd] Advertise tenant prefixes from router to outside

On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin wrote: > Hi Carl, > > I’ll fil RFE for sure, thank you for the link to the process ) > > So actually, we should announce all SUBNETS we’ve attached to router. > Otherwise is will not work, because external network router will

Re: [openstack-dev] [gate] any project using olso.db test_migrations is currently blocked

On Wed, Dec 16, 2015 at 11:32 AM, Jeremy Stanley wrote: [...] > Yes, it's progressing nicely. DevStack-based jobs are already > covered this way for master and stable/liberty, and Neutron is > piloting the same solution for its other non-DevStack-based jobs. If Is someone from

Re: [openstack-dev] [gate] any project using olso.db test_migrations is currently blocked

On Wed, Dec 16, 2015 at 10:04 AM, Mike Bayer wrote: >> Instead of just breaking the world, and burning 10s to 100 engineer >> hours in redo tests and investigating and addressing the break after the >> fact. We shouldn't let this happen in the first place. I think this is our

Re: [openstack-dev] [Neutron] Call for review focus

On Mon, Dec 14, 2015 at 12:41 PM, Rossella Sblendido wrote: > On 11/25/2015 11:05 PM, Assaf Muller wrote: >> We could then consider running the script automatically on a daily >> basis and publishing the >> resulting URL in a nice bookmarkable place. > > An update on this.

Re: [openstack-dev] [neutron] Multiple locations for documentation of features

On Fri, Dec 4, 2015 at 12:22 PM, Henry Gessau wrote: > 1. RFE: "I want X" > 2. Spec: "I plan to implement X like this" > 3. devref: "How X is implemented and how to extend it" > 4. OS docs: "API and guide for using X" > > Once X is implemented I don't want to have to go to 1 or

Re: [openstack-dev] [Neutron] Bug deputy process

On Thu, Dec 3, 2015 at 9:29 AM, Kyle Mestery wrote: > One concern I have is ensuring we rotate people, because it does take some > time, and if the same handful of rotate, they will burn out. So I actively > encourage more people to volunteer, you don't even have to be a

[openstack-dev] [Neutron][DVR]

I was going to bring this up in the meeting this morning but IRC troubles prevented it. After chatting with Armando, I'd like to suggest a few enhancements to how we're tackling DVR during this cycle. I'm hoping that these changes help us to get things done faster and more efficiently. Let me

Re: [openstack-dev] [Neutron] Call for review focus

++ On Wed, Nov 25, 2015 at 3:05 PM, Assaf Muller wrote: > On Mon, Nov 23, 2015 at 7:02 AM, Rossella Sblendido > wrote: >> >> >> On 11/20/2015 03:54 AM, Armando M. wrote: >>> >>> >>> >>> On 19 November 2015 at 18:26, Assaf Muller >>

Re: [openstack-dev] [Neutron] Call for review focus

On Tue, Nov 24, 2015 at 4:47 AM, Rossella Sblendido wrote: >> I looked for the address scopes blueprint [1] which is targeted for >> Mitaka-1 [2] and there are 6 (or 5, one is in the gate) patches on the >> bp/address-scopes topic [3]. It isn't obvious to me yet

Re: [openstack-dev] [Neutron] Call for review focus

On Mon, Nov 23, 2015 at 5:02 AM, Rossella Sblendido wrote: > To cross-reference we can use the bug ID or the blueprint name. > > I created a script that queries launchpad to get: > 1) Bug number of the bugs tagged with approved-rfe > 2) Bug number of the critical/high bugs >

Re: [openstack-dev] [Neutron] Call for review focus

On Fri, Nov 20, 2015 at 3:57 PM, Armando M. wrote: > On 20 November 2015 at 14:07, Kyle Mestery wrote: >> On Wed, Nov 18, 2015 at 8:14 PM, Armando M. wrote: >>> >>> Hi Neutrites, >> >> Neutrinos? > > I am still experimenting to see what

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

On Mon, Nov 9, 2015 at 1:39 PM, Shraddha Pandhe wrote: > Thats great. L3 layer network model is definitely one of our most important > requirements. All our go-forward deployments are going to be L3. So this is > a big deal for us. I think we're on a good path to

Re: [openstack-dev] [Neutron] Call for review focus

++ On Wed, Nov 18, 2015 at 7:14 PM, Armando M. wrote: > Hi Neutrites, > > We are nearly two weeks away from the end of Mitaka 1. > > I am writing this email to invite you to be mindful to what you review, > especially in the next couple of weeks. Whenever you have the time to

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

On Wed, Nov 18, 2015 at 9:44 AM, Ihar Hrachyshka wrote: > Hi all, > > as per [1] I imply that all projects under stable-maint-core team > supervision must abide the stable policy [2] which limits the types of > backports for N-2 branches (now it’s stable/kilo) to "Only

Re: [openstack-dev] [Neutron][IPAM] Arbitrary JSON blobs in ipam db tables

On Fri, Nov 6, 2015 at 2:59 PM, Shraddha Pandhe wrote: > > We have a similar requirement where we want to pick a network thats > accessible in the rack that VM belongs to. We have L3 Top-of-rack, so the > network is confined to the rack. Right now, we are achieving

Re: [openstack-dev] [Neutron] Reminder: Team meeting on Monday at 2100 UTC

I've been using Iceland's TZ for this. Seems to work well and handle the TZ changes nicely. Carl On Sat, Nov 7, 2015 at 7:24 AM, Sean M. Collins wrote: > Learn from my mistake, check your calendar for the timezone if you've > created an event for the weekly meetings. Google

Re: [openstack-dev] [stable][neutron] Kilo is 'security-supported'. What does it imply?

On Thu, Nov 5, 2015 at 8:17 AM, Ihar Hrachyshka wrote: > - Releases page on wiki [2] calls the branch ‘Security-supported’ (and it’s > not clear what it implies) I saw this same thing yesterday when it was pointed out in the DVR IRC meeting [1]. I have a hard time believing

Re: [openstack-dev] [neutron] Stepping Down from Neutron Core Responsibilities

Edgar, It is great working with you. You've done so much. Carl On Wed, Nov 4, 2015 at 5:28 PM, Edgar Magana wrote: > Dear Colleagues, > > I have been part of this community from the very beginning when in Santa > Clara, CA back in 2011 a bunch of we crazy people

Re: [openstack-dev] [Neutron] Weekly DVR Meeting starting next week

Thanks, Brian. I'm planning to be there. Carl On Thu, Oct 29, 2015 at 10:17 PM, Brian Haley wrote: > A few of us had a discussion this week at Summit and decided to re-start the > weekly Neutron Distributed Virtual Router (DVR) meeting. The goal is to > help: > > -

[openstack-dev] [Neutron] Routed Networks meetup in Tokyo

Sorry for the late notice. I fell asleep yesterday before sending this out. I'd like to get together at the afternoon session of the Neutron contributors meetup today to discuss the next steps for addressing operators' routed networks use case during the Mitaka cycle. If you are interested in

Re: [openstack-dev] [neutron][calico] networking-calico 1.0.0

Great work Calico! Count me in when you have project meetings, I'd like to keep up. Carl On Oct 16, 2015 6:21 AM, "Neil Jerram" wrote: > I'm happy to announce the first release of networking-calico. As it > says at

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

+1 Great idea! On Fri, Oct 9, 2015 at 3:42 AM, Thierry Carrez wrote: > Hello everyone, > > OpenStack has become quite big, and it's easier than ever to feel lost, > to feel like nothing is really happening. It's more difficult than ever > to feel part of a single

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

(Cross-posting to the operators list for feedback) Thank you Ihar for starting this up. In the absence of any kind of blog or other outlet of my own to disseminate this, let me share my plans here... Routed Networks: My plans for Mitaka (and beyond) are around routed networks. During Liberty,

Re: [openstack-dev] [networking-ovn] Neutron-DVR feature on OVN/L3

On Tue, Sep 22, 2015 at 10:42 AM, Russell Bryant wrote: > The Neutron L3 agent is only used with networking-ovn temporarily while > we work through the L3 design and implementation in OVN itself. OVN > will not use the L3 agent (or DVR) quite soon. Some initial L3 design >

Re: [openstack-dev] [Neutron] Port Forwarding API

Interesting, I'll have a look. We should get this on the neutron drivers' agenda. The drivers team has been dormant for a couple of weeks but I'm sure it will pick up again very soon. Carl On Sep 20, 2015 12:28 AM, "Gal Sagie" wrote: > Hello All, > > I have sent a spec

Re: [openstack-dev] [neutron] [floatingip] Selecting router for floatingip when subnet is connected to multiple routers

On Sep 21, 2015 9:21 AM, "Venkata Anil" wrote: > > Hi All > > I need your opinion on selecting router for floatingip when subnet is connected to multiple routers. > > When multiple routers connected to a subnet, vm on that subnet will only send packets destined for external

Re: [openstack-dev] [networking-ovn] Neutron-DVR feature on OVN/L3

On Mon, Sep 21, 2015 at 2:47 PM, Sisir Chowdhury wrote: > Hi All - > > I have some proposal regarding ovn-networking project within Open-Stack. > > #1. Making Neutron-DVR feature intelligent enough so that we can > completely remove Network Node(NN). > > Right

Re: [openstack-dev] [Neutron] Separate floating IP pools?

On Fri, Sep 18, 2015 at 4:55 AM, Clark, Robert Graham wrote: > Is it possible to have separate floating-IP pools and grant a tenant access > to only some of them? It is possible to have multiple floating IP pools by creating multiple external networks. However, it is not

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton wrote: > Yes, the L2 semantics apply to the external network as well (at least with > ML2). This is true and should remain so. I think we've come to the agreement that a neutron Network, external, shared, or not, should be an L2

Re: [openstack-dev] [neutron] What semantics are expected when booting a VM on an external network?

On Thu, Sep 17, 2015 at 12:35 PM, Kevin Benton wrote: >>Also I believe that (c) is already true for Neutron external networks - >> i.e. it doesn't make sense to assign a floating IP to an instance that is >> directly on an external network. Is that correct? > > Well not

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

On Tue, Sep 15, 2015 at 3:09 PM, Fox, Kevin M wrote: > DNS is preferable, since humans don't remember ip's very well. IPv6 is much > harder to remember then v4 too. > > DNS has its own issues, mostly, its usually not very quick to get a DNS entry > updated. At our site (and

Re: [openstack-dev] [neutron][L3][QA] DVR job failure rate and maintainability

, and making the enhancements needed to make this feature what it should be. Carl [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam On Mon, Sep 14, 2015 at 4:01 PM, Sean M. Collins <s...@coreitpro.com> wrote: > Hi, > > Carl Baldwin, Doug Wiegley, Matt Kassawara, Ryan Mo

Re: [openstack-dev] [Neutron] Port forwarding

On Tue, Sep 1, 2015 at 11:59 PM, Gal Sagie wrote: > Hello All, > > I have searched and found many past efforts to implement port forwarding in > Neutron. I have heard a few express a desire for this use case a few times in the past without gaining much traction. Your

Re: [openstack-dev] [nova] [neutron] [rally] Neutron or nova degradation?

This sounds like a good candidate for a "git bisect" operation [1] since we already have a pretty tight window where things changed. Carl [1] http://git-scm.com/docs/git-bisect On Thu, Sep 3, 2015 at 7:07 AM, Assaf Muller wrote: > > > On Thu, Sep 3, 2015 at 8:43 AM, Andrey

Re: [openstack-dev] [neutron][db] reviewers: please mind the branch a script belongs to

Thanks, I learned a thing or two from the document that you linked. Thanks for reminding us of that. Carl On Tue, Sep 1, 2015 at 3:14 AM, Ihar Hrachyshka wrote: > Hi reviewers, > > several days ago, a semantically expand-only migration script was merged into > contract

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

I was under the impression that we had a plan to stop allowing these external updates break our gate jobs. It seems extremely unwise to allow these forces outside of our control to disrupt us so much especially in such a large project as Neutron. We lose a lot of valuable time to these. I

Re: [openstack-dev] [neutron][fwaas][dvr] FWaaS with DVR

Hi, I did take the opportunity to read through your etherpad today. Many of the solutions that you propose have been discussed in the past but there just hasn't been a traction on the problem. You did a fine job of writing this up and I think we should use your etherpad as a central point for

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On Mon, Aug 31, 2015 at 10:50 AM, Armando M. wrote: > You missed 'weekends' :) I did miss weekends! While I went about my life last night blissfully unaware of the problems that were brewing, you were on top of things and came to our rescue. I thank you for your efforts and

Re: [openstack-dev] [Neutron] Netaddr 0.7.16 and gate breakage

On Mon, Aug 31, 2015 at 11:02 AM, Armando M. <arma...@gmail.com> wrote: > > > On 31 August 2015 at 09:53, Jeremy Stanley <fu...@yuggoth.org> wrote: >> >> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: >> > I was under the impr

Re: [openstack-dev] [neutron] RFE for DHCP agent changes for networking-calico

Hi, It has been a long catch-up day for me. I have looked through the patches. I have some feedback for them but I don't see why we can't shoot for Liberty-3. Carl On Sun, Aug 23, 2015 at 7:11 PM, Kyle Mestery mest...@mestery.com wrote: Thanks Neil, we'll review this during the drivers

Re: [openstack-dev] [Neutron][L3] [Large Deployments Team] Representing a networks connected by routers

On Mon, Aug 3, 2015 at 9:07 PM, Mike Dorman mdor...@godaddy.com wrote: I hope we can move this idea moving forward. I was disappointed to see the spec abandoned. While I think the ship has sailed for Liberty, this is going to be my top priority for for Mitaka. Abandoning the spec may have

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

Kevin, This is just a final top-post to say that I'm going to spend the next week noodling over this discussion in more detail and trying to flesh it out into a proposal. I think we're pretty much in agreement about where the problems are in the model. It feels like we'll just be beating a dead

Re: [openstack-dev] [Neutron] Common Base class for agents

I see this as two tasks: 1) A refactoring to share common code and 2) the addition of another agent following the pattern of the others. I'd prefer that the two tasks not be mixed in the same review because it makes it more difficult to review as I think Kevin eluded to. For me, either could be

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

Kevin, sorry for the delay in response. Keeping up on this thread was getting difficult while on vacation. tl;dr: I think it is worth it to talk through the idea of inserting some sort of a subnet group thing in the model to which floating ips (and router external gateways) will associate. It

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Jul 23, 2015 6:04 PM, Kevin Benton blak...@gmail.com wrote: IOW, I don't think what I proposed in adding L3 stuff to the network that wasn't already here. The point I'm trying to make is that there isn't any L3 stuff on the network itself. There are L3 things that depend on the network

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Jul 23, 2015 8:39 PM, Paul Carver pcar...@paulcarver.us wrote: I think Kevin is right here. Network is fundamentally a layer 2 construct, it represents direct reachability. A network could in principle support non-IP traffic (though in practice that may or may not work depending on underlying

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton blak...@gmail.com wrote: We ran in to this long ago. What are some other examples? We've be good about keeping the network L2 only. Segments, VLAN transparency, and other properties of the network are all L2. Another thing is that we create

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote: It seems to me that the existence of the multiprovider extension is an important point for this discussion. Multiprovider, as I understand it, allows describing a network composed of multiple L2 segments with implicit

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton blak...@gmail.com wrote: Or, migration scheduling would need to respect the constraint that a port may be confined to a set of hosts. How can be assign a port to a different network? The VM would wake up and what? How would it know to reconfigure

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton blak...@gmail.com wrote: The issue with the availability zone solution is that we now force availability zones in Nova to be constrained to network configuration. In the L3 ToR/no overlay configuration, this means every rack is its own availability

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando salv.orla...@gmail.com wrote: It is however important to ensure services like DHCP keep working as usual. Treating segments as logical networks in their own right is the simples solution to achieve this imho. Agreed. While the logical model

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton blak...@gmail.com wrote: I proposed the port scheduling RFE to deal with the part about selecting a network that is appropriate for the port based on provided hints and host_id. [1] Thanks for the pointer. I hadn't paid much attention to this RFE

Re: [openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

It has been a week since this nomination. I'm pleased to confirm Cedric as a core reviewer for these areas of focus. We look forward to your continued contribution to the project! Carl On Wed, Jul 15, 2015 at 12:47 PM, Carl Baldwin c...@ecbaldwin.net wrote: As the Neutron L3 Lieutenant along

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric jbelama...@infoblox.com wrote: Wow, a lot to digest in these threads. If I can summarize my understanding of the two proposals. Let me know whether I get this right. There are a couple problems that need to be solved: a. Scheduling based on

Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers

floating ips from the other blocks. On 20 July 2015 at 10:33, Carl Baldwin c...@ecbaldwin.net wrote: When creating a port, the binding information would be sent to the IPAM system and the system would choose an appropriate address block for the allocation. Implicit in both is a need to provide

[openstack-dev] [Neutron][L3] Representing a networks connected by routers

. I'm not convinced that IPAM and routing really belong together like this. If you made it this far in this email, you must have some feedback. Please help us out. Carl Baldwin [1] https://bugs.launchpad.net/neutron/+bug/1458890 [2] https://review.openstack.org/#/c/196812/ [3] http

[openstack-dev] [Neutron] Proposing Cedric Brandily to Neutron Core Reviewer Team

these areas of focus, please vote +1/-1 for the addition of Cedric to the team. Thanks! Carl Baldwin [1] https://review.openstack.org/#/q/reviewer:zzelle%2540gmail.com,n,z [2] http://stackalytics.com/report/contribution/neutron-group/90

Re: [openstack-dev] [Neutron] What are problems of Distributed SNAT?

Hi, There was some discussion a while back on this subject. Some alternatives were captured on etherpad [1] with pros and cons. Sorry for the delay in responding. The initial implementation of DVR went with centralized SNAT to reduce the scope of the effort and because of a lack consensus

Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team

+1! On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I am proposing to add Miguel Angel Ajo to the control plane core reviewer team. His review stats are inline with the other core reviewers[2], and his work on

Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

It has been a week and feedback has been positive and supportive of Brian's nomination. Welcome to the L3 core reviewer team, Brian. Carl On Wed, Jun 10, 2015 at 1:11 PM, Carl Baldwin c...@ecbaldwin.net wrote: Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose

Re: [openstack-dev] [Neutron] Quota enforcement

On Tue, Jun 16, 2015 at 12:33 AM, Kevin Benton blak...@gmail.com wrote: Do these kinds of test even make sense? And are they feasible at all? I doubt we have any framework for injecting anything in neutron code under test. I was thinking about this in the context of a lot of the fixes we have

Re: [openstack-dev] [Neutron] Quota enforcement

On Thu, Jun 11, 2015 at 2:45 PM, Salvatore Orlando sorla...@nicira.com wrote: I have been then following a different approach. And a set of patches, including a devref one [2], if up for review [3]. This hardly completes the job: more work is required on the testing side, both as unit and

Re: [openstack-dev] [Neutron] Quota enforcement

On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando sorla...@nicira.com wrote: But zzzeek (Mike Bayer) is coming to our help; as a part of his DBFacade work, we should be able to treat active/active cluster as active/passive for writes, and active/active for reads. This means that the write set

Re: [openstack-dev] [Neutron] Quota enforcement

On Tue, Jun 16, 2015 at 5:17 PM, Kevin Benton blak...@gmail.com wrote: There seems to be confusion on what causes deadlocks. Can one of you explain to me how an optimistic locking strategy (a.k.a. compare-and-swap) results in deadlocks? Take the following example where two workers want to

Re: [openstack-dev] [Neutron] Proposing Rossella Sblendido for the Control Plane core team

+1! On Fri, Jun 12, 2015 at 1:44 PM, Kevin Benton blak...@gmail.com wrote: Hello! As the Lieutenant of the built-in control plane[1], I would like Rossella Sblendido to be a member of the control plane core reviewer team. Her review stats are in line with other cores[2] and her feedback on

[openstack-dev] [Neutron][L3] Modular L3 Discussion

Hi all, Cross posting to openstack-dev and openstack-operators We discussed supporting multiple types of routers within a Neutron in the L3 meeting this morning [1]. The team would like more feedback from the community in order to refine use cases and also to consider possible approaches to

[Openstack-operators] [Neutron][L3] Modular L3 Discussion

Hi all, Cross posting to openstack-dev and openstack-operators We discussed supporting multiple types of routers within a Neutron in the L3 meeting this morning [1]. The team would like more feedback from the community in order to refine use cases and also to consider possible approaches to

Re: [openstack-dev] [neutron][L3] L3 routed network segments

Neil, I'm very glad to here of your interest. I have been talking with Kyle Mestery about the rfe you mention [1] since the day he filed it. It relates to a blueprint that I have been trying to get traction on [2] in various forms for a while [*]. The rfe talks about attaching VMs directly to

Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API DB core reviewer team

+1! On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau ges...@cisco.com wrote: As one of the Lieutenants [1] for the API and DB areas under the PTL, I would like to propose Ann Kamyshnikova as a member of the Neutron API and DB core reviewer team. Ann has been a long time contributor in Neutron

Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team

+1 On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his

[openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team

Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose Brian Haley as a member of the Neutron L3 core reviewer team. Brian has been a long time contributor in Neutron showing expertise particularly in IPv6, iptables, and Linux kernel matters. His knowledge and

[openstack-dev] Fwd: [neutron] - L3 scope-aware security groups

On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton blak...@gmail.com wrote: There is a bug in security groups here: https://bugs.launchpad.net/neutron/+bug/1359523 In the example scenario, it's caused by conntrack zones not being isolated. But it also applies to the following scenario that can't be

Re: [openstack-dev] [all][python3] use of six.iteritems()

+1 Don't forget values and keys in addition to items. They aren't as common but come up every so often. I think you can iterate the keys just by iterating on the dict itself. Carl On Jun 9, 2015 6:18 PM, Robert Collins robe...@robertcollins.net wrote: I'm very glad folk are working on

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

On Thu, Jun 4, 2015 at 3:20 PM, Kevin Benton blak...@gmail.com wrote: After trying to reproduce this, I'm suspecting that the issue is actually on the server side from failing to drain the agent report state queue in time. I set the report_interval to 1 second on the agent and added a logging

Re: [openstack-dev] [Neutron] L3 agent rescheduling issue

Ann, Thanks for bringing this up. It has been on the shelf for a while now. Carl On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando sorla...@nicira.com wrote: One reason for not sending the heartbeat from a separate greenthread could be that the agent is already doing it [1]. The current

Re: [openstack-dev] [neutron] Proposing Assaf Muller for the Neutron Core Reviewer Team

+1 On Thu, May 28, 2015 at 6:42 AM, Kyle Mestery mest...@mestery.com wrote: Folks, I'd like to propose Assaf Muller to be a member of the Neutron core reviewer team. Assaf has been a long time contributor in Neutron, and he's also recently become my testing Lieutenant. His influence and

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

On Tue, May 26, 2015 at 11:05 AM, Brian Haley brian.ha...@hp.com wrote: On 05/26/2015 01:12 PM, Salvatore Orlando wrote: From the bug Kevin reported it seems multiple dhcp agents per network have been completely broken by the fix for bug #1345947, so a revert of patch [1] (and stable

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

On May 21, 2015 9:06 AM, Kyle Mestery mest...@mestery.com wrote: On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.com wrote: After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying what if questions, it is

Re: [openstack-dev] [neutron] Neutron API rate limiting

@Gal, your proposal sounds like packet or flow rate limiting of data through a port. What Ryan is proposing is rate limiting of api requests to the server. They are separate topics, each may be a valid need on its own but should be considered separately. @Ryan, I tend to agree that rate

Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?

On Tue, May 5, 2015 at 11:47 AM, Salvatore Orlando sorla...@nicira.com wrote: I suggest to not enable it by default, and then consider in L-3 whether we should do this switch. I agree. At the least, the switch should be decoupled from that patch. I think decoupling them before merging the

Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

On Wed, May 6, 2015 at 12:46 AM, Mike Spreitzer mspre...@us.ibm.com wrote: While I am a Neutron operator, I am also a customer of a lower layer network provider. That network provider will happily give me a few /64. How do I serve IPv6 subnets to lots of my tenants? In the bad old v4 days

Re: [openstack-dev] [neutron] Are routed TAP interfaces (and DHCP for them) in scope for Neutron?

This brings up something I'd like to discuss. We have a config option called allow_overlapping_ips which actually defaults to False. It has been suggested [1] that this should be removed from Neutron and I've just started playing around with ripping it out [2] to see what the consequences are.

Re: [openstack-dev] [Neutron] Success of the IPv6 Subteam - Proposal to disband

On Mon, May 4, 2015 at 7:51 PM, Kyle Mestery mest...@mestery.com wrote: Sean and team, thanks for all your awesome work on IPv6 in Neutron over the past two cycles! And thanks for volunteering to disband and go out on top, integrating back into the broader team. It's a good move and would make

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

Jacob, I don't have your original email from which to reply. So, hopefully this finds you just as well. The bad news is that I don't have an immediate answer to address this. However, I thought it was worth mentioning where the future may lead. I have been thinking about the scenario that you

Re: [openstack-dev] [neutron][stable] Bug 1414218 is not fixed on in neutron stable/juno branch

Stephen, On Thu, Apr 16, 2015 at 4:21 PM, Ma, Stephen B. stephen...@hp.com wrote: As it stands currently, neutron on the stable/juno branch behaves as if https://review.openstack.org/#/c/164329/ was never merged. The merge of patch https://review.openstack.org/#/c/153181 puts some LOG.debug

Re: [openstack-dev] [Neutron] - Joining the team - interested in a Debian Developer and experienced Python and Network programmer?

is something we'll look at again for Liberty. Carl Baldwin leads the L3 work in Neutron, and would be a good person to sync with on this work item. I suspect he may be looking for people to help integrate the BGP work in Liberty, this may be a good place for you to jump in. I have a single stand alone

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar pbon...@infoblox.com wrote: Hi, I made some investigation on the topic[1] and see several issues on this way. 1. Plugin's create_port() is wrapped up in top level transaction for create floating ip case[2], so it becomes more complicated to do

<    1   2   3   4   >