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 scroll bar shows a smal

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 wrote: > I noticed a couple of things today while reviewing a largish page [1]. > First, when I search for something usi

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] [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 shared network’s subnet from

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 have no > idea, where

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 PD[1], unfortunately,

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 constrained jobs in Neutron worl

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 with > the code that t

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 Neutron actively he

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 fault. We need to

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. The easiest bookmarkable

Re: [openstack-dev] [Neutron][DVR]

nt: Friday, December 11, 2015 3:12 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][DVR] > > > > > > > > On 3 December 2015 at 10:46, Carl Baldwin wrote: > > I was going to bring this up in the meeting thi

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 2 to find informati

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 Neutron core > reviewer to

[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 kn

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 >> > wrote: >>> >>> On Wed, Nov 18,

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 why it didn't >> g

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 > 3) list of blueprints

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 sticks...So far I got Neutrinos, > Neutronians, and Neutrit

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 getting this figured out over the

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 review > code, pleas

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 critical bugfixes > and secu

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 this by naming > physical networ

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 makes it a hassle to

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 that we want to aband

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 decided to work on this > netwo

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: > > - Stabilize DVR - fix the bugs

[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 wo

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 http://docs.openstack.org/developer/networking-calico/: > > networking-calico

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 community, and to celebrate littl

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 > notes are being discus

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 network to the router w

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 [1] to resume the work o

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 now even with DVR, the

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

On Tue, Sep 15, 2015 at 8:40 PM, shihanzhang wrote: > [1] https://bugs.launchpad.net/neutron/+bug/1486795 > [2] https://bugs.launchpad.net/neutron/+bug/1486828 > [3] https://bugs.launchpad.net/neutron/+bug/1496201 > [4] https://bugs.launchpad.net/neutron/+bug/1496204 > [5] https://bugs.launchpad.n

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 currently possible to ha

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 floating IPs from the same

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 broadcast domain and

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 I'm sure, others), I

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

e bugs out, 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 wrote: > Hi, > > Carl Baldwin, Doug Wiegley, Matt Kassawara, Ryan Moats, and mys

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 summary here seems to show t

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 Pavlov wrote: >> >>

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 branch [1]. This is not a

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

On Mon, Aug 31, 2015 at 11:02 AM, Armando M. wrote: > > > On 31 August 2015 at 09:53, Jeremy Stanley wrote: >> >> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote: >> > I was under the impression that we had a plan to stop allowing these >> &g

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 time, truly. > Not

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 di

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 though

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 wrote: > Thanks Neil, we'll review this during the drivers meeting this week. It's

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][L3] [Large Deployments Team] Representing a networks connected by routers

On Mon, Aug 3, 2015 at 9:07 PM, Mike Dorman 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 sent the wrong messag

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 d

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 8:39 PM, "Paul Carver" 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 implementation.) Su

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

On Jul 23, 2015 6:04 PM, "Kevin Benton" 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 because an L

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

On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton 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 floating IPs from

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

On Tue, Jul 21, 2015 at 8:41 AM, Salvatore Orlando 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 and workflow you de

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

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton 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 yet. >>the neu

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

On Wed, Jul 22, 2015 at 3:21 PM, Kevin Benton 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 zone. This is

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

On Thu, Jul 23, 2015 at 8:51 AM, Kevin Benton 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 its network

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

On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton 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 >> east-west routi

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 wrote: > As the Neutron L3 Lieutenant along with Kevi

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

On Tue, Jul 21, 2015 at 1:11 PM, John Belamaric 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 host reachability to t

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

n based blocks which could host floating ips from the other blocks. > On 20 July 2015 at 10:33, Carl Baldwin 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 th

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

nant subnet behind a Neutron router in the same address scope as the external network. 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.launchp

[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-gro

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 aroun

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 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 improving

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 wrote: > Folks, > > As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to >

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

On Tue, Jun 16, 2015 at 5:17 PM, Kevin Benton 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 update a record

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

On Tue, Jun 16, 2015 at 2:18 PM, Salvatore Orlando 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 > certification i

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

On Tue, Jun 16, 2015 at 12:33 AM, Kevin Benton 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 for > othe

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

On Thu, Jun 11, 2015 at 2:45 PM, Salvatore Orlando 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 functional > tests. >

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 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 patches > re

[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 achi

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 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 feedback on >

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 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 showing exper

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 t

[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 involvemen

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" wrote: > I'm very glad folk are working on Python3 ports. > > I'd like t

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

On Mon, Jun 8, 2015 at 3:52 PM, Kevin Benton 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 solved by zo

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

On Thu, Jun 4, 2015 at 3:20 PM, Kevin Benton 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 > statement an

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 wrote: > One reason for not sending the heartbeat from a separate greenthread could > be that the agent is already doing it [1]. > The current proposed patch addre

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 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 knowledge in > testing

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

On Tue, May 26, 2015 at 11:05 AM, Brian Haley 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 backports)

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

On May 21, 2015 9:06 AM, "Kyle Mestery" wrote: > > On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando wrote: >> >> After putting the whole OpenStack networking contributors community through almost 8 cycles of pedant comments and annoying "what if" questions, it is probably time for me to relieve

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 limiting

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] IPv4 transition/interoperation with IPv6

On Wed, May 6, 2015 at 12:46 AM, Mike Spreitzer 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 this would > be eas

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 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 patch was the plan al

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

On Mon, May 4, 2015 at 7:51 PM, Kyle Mestery 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 > sense to cover

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. 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 > statements in

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

rid L3 North/South Neutron >>> router that propagates tenant routes and networks into OSPF/BGP via a >>> routing daemon, and uses floating MAC addresses/costed flow rules via >>> OVS to fail over to a hot standby router? There are practical use cases >>> for such

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

Have we found the last of them? I wonder. I suppose any higher level service like a router that needs to create ports under the hood (under the API) will have this problem. The DVR fip namespace creation comes to mind. It will create a port to use as the external gateway port for that namespace

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

On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar 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 IPAM > calls ou

Re: [openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow

e > weekend, so I will be looking at it today (hopefully). > > John > > > On 4/8/15, 11:26 AM, "Carl Baldwin" wrote: > >>I will not be available to chair or attend the L3 sub team meeting >>tomorrow. Are others okay with canceling the meeting

[openstack-dev] [Neutron][L3] L3 Subteam Meeting Tomorrow

I will not be available to chair or attend the L3 sub team meeting tomorrow. Are others okay with canceling the meeting? Let me know if you have something to discuss. Carl __ OpenStack Development Mailing List (not for usag

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

stage, and thank for > understanding. > > Akihiro > > 2015-03-31 5:28 GMT+09:00 Carl Baldwin : >> Akihiro, >> >> If we go with the empty extension you proposed in the patch will that be >> acceptable? >> >> We've got to stop killing new func

Re: [openstack-dev] [Neutron] Core API vs extension: the subnet pool feature

Akihiro, If we go with the empty extension you proposed in the patch will that be acceptable? We've got to stop killing new functionality on the very last day like this . It just kills progress. This proposal isn't new. Carl On Mar 30, 2015 11:37 AM, "Akihiro Motoki" wrote: > Hi Neutron folks

Re: [openstack-dev] [Openstack-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

Kevin, Thank you for your valuable insight here. Comments inline... On Wed, Mar 25, 2015 at 10:09 AM, Kevin Benton wrote: > This is a nice option for smaller deployments that didn't need the > complexity of NAT. From a custom L3 plugin perspective, it also eliminated > any single points of fail

<    1   2   3   4   5   >