Re: [openstack-dev] Multiple patches in one review

+1 to all Ben said. There are reasons to split things up in to a logical progression of changes but each change must stand alone and must pass tests. Carl On Mon, Mar 24, 2014 at 10:03 AM, Ben Nemec wrote: > I should point out that Jenkins can't apply the next patch in sequence > just to get te

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

Don't discard the first number so quickly. For example, say we use a timeout mechanism for the daemon running inside namespaces to avoid using too much memory with a daemon in every namespace. That means we'll pay the startup cost repeatedly but in a way that amortizes it down. Even if it is rea

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

I was thinking that we could document the information about sudo and iproute2 patches with the upcoming release. How would I go about doing this? Is there any section in our documentation about OS level tweaks or requirements such as these that could present this information as part of the releas

Re: [openstack-dev] dhcp port creation

Hanish, I have observed this behavior as well. Without digging in to recall the details, I believe that when the DHCP agent restarts, it makes a call that schedules any unscheduled networks to it. Upon scheduling the network to the agent, the port is created by the agent. Without restarting the

[openstack-dev] [Neutron][L3] Dynamic Routing Use Cases

Hi All, The neutron L3 subteam [1] has been discussing dynamic routing use cases for a couple of weeks in our meeting. I attempted to capture the use cases at a high level here [2]. It is far from complete, I'd like some feedback from the community on the use cases. Carl Baldwin [1]

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

Tomorrow's meeting will be at 1500 UTC in #openstack-meeting-3. The current agenda can be found on the subteam meeting page [1]. New on the agenda this week: Multiple Subnets on External Network Carl [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda __

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

+1. I think we'll like this process better. I hope to have some of the first blueprints to propose to the new repository very soon. On Tue, Apr 15, 2014 at 4:07 PM, Kyle Mestery wrote: > Given the success the Nova team has had in handling reviews using > their new nova-specs gerrit repository,

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

opic on this [2]. Carl Baldwin Neutron L3 Subteam Lead [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda [2] http://summit.openstack.org/cfp/details/81 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.op

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Neutron (and Nova), I have had one thing come up as I've been using the template. I find that I would like to add just a little document structure in the form of a sub-heading or two under the "Proposed change" heading but before the required "Alternatives" sub-heading. However, this is not allo

Re: [openstack-dev] Reviewing spelling and grammar errors in blueprints Re: [Nova] nova-specs

Personally, I try not to be disagreeable and to be considerate in my reviews. However, I don't want to worry too much about hurting someone's feelings by making a comment. As a community we should be considerate and polite but we should also embrace critical reviews of our own work. I think addi

Re: [openstack-dev] Reviewing spelling and grammar errors in blueprints Re: [Nova] nova-specs

I'd prefer that others *not* upload a new patch over mine just to make a spelling correction. I might be in the middle of another version of the patch myself and mine will overwrite yours. If you want to upload a patch over mine please ask me first so that we can coordinate and discuss the change

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

14 at 3:43 PM, Kyle Mestery wrote: > On Wed, Apr 16, 2014 at 4:26 PM, Carl Baldwin wrote: >> Neutron (and Nova), >> >> I have had one thing come up as I've been using the template. I find >> that I would like to add just a little document structure in the form

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

I don't see any indication that a floating ip can be associated with any of the secondary addresses. Can this be done? If not, then multiple addresses are not useful if a floating ip is required to make the server public facing. Carl On Wed, Apr 16, 2014 at 10:46 PM, Aaron Rosen wrote: > The a

Re: [openstack-dev] [neutron] Neutron BP review process for Juno

Wow, easiest merge ever! Can we get this repository counted in our stats?! ;) Carl On Thu, Apr 17, 2014 at 1:09 PM, Kyle Mestery wrote: > On Thu, Apr 17, 2014 at 1:18 PM, Carl Baldwin wrote: >> Sure thing [1]. The easiest change I saw was to remove the >> restriction that th

Re: [openstack-dev] [Openstack][nova][Neutron] Launch VM with multiple Ethernet interfaces with I.P. of single subnet.

port-show. Carl On Thu, Apr 17, 2014 at 12:29 PM, Carl Baldwin wrote: > I don't see any indication that a floating ip can be associated with > any of the secondary addresses. Can this be done? > > If not, then multiple addresses are not useful if a floating ip is > required

Re: [openstack-dev] [NEUTRON] [IPv6] [VPNaaS] - IPSec "by default" on each Tenant router, the beginning of the Opportunistic Encryption era (rfc4322 ?)...

Keys are distributed via dns records. https://tools.ietf.org/html/rfc4322 Carl On Apr 21, 2014 5:35 PM, "Kevin Benton" wrote: > This is interesting. How is key distribution handled when I want to use OE > with someone like Google.com for example? > > > On Thu, Apr 17, 2014 at 12:07 PM, Martinx

Re: [openstack-dev] [Neutron][L3] Agent manager customization

Cedric, I'm just getting back from a short vacation. Please excuse the delayed reply. I have a feeling that this subject may have been discussed in the past before I was very active in Neutron. So, others may chime in if I'm missing something. For the customizations that you're making, it soun

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

on this. - DNS Resolution internal and external to Neutron - Pluggable External Networks Carl Baldwin Neutron L3 Subteam Lead [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda ___ OpenStack-dev mailing list OpenStack-dev@lists.ope

Re: [openstack-dev] [Nova] [All] API standards working group

On Wed, Sep 24, 2014 at 11:05 AM, David Stanek wrote: > > > On Wed, Sep 24, 2014 at 11:42 AM, Dean Troyer wrote: >> >> On Tue, Sep 23, 2014 at 5:18 PM, Jay Pipes wrote: >>> >>> Yes, I'd be willing to head up the working group... or at least >>> participate in it. >> >> >> I'll bring an API consu

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

The Neutron L3 Subteam will meet tomorrow at the regular time and place. The agenda and details are posted [1]. I think the RC1 ship will have sailed for most potential fixes by then so I'd like to take some time during the meeting tomorrow to chat about the work that is coming up for Kilo. Ther

Re: [openstack-dev] [neutron] Updates to the weekly Neutron meting

Kyle, This works for me. My only comment is that linking sub team pages from the Neutron meeting page served a dual purpose. It attached it to the agenda -- which is now deprecated -- and it served as sort of an anchor for the sub team in to the Neutron team on the wiki. At least for the L3 sub

Re: [openstack-dev] [neutron] Updates to the weekly Neutron meting

> > Thanks, > Kyle > > [1] https://wiki.openstack.org/wiki/NeutronSubTeams > > On Mon, Oct 13, 2014 at 2:41 PM, Carl Baldwin wrote: >> Kyle, >> >> This works for me. My only comment is that linking sub team pages >> from the Neutron meeting page served a du

[openstack-dev] [Neutron][L3][IPAM] No Team Meeting Thursday

I just had a conflict come up. I won't be able to make it to the meeting. I wanted to announce that IPAM is very likely topic for a design session at the summit. I will spend some time reviewing the old etherpads starting here [1] since the topic was set aside early in Juno. Carl [1] https://e

Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion

Hi Elena, On Thu, Oct 23, 2014 at 4:22 AM, Elena Ezhova wrote: > Kill the connection using conntrack > > The problem here is that it is sometimes impossible to tell which > connection should be killed. For example there may be two instances running > in different namespaces that have th

Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion

Miguel Ángel, On Thu, Oct 23, 2014 at 5:56 AM, Miguel Angel Ajo Pelayo wrote: > Temporarily removing this entry doesn't seem like a good solution > to me as we can't really know how long do we need to remove this rule to > induce the connection to close at both ends (it will only close if any > n

Re: [openstack-dev] Travels tips for the Paris summit

+1 It would be great to know where to go in the airport and what to ask for for a good 1 - 1.5 week prepaid GSM data plan. Carl On Fri, Oct 24, 2014 at 11:01 AM, Mathieu Gagné wrote: > On 2014-10-14 11:35 AM, Adrien Cunin wrote: >> >> Hi everyone, >> >> Inspired by the travels tips published fo

Re: [openstack-dev] [Neutron] Killing connection after security group rule deletion

On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando wrote: > Assigning a distinct ct zone to each port sounds more scalable. This should > keep the number of zones per host Agree that zones could be a good solution to this problem. +1 to zone / port for scalability. Though it will take a bit mor

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

On Mon, Oct 27, 2014 at 6:34 AM, Simon Pasquier wrote: > Hello Itzik, > This has been discussed lately on this ML. Please see > https://bugs.launchpad.net/neutron/+bug/1335375. This is a good example that any create, update, or delete of a SG rule can expose this issue. This bug only mentions de

Re: [openstack-dev] [Neutron] FWaaS/Security groups Not blocking ongoing traffic

I think I'd suggest opening a new bug for FWaaS since it is a different component with different code. It doesn't seem natural to extend the scope of this bug to include it. Carl On Mon, Oct 27, 2014 at 9:50 AM, Itzik Brown wrote: > > - Original Message - >> From:

Re: [openstack-dev] [neutron][nova] New specs on routed networking

On Tue, Oct 28, 2014 at 2:01 PM, Kevin Benton wrote: > I think the simplest use case is just that a provider doesn't want to deal > with extending L2 domains all over their datacenter. This is similar to a goal behind [1] and [2]. I'm trying to figure out where the commonalities and differences

Re: [openstack-dev] [neutron][nova] New specs on routed networking

On Tue, Oct 28, 2014 at 3:07 PM, Rohit Agarwalla (roagarwa) wrote: > Agreed. The way I'm thinking about this is that tenants shouldn't care what > the underlying implementation is - L2 or L3. As long as the connectivity > requirements are met using the model/API, end users should be fine. > The da

Re: [openstack-dev] [Neutron] BGP - VPN BoF session in Kilo design summit

> etherpad[3] to share ideas and agree with session schedule. I propose > Wednesday afternoon. > > If Carl Baldwin is agree, we can talk about it also during the open > discussion of today's L3 subteam meeting. > > [1]: https://review.openstack.org/#/c/125401/ > [ > ​2]:

Re: [openstack-dev] [neutron][opendaylight]OpenDaylight Neutron Plugin design session etherpad

https://etherpad.openstack.org/p/odl-neutron-plugin On Mon, Nov 3, 2014 at 4:05 AM, Richard Woo wrote: > Hi, what is etherpad link for opendaylight neutron plugin design session? > > http://kilodesignsummit.sched.org/event/5a430f46842e9239ea6c29a69cbe4e84#.VFdhdPTF-0E > > Thanks, > > Richard > >

Re: [openstack-dev] [Neutron]why FIP is integrated into router not as a separated service like XxxaaS?

I don't think I know the precise answer to your question. My best guess is that floating ips were one of the initial core L3 features implemented before other advanced services existed. Implementing them in this way may have been the path of least resistance at the time. Are you suggesting a cha

Re: [openstack-dev] [ironic] the possible use of dhcp client id

Hi Chuck, I should probably chime in since I made the initial comment in the first place. I hate to derail the progress you've made with the blueprint you have up now but this is worth some discussion. On Wed, Nov 12, 2014 at 3:38 PM, Chuck Carlino wrote: > It has been proposed that both issues

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

Reminder that the L3 subteam meeting will be tomorrow at 1500 UTC. Remember that daylight savings time may have ended since the last meeting and the meeting will come an hour earlier. I'd like to talk about the subjects discussed at the summit. Specifically, we had design sessions about paying dow

Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

On Thu, Nov 13, 2014 at 1:00 PM, Salvatore Orlando wrote: > No worries, > > you get one day off over the weekend. And you also get to choose if it's > saturday or sunday. I didn't think it was going to be a whole day. > Salvatore > > On 13 November 2014 20:05, Kevin Benton wrote: >> >> December

Re: [openstack-dev] [Neutron] Stale patches

+1. I always hesitate to abandon someone's patch because it is so personal. The auto-expire is impersonal and procedural. I agree that 1 week is too soon. Give it at least a month. Abandoned patches that have some importance shouldn't ever really be lost. They should be linked to bug reports

Re: [openstack-dev] [Neutron]One security issue about floating ip

There is a bit more to it. The floating ip was dissociated which means it should have been removed from the gateway device. How long did the connection stay up? Was this a matter of the l3 agent getting a little behind and not processing the update for a while? Can you confirm that the floating

Re: [openstack-dev] [Neutron] One performance issue about VXLAN pool initiation

++. This might also be useful in ipam. I'll have a look at the patch regardless for the short term. (I had actually suggested something similar on Eugene's patch review.) Carl On Jun 26, 2014 8:14 AM, "Zang MingJie" wrote: > it would be better to make the range increase dynamic, instead of cr

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

Paul, Is there a blueprint filed on the subject of logging? This really doesn't have anything to do with DVR. The current solution has no logging either. Carl On Thu, Jun 26, 2014 at 5:41 AM, CARVER, PAUL wrote: > > > > > > > Original message > From: Yi Sun > Date: > To: op

Re: [openstack-dev] DVR and FWaaS integration

The east/west case is the only case with this asymmetric routing problem being discussed. However, the north/south case might still be interesting from a FWaaS perspective. The fact that the router is distributed in pieces may affect it depending on the firewall implementation. Carl On Jun 28, 2

Re: [openstack-dev] DVR and FWaaS integration

In line... On Jun 25, 2014 2:02 PM, "Yi Sun" wrote: > > All, > During last summit, we were talking about the integration issues between DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But after that meeting I was tight up with my work and did not get time to continue to foll

Re: [openstack-dev] [third-party] - rebasing patches for CI

It could be that it this behavior has merely become more noticeable since Jenkins is now reverifying patch sets when new comments show up and it sees that the patch set hasn't been verified recently. Carl On Tue, Jul 1, 2014 at 5:00 PM, Jeremy Stanley wrote: > On 2014-07-01 10:05:45 -0700 (-0700

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

The Neutron L3 Subteam will meet tomorrow at the regular time in #openstack-meeting-3. The agenda [1] is posted, please update as needed. DVR is our priority. I have had some encouraging success this week deploying my own two-node devstack with distributed routers. I would like to discuss that

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

+1 I'm pretty excited about the possibilities here. I've had this mysqldb/eventlet contention in the back of my mind for some time now. I'm glad to see some work being done in this area. Carl On Fri, Jul 11, 2014 at 7:04 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: S

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

On Jul 11, 2014 5:32 PM, "Vishvananda Ishaya" wrote: > > I have tried using pymysql in place of mysqldb and in real world concurrency > tests against cinder and nova it performs slower. I was inspired by the mention > of mysql-connector so I just tried that option instead. Mysql-connector seems >

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

Clark, You make a good point. It's there some resistance to this or is it just a matter of asking? Carl On Jul 11, 2014 12:23 PM, "Clark Boylan" wrote: > Before we get too far ahead of ourselves mysql-connector is not hosted > on pypi. Instead it is an external package link. We recently manage

Re: [openstack-dev] [neutron][all] switch from mysqldb to another eventlet aware mysql client

+1. Well put. No one is arguing against this other approach. The two efforts can be taken independently. Carl On Jul 11, 2014 10:48 PM, "Mike Bayer" wrote: > > On 7/11/14, 11:26 PM, Jay Pipes wrote: > > Yep, couldn't agree more. > > > > Frankly, the steps you outline in the wiki above are exce

Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline

+1 This spec had already been proposed quite some time ago. I'd like to see this work get in to juno. Carl On Jul 12, 2014 9:53 AM, "Yuriy Taraday" wrote: > Hello, Kyle. > > On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery > wrote: > >> Just a note that yesterday we passed SPD for Neutron. We ha

Re: [openstack-dev] [neutron] [nova] Weekly nova-network / neutron parity meeting

Kyle, Somehow I missed this thread until now. I will encourage the dvr team to be there. It's this still the time? Carl On Jul 16, 2014 8:24 PM, "Kyle Mestery" wrote: > As we're getting down to the wire in Juno, I'd like to propose we have > a weekly meeting on the nova-network and neutron pa

Re: [openstack-dev] [Neutron] Gap 0 (database migrations) closed!

Anna, Your second point is going to be a bit of a maintenance headache. I was reviewing a patch [1] where you caught the lack of an import in head.py. I'm not sure that I can be trusted to check consistently for this in future reviews. I'm not sure that we can rely on you catching them all eith

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support

+1 I think this is important for scalability. On Jul 23, 2014 5:45 PM, "Miguel Angel Ajo Pelayo" wrote: > +1 > > Sent from my Android phone using TouchDown (www.nitrodesk.com) > > > -Original Message- > From: Yuriy Taraday [yorik@gmail.com] > Received: Thursday, 24 Jul 2014, 0:42 > T

Re: [openstack-dev] [neutron] Add static routes on neutron router to devices in the external network

I wondered the same as Kevin. Could you confirm that the vpn gateway is directly connected to the external subnet or not? The diagram isn't quite clear Assuming it is directly connected then it is probable that routes through the external gateway are not considered, hence the error you received.

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

The Neutron L3 Subteam will meet tomorrow at the regular time in #openstack-meeting-3. The agenda [1] is posted, please update as needed. See you there! The initial DVR implementation has merged as of today. Please review the notes and log from the DVR meeting today [2]. I will be sure to allo

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

Kyle, Let me know if I can help resolve the concerns around rootwrap. I think in this case, the return on investment could be high with a relatively low investment. Carl On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery wrote: > I wanted to send an email to let everyone know where we're at in the

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

Armando's point #2 is a good one. I see that we should have raised awareness of this more than we did. The bulk of the discussion and the development work moved over to the oslo team and I focused energy on other things. What I didn't realize was that the importance of this work to Neutron did n

Re: [openstack-dev] [all] specs.openstack.org is live

I have a spec proposal in play that crosses the Nova/Neutron boundary. I split it in to two specs: a nova spec [1] and a Neutron spec [2]. There is a little duplication between the two at a high level but not in the details. Each of the specs references the other at various spots in the text and

[openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

Hi, I noticed this yesterday afternoon. I tried to run pep8 and unit tests on a patch I was going to submit. It failed with an error that no package satisfying oslo.config could be found [1]. I went to pypi and saw that the version appears to be available [2] but still couldn't install it. I t

Re: [openstack-dev] [Neutron][oslo] Problem installing oslo.config-1.4.0.0a3 from .whl files

v). > It fixed this problem for me. > > Regards, > Alexei > > > On 05/08/14 23:00, Carl Baldwin wrote: >> >> Hi, >> >> I noticed this yesterday afternoon. I tried to run pep8 and unit >> tests on a patch I was going to submit. It failed with an error

[openstack-dev] [Neutron][L3] Team Meeting Thursday at 1500 UTC

Apologies for the late notice... The Neutron L3 Subteam will meet tomorrow at the regular time in #openstack-meeting-3. The agenda [1] is posted, please update as needed. Carl [1] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam#Agenda ___

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

Swami, I would like to participate in discussions as well. Carl On Tue, Oct 22, 2013 at 12:50 PM, Vasudevan, Swaminathan (PNB Roseville) wrote: > Hi Folks, > > Thanks for your interests in the DVR feature. > > We should get together to start discussing the details in the DVR. > > Please let me

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

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] [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] 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] [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] [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] 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] [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 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] 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 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 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,

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

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] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

tl;dr Merge changes to process documentation before expecting them to be followed! :) On Tue, May 17, 2016 at 4:25 AM, Ihar Hrachyshka wrote: > 2016.1.0 tag is in the repo, and is part of stable/mitaka branch. > > Git tag history suggests that Carl pushed it (manually I guess?) It seems > that

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On Tue, May 17, 2016 at 10:56 AM, Kevin Benton wrote: >>a) Deleting network's last segment will be prevented. Every network should >> have at least one segment to let the port to bind. > > This seems a bit arbitrary to me. If a segment is limited to a small part of > the datacenter, it being able

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On May 17, 2016 2:18 PM, "Kevin Benton" wrote: > > >I kind of think it makes sense to require evacuating a segment of its ports before deleting it. > > Ah, I left out an important assumption I was making. We also need to auto delete the DHCP port as the segment is deleted. I was thinking this will

Re: [openstack-dev] [Neutron][ML2][Routed Networks]

On Wed, May 18, 2016 at 5:24 AM, Hong Hui Xiao wrote: > I update [1] to auto delete dhcp port if there is no other ports. But > after the dhcp port is deleted, the dhcp service is not usable. I can I think this is what I expect. > resume the dhcp service by adding another subnet, but I don't thi

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

On Wed, May 18, 2016 at 1:36 PM, Kevin Benton wrote: >>I may have wrongly assumed that segments MAY have the possibility of being >> l2 adjacent, even if the entire network they are in is not, which would mean >> that viewing and scheduling these in the context of a segment could be >> useful. > >

Re: [openstack-dev] [release] Re: [Neutron][L2GW] Mitaka release of L2 Gateway now available

On Thu, May 19, 2016 at 7:09 AM, Doug Hellmann wrote: > We have the same issue with version numbers regressing no matter when we > cut the next release, so it's up to the team. It might be easier to deal > with now while it's fresh in our minds. > > I would like to update the instructions that wer

Re: [openstack-dev] [neutron] Update_port can not remove allocation from auto-addressed subnets

On Fri, May 20, 2016 at 6:06 AM, Pavel Bondar wrote: > Hi, > > Currently using update_port workflow user can not remove ip addresses from > auto-addressed subnets (SLAAC). It prevents me from implementing complete > fix for [1]. > > Typically for removing ip address from port, 'fixed_ips' list is

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

On Fri, May 20, 2016 at 1:44 PM, Brandon Logan wrote: > On Thu, 2016-05-19 at 14:16 -0600, Carl Baldwin wrote: >> On Wed, May 18, 2016 at 1:36 PM, Kevin Benton wrote: >> >>I may have wrongly assumed that segments MAY have the possibility of being >> >> l2 adj

Re: [openstack-dev] [neutron] DHCP Agent Scheduling for Segments

AZ. So why are we not able to leverage > that logic or make it more generic? > Thanks > Gary > > On 5/22/16, 4:02 AM, "Carl Baldwin" wrote: > > >On Fri, May 20, 2016 at 1:44 PM, Brandon Logan > > wrote: > >> On Thu, 2016-05-19 at 14:16 -0600, C

[openstack-dev] [Neutron] Question about service subnets spec

Hi folks, Some (but not all) of you will remember a discussion we had about service subnets at the last mid-cycle. We've been iterating a little bit on a spec [1] and we have just one issue that we'd like to get a little bit more feedback on. As a summary: To me, the idea of this spec is to res

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Wed, Jun 1, 2016 at 9:48 AM, zhi wrote: > hi, all > > I have some questions about north/south traffic in DVR mode. > > As we all know, packets will be sent to instance's default gateway (qr > interface) when an instance want to communicate to the external network. > Next, these packets

Re: [openstack-dev] [neutron][dvr] Wasting so many external network IPs in DVR mode?

On Thu, Jun 2, 2016 at 12:04 AM, zhi wrote: > The reason putting the routers namespaces behind the fip namespace is > saving mac address tables in switches. In Centralized Virtual Router, there > are many "qg" interfaces in the external bridge. Every "qg" interface may > contains one or more

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

On Fri, Jun 3, 2016 at 11:16 AM, Darek Smigiel wrote: > Hello, > Doing reviews I noticed, that Liu Yong submitted a bug [1] where we have a > problem with removing subnets. This makes me wonder what the use case that gets in to this situation. > In short: if tenant wants to delete network with

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

On Fri, Jun 3, 2016 at 2:26 PM, Henry Gessau wrote: > Darek Smigiel wrote: >> strange, that owner is not able to just get rid of *his* network and subnets. > > But not all the subnets are his, and consequently the network is partially not > his. To me, this is a nonsensical outcome and tells me

Re: [openstack-dev] [Neutron] Question about service subnets spec

Thanks, John for your comments. I've added a few comments inline. In summary, I'm inclined to move forward with this as an admin-only operation to begin with. I'll give another day or two for someone new to take notice. Carl On Tue, Jun 7, 2016 at 7:56 AM, John Davidge wrote: > Resurrecting t

Re: [openstack-dev] [neutron][upgrades] Bi-weekly upgrades work status. 6/2/2016

On Thu, Jun 2, 2016 at 2:29 PM, Korzeniewski, Artur wrote: > I would like to remind that agreed approach at Design Summit in Austin was, > that every new resource added to neutron should have OVO implemented. Please > comply, and core reviewers please take care of this requirements in patches > yo

[openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

to start rounding up the reviewers and other participants we need to see how we can start putting together a plan for nova integration of this feature (via os-vif?). Carl Baldwin [1] https://review.openstack.org/#/q/topic:bp/vlan-aware-vms+-status:abandoned

Re: [openstack-dev] [Neutron] Random IP address allocations

On Fri, Jun 10, 2016 at 2:40 AM, Gary Kotton wrote: > Hi, > The patch https://review.openstack.org/#/c/292207/ has broken decomposed > plugins. I am not sure if we can classify this as a API change – basically Can you be more specific about how it "has broken decomposed plugins?" What's broken?

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

Here's a link directly to the current design proposal [1] that might be of interest. [1] https://review.openstack.org/#/c/318317/4/doc/source/devref/openvswitch_agent.rst@463 On Thu, Jun 9, 2016 at 5:31 PM, Carl Baldwin wrote: > Hi, > > You may or may not be aware of the vlan-aw

Re: [openstack-dev] [Neutron][os-vif] Expanding vif capability for wiring trunk ports

I know I've been pretty quiet since I started this thread. Y'all have been doing so well, I've just been reading the thread every day and enjoying it. I thought I'd top post here to kind of summarize. I see wisdom in the strategy suggested by Sean Mooney to make a very minimal change to os-vif t

[openstack-dev] [Neutron][IPAM] Anyone using builtin pluggable IPAM driver?

Hi, Cross posting to the operators and devs. In Liberty, pluggable IPAM was added to Neutron. With it, a built-in pluggable driver, equivalent to the old non-pluggable IPAM was added as a reference implementation. In a greenfield deployment, you could choose to use this driver by setting the fol

Re: [openstack-dev] [Neutron] Elevating context to remove subnets created by admin

subnet should also not have a tenant_id and should just inherit it from the network. Carl [1] https://review.openstack.org/#/c/331497/2/neutron/db/segments_db.py On Fri, Jun 3, 2016 at 3:05 PM, Henry Gessau wrote: > Carl Baldwin wrote: >> On Fri, Jun 3, 2016 at 2:26 PM, Henry Gess

<    1   2   3   4   5   >