Re: [openstack-dev] floating IP is DOWN

Probably that LOG statement is a line added for debugging purposes. There are several probable causes for a floating ip being down. If you see any traceback in the neutron server or l3-agent that will probably immediately reveal the root cause. On the other hand, lack of any traceback might

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

As for the notifier proposed above it is correct that neutron needs to be changed. This should not be a massive amount of work. Today it works with nova only pretty much because nova it's the only compute service it interacts with. The question brought aboud ping vs operational status is a very

Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

Neutron has the ability already of sending an event as a REST call to notify a third party that a port became active [1] This is used by Nova to hold on booting instances until network has been wired. Perhaps kuryr could leverage this without having to tap into the AMQP bus, as that would be

Re: [openstack-dev] [devstack][neutron] VMWare NSX CI - voting on devstack changes long after plugin decomposition

There is a job which has been turned on again by mistake and I'm working on ensuring it's put to sleep again (for good this time). If you can avoid disabling the whole account it would be great as the same credentials are used by the still-voting nova CI. Cheers, Salvatore On 3 May 2016 at

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

On 21 April 2016 at 16:54, Boden Russell wrote: > On 4/20/16 3:29 PM, Doug Hellmann wrote: > > Yes, please, let's try to make that work and contribute upstream if we > > need minor modifications, before we create something new. > > We can leverage the 'retrying' module

Re: [openstack-dev] [cross-project] [all] Quotas and the need for reservation

On 12 April 2016 at 15:48, Andrew Laski wrote: > > > On Tue, Apr 5, 2016, at 09:57 AM, Ryan McNair wrote: > > >It is believed that reservation help to to reserve a set of resources > > >beforehand and hence eventually preventing any other upcoming request > > >(serial or

Re: [openstack-dev] Nova quota statistics counting issue

For what is worth neutron employs "resource trackers" which conceptually do something similar to nova quota usage statistics. Before starting any transaction that can potentially change usage for a given resource, the quota enforcement mechanism checks for a "dirty" marker on the resource tracker.

Re: [openstack-dev] Floating IPs and Public IPs are not equivalent

Hey! This sounds like bike-shedding & yak-shaving... totally my thing! It is true that the Neutron model currently kind of forces a two-level topology, with the external network being a sort of special case. Regardless, this does not mean you cannot assign directly public IPs to your instances -

Re: [openstack-dev] [cross-project] [all] Quotas -- service vs. library

I'm not sure if this was mentioned already throughout the thread, however as I've been working a bit on quotas in the past I might have some additional information: - Looking at quotas it is worth distinguishing between management (eg:: resource limits per tenant and/or users), and enforcement

Re: [openstack-dev] [Neutron] RBAC: Fix port query and deletion for network owner

Indeed the VMware plugins were not using resource tracking (they know that my code should not be trusted!) I think this bears however another question that we need to answer... it is likely that some change broke quota enforcement for plugins which do not use usage tracking. When I developed

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

Some thoughts inline. Salvatore On 11 March 2016 at 23:15, Carl Baldwin wrote: > Hi, > > I have started to get into coding [1] for the Neutron routed networks > specification [2]. > > This spec proposes a new association between network segments and > subnets. This affects

Re: [openstack-dev] [Neutron][tempest] Timestamp service extension breaks CI

On 7 March 2016 at 10:54, Gary Kotton wrote: > There are a number of issues here: > >1. The create returns additional values, for example the binding:vnic_type, >whilst the get does not > > This is probably a consequence of fixing the behaviour mismatch between create

Re: [openstack-dev] [neutron] - Changing the Neutron default security group rules

On 3 March 2016 at 10:38, Ihar Hrachyshka wrote: > Kevin Benton wrote: > > Hi, >> >> I know this has come up in the past, but some folks in the infra channel >> brought up the topic of changing the default security groups to allow all >> traffic. >> >>

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 11 February 2016 at 20:17, John Belamaric wrote: > > On Feb 11, 2016, at 12:04 PM, Armando M. wrote: > > > > On 11 February 2016 at 07:01, John Belamaric > wrote: > >> >> >> >> It is only internal implementation changes.

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

The difference lies in the process in my opinion. If the switch is added into the migration path then we will tell operators when to switch. I was suggesting doing it manual because we just don't know if every operator is happy about doing the switch when upgrading to Newton, but perhaps it is

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 5 February 2016 at 17:58, Neil Jerram <neil.jer...@metaswitch.com> wrote: > On 05/02/16 16:31, Pavel Bondar wrote: > > On 05.02.2016 12:28, Salvatore Orlando wrote: > >> > >> > >> On 5 February 2016 at 04:12, Armando M. <arma...@gma

Re: [openstack-dev] [neutron] [ipam] Migration to pluggable IPAM

On 5 February 2016 at 04:12, Armando M. wrote: > > > On 4 February 2016 at 08:22, John Belamaric > wrote: > >> >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin wrote: >> > >> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar

Re: [openstack-dev] [neutron][networking-calico] To be or not to be an ML2 mechanism driver?

I agree with Armando that at the end of the day user requirements should drive these decisions. I think you did a good job in listing what are the pro and the cons of choosing standalone plugin rather than a ML2 driver. The most important point you made, in my opinion, concerns the ability of

Re: [openstack-dev] [neutron][api] GET call with huge argument list

flow for allowing this. > > > > On Wed, Jan 20, 2016 at 2:27 PM, Salvatore Orlando <salv.orla...@gmail.com > > wrote: > >> I tend to agree with Doug and Ryan's stance. If you need to pass 1000s of >> network-id on a single request you're probably not doing

Re: [openstack-dev] [neutron][api] GET call with huge argument list

I tend to agree with Doug and Ryan's stance. If you need to pass 1000s of network-id on a single request you're probably not doing things right on the client side. As Ryan suggested you can try and split the request in multiple requests with acceptable URI lenght and send them in parallel; this

Re: [openstack-dev] [Horizon] [Cinder] [Nova] [Neutron] Gathering quota usage data in Horizon

The point raised by Matt for Nova applies to Neutron as well. Neutron does not have strict deadlines for blueprint approval; however even if in theory it would still be possible to achieve this for Mitaka, it is rather unlikely since the number of blueprints already in the pipeline is way more

Re: [openstack-dev] [client][all][neutron] client option removal policy

The Neutron API dropped XML support quite some time ago. Therefore specifying --request-format xml already produces an error. Even if this parameter is already vestigial and should be abruptly removed. We don't know whether anyone is using it. For instance one could have a set of scripts that

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

I only have some historical, anecdotal, and rapidly waning memory of previous releases. Nevertheless my feeling is that the process has been a success so far. In past times it would not have been a surprise if a bug fell under the radar until that well known brownish matter hit the proverbial fan.

Re: [openstack-dev] [nova][api]

It makes sense to have a single point were response pagination is made in API processing, rather than scattering pagination across Nova REST controllers; unfortunately if I am not really able to comment how feasible that would be in Nova's WSGI framework. However, I'd just like to add that there

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

the requirements of any stakeholder. If these information are needed for making scheduling decisions based on network requirements, then it makes sense to expose this information also at the API layer (I assume there also plans for making the scheduler *seriously* network aware). However, this information sho

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

Arbitrary blobs are a powerful tools to circumvent limitations of an API, as well as other constraints which might be imposed for versioning or portability purposes. The parameters that should end up in such blob are typically specific for the target IPAM driver (to an extent they might even

Re: [openstack-dev] [api][nova] Handling lots of GET query string parameters?

Regarding Jay's proposal, this would be tantamount to defining an API action for retrieving instances, something currently being discussed here [1]. The only comment I have is that I am not entirely surely whether using the POST verb for operations which do no alter at all the server

Re: [openstack-dev] [api][nova] Handling lots of GET query string parameters?

Inline, Salvatore On 4 November 2015 at 15:11, Cory Benfield <c...@lukasa.co.uk> wrote: > > > On 4 Nov 2015, at 13:13, Salvatore Orlando <salv.orla...@gmail.com> > wrote: > > > > Regarding Jay's proposal, this would be tantamount to defining an API > act

Re: [openstack-dev] [neutron][stable] should we open gate for per sub-project stable-maint teams?

This plan makes a lot of sense to me. With the staggering number of sub-projects in neutron it is impossible for the stable team to cope with the load. Delegation and decentralisation is a must and both sub-project maintainers and the stable team will benefit from it. Also, since patches can

Re: [openstack-dev] [neutron][stable] proactive backporting

This sounds like a pretty decent idea to me. Considering Neutron's patch merge rate this activity should hopefully not take a consistent chunk of your Friday. It might also make sense to ask contributors to resume the habit of tagging bugs with 'backport-potential' even if not in the RC period. I

Re: [openstack-dev] [neutron]What happened when the 3-rd controller restarted?

Hi Germy, It seems that you're looking at solutions for ensuring consistency between the "desired" configuration (Neutron), and the actual one (whatever is in your backend) at startup. This has been discussed several times in the past - not just for synchronization at startup, but also for

Re: [openstack-dev] [neutron]What happened when the 3-rd controller restarted?

Inline, Salvatore On 12 October 2015 at 09:29, Germy Lure wrote: > Hi Kevin, > > *Thank you for your response. Periodic data checking is a popular and > effective method to sync info. But there is no such a feature in Neutron. > Right? Will the community merge it soon? And

Re: [openstack-dev] [neutron]Anyone tried to mix-use openstack components or projects?

Inline, Salvatore On 12 October 2015 at 10:23, Germy Lure wrote: > Thank you, Kevin. > So the community just divided the whole openstack into separate > sub-projects(Nova,Neutron and etc.) but it's not taken into account that if > those modules can work together with

Re: [openstack-dev] [pecan] [mistral] Pecan python3 compatibility

Or, since many OpenStack projects now use Pecan, we could fix this ourselves as a thank you note to Pecan developers! Salvatore On 1 October 2015 at 21:08, Ryan Petrello wrote: > Yep, this definitely looks like a Python3-specific bug. If you'll open a > ticket,

Re: [openstack-dev] [neutron][networking-ovn][vtep] Proposal: support for vtep-gateway in ovn

Random comments inline. Salvatore On 24 September 2015 at 14:05, Russell Bryant wrote: > On 09/24/2015 01:17 AM, Amitabha Biswas wrote: > > Hi everyone, > > > > I want to open up the discussion regarding how to support OVN > > VTEP gateway deployment and its lifecycle in

Re: [openstack-dev] [neutron] Neutron debugging tool

. Salvatore On 22 September 2015 at 04:25, Ganesh Narayanan (ganeshna) < ganes...@cisco.com> wrote: > Another project for diagnosing OVS in Neutron: > > https://github.com/CiscoSystems/don > > Thanks, > Ganesh > > From: Salvatore Orlando <salv.orla...@gmail.com> >

Re: [openstack-dev] [neutron] Neutron debugging tool

It sounds like indeed that easyOVS covers what you're aiming too. However, from what I gather there is still plenty to do in easy OVS, so perhaps rather than starting a new toolset from scratch you might build on the existing one. Personally I'd welcome its adoption into the Neutron stadium as

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 28 August 2015 at 16:57, Sean Dague s...@dague.net wrote: On 08/28/2015 11:20 AM, Assaf Muller wrote: To recap, we had three issues impacting the gate queue: 1) The neutron functional job has had a high failure rate for a while now. Since it's impacting the gate, I've removed it

Re: [openstack-dev] [neutron] Pecan and Liberty-3

./neutron/newapi/hooks/ownership_validation.py:34:# TODO(salvatore-orlando): consider whether this check can be folded ./neutron/newapi/app.py:40:#TODO(kevinbenton): error templates ./neutron/newapi/controllers/root.py:150:# TODO(kevinbenton): allow fields after policy enforced

Re: [openstack-dev] [Neutron] Etherpad from the Ops Meetup

The etherpad contains some complaints around DVR implementation that might deserve furhter exploration. However, as pointed out by Jay, the comments made leave very little room for actionable items. It would be great if the author(s) could fill in with more details. Salvatore On 19 August 2015

Re: [openstack-dev] [Neutron] Kuryr - virtual sprint

Hi Gal, even if I've been a lurker so far, I'm interested in attending for learning and contributing to it with my massive bug-injecting skills! You said virtual sprint and somewhere in september - I think somewhere refers to dates? Anyway I am pretty much open to any date from September 7th

Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

my 0.02€ on the matter inline. Regards, Salvatore On 18 August 2015 at 23:45, Mathieu Rohon mathieu.ro...@gmail.com wrote: hi brandon, thanks for your answer. my answers inline, On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan brandon.lo...@rackspace.com wrote: ​So let me make sure I

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support

On 13 August 2015 at 09:50, John Garbutt j...@johngarbutt.com wrote: On Wednesday, August 12, 2015, Thierry Carrez thie...@openstack.org wrote: Gary Kotton wrote: On 8/12/15, 12:12 AM, Mike Perez thin...@gmail.com wrote: On 15:39 Aug 11, Gary Kotton wrote: On 8/11/15, 6:09 PM, Jay

Re: [openstack-dev] [neutron] Race conditions in fwaas that impact the gate

I have been hit by these failures as well. I think you did well by bumping out that revert from the queue; I think it simply cures the sympton possibly affecting correct operations of the firewall service. If we are looking at removing the sympton on the API job, than I'd skip the failing tests

Re: [openstack-dev] [neutron] Merge back of QoS and pecan branches

Kyle, I can speak very little about the QoS branch, but from what I gather it is mature enough to be merged back. However, I believe the Pecan work is still incomplete as we need a solution to run the RPC over AMQP server independently. Once we have that we can start merging back what we have.

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

More comments inline. Salvatore On 31 July 2015 at 01:47, Kevin Benton blak...@gmail.com wrote: The issue is that the Neutron credentials might not have privileges to resolve the name to a UUID. I suppose we could just fail in that case. As quota-update is usually restricted to admin users

Re: [openstack-dev] [nova, cinder, neutron] quota-update tenant-name bug

To the best of my knowledge Neutron is unable to enforce tenant quotas using the tenant name; this should be undocumented. What Kevin suggests also goes in this direction, even if we have to be careful as we're making assumptions on how tenant ids are represented (if the deployment is not using

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

For my low-orbit perspective (I would have lied if I said 10,000 or 30,000 ft!) Kuryr's ultimate goal is to provide: 1) a container-oriented set of neutron plugins and drivers (you know the ML2 driver, a l3 svc plugin, a lbaas driver, etc. etc.) 2) possibly (I'm not sure if that's the case)

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

A few comments inline. Generally speaking the only thing I'd like to remark is that this use case makes sense independently of whether you are using overlay, or any other SDN solution (whatever SDN means to you). Also, please note that this thread is now split in two - there's a new branch

Re: [openstack-dev] [neutron] Should we document the using of device:owner of the PORT ?

It is not possible to constrain this attribute to an enum, because there is no fixed list of device owners. Nevertheless it's good to document know device owners. Likewise the API layer should have checks in place to ensure accidental updates to this attributes do not impact control plane

Re: [openstack-dev] [Openstack][nova] proxy quota/limits info from neutron

Some comments inline. Salvatore On 15 July 2015 at 10:24, Alex Xu sou...@gmail.com wrote: 2015-07-15 5:14 GMT+08:00 Matt Riedemann mrie...@linux.vnet.ibm.com: On 7/14/2015 3:43 PM, Cale Rath wrote: Hi, I created a patch to fail on the proxy call to Neutron for used limits, found

Re: [openstack-dev] [neutron][db] online-schema-migrations patch landed

Do you reckon that the process that led to creating a migration like [1] should also be documented in devref? That might be helplful for developers, unless that process is already documented elsewhere. Salvatore [1] https://review.openstack.org/#/c/202013/1 On 15 July 2015 at 15:54, Mike Bayer

Re: [openstack-dev] [neutron] Should we document the using of device:owner of the PORT ?

Yes please. This would be a good starting point. I also think that the ability of editing it, as well as the value it could be set to, should be constrained. As you have surely noticed, there are several code path which rely on an appropriate value being set in this attribute. This means a user

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

Some pedant comments inline. Salvatore On 13 July 2015 at 23:29, Russell Bryant rbry...@redhat.com wrote: On 07/13/2015 05:08 PM, Kevin Benton wrote: Thanks for the info. So the equivalent in neutron would be if we just ensure backward compatible AMQP APIs, right? There's a few parts:

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

On 7 July 2015 at 14:00, Paul Michali p...@michali.net wrote: Thanks Salvatore for the responses. See @PCM in-line... On Tue, Jul 7, 2015 at 6:14 AM Salvatore Orlando sorla...@nicira.com wrote: Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

Some comments inline. Salvatore On 6 July 2015 at 20:00, Paul Michali p...@michali.net wrote: Hi, I have some urgent requests about migration that I'm hoping to get some info on. I'm working on a bug where I need to add two (related) fields to a table for VPNaaS. Here's the objectives

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

On 25 June 2015 at 16:08, John Davidge (jodavidg) jodav...@cisco.com wrote: Hi all, Recent neutron third party CI issues have got me thinking again about a topic which we discussed in Vancouver: Should any Third Party CI have voting rights for neutron patches in gerrit? Why should

[openstack-dev] [Neutron] new RFE on quota enforcement

Hi, since the quota enforcement patches for the 'better-quotas' blueprint did not merge by liberty-1, and I forgot to resubmit the already-approved kilo spec [1], I have submitted a RFE to comply with the process agreed for Liberty [2]. As the policy [3] does not explicitly state that the

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

? Edgar From: Salvatore Orlando Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Thursday, June 25, 2015 at 7:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting On 25

Re: [openstack-dev] [Neutron] Modular L2 Agent

I see Kyle's point that this is not something in-scope for liberty at this stage. However, on the other hand I would rather avoid having multiple agents on the compute node performing various tasks in an un-coordinated way (well, actually relying on neutron-server coordination). QoS is an

Re: [openstack-dev] M Naming Poll ended - results still need to clear legal

Anyway, if you want to print t-shirts once legal is cleared, here's a vintage football idea [1]. Little and pointless trivia fact: Como calcio was sponsored for a few years in the 80s by Mita copiers - now known as Kyocera. Salvatore [1]

[openstack-dev] [neutron][api] Neutron micro-versioning update

As you are probably aware an api-wg guideline for microversioning is under review [1] Needless to say, neutron developers interested in this work should have a look at [1] - if nothing else because we need to ensure we are aligned - and influence the guideline were appropriate. Experimental APIs

Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header

On 16 June 2015 at 14:38, Lucas Alvares Gomes lucasago...@gmail.com wrote: Hi So if our min_version is 2.1 and the max_version is 2.50. That means alternative implementations need implement all the 50 versions api...that sounds pain... Yes, it's pain, but it's no different than

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

Some more comments inline. Salvatore On 16 June 2015 at 19:00, Carl Baldwin c...@ecbaldwin.net wrote: 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

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

On 16 June 2015 at 18:49, Carl Baldwin c...@ecbaldwin.net wrote: 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

Re: [openstack-dev] [Openstack][Neutron][OVN] OVN-Neutron - TODO List

Gal, thanks for this summery. Some additional info inline. Salvatore On 12 June 2015 at 19:38, Gal Sagie gal.sa...@gmail.com wrote: Hello All, I wanted to share some of our next working items and hopefully get more people on board with the project. I personally would mentor any new comer

Re: [openstack-dev] [neutron] Microversioning work questions and kick-start

On 12 June 2015 at 16:58, Henry Gessau ges...@cisco.com wrote: On Thu, Jun 11, 2015, Salvatore Orlando sorla...@nicira.com wrote: Finally, I received queries from several community members that would be keen on helping supporting this microversioning effort. I wonder if the PTL

Re: [openstack-dev] [neutron] Microversioning work questions and kick-start

On 12 June 2015 at 12:22, Sean Dague s...@dague.net wrote: On 06/11/2015 06:03 PM, Salvatore Orlando wrote: As most of you already know, work is beginning to move forward on the micro-versioned Neutron API, for which a specification is available at [1] From a practical perspective

Re: [openstack-dev] [keystone] [nova] [oslo] [neutron][cross-project] Split Policy rules into two parts.

I am not able to say whether this works for Nova. Surely works for Neutron - from a functional perspective at least. I still don't know however whether this choice is the best way to proceed, and perhaps you can help me understand better. Role checks are always expressed through policy.json and

[openstack-dev] [Neutron] Quota enforcement

Aloha! As you know I pushed spec [1] during the Kilo lifecycle, but given the lazy procrastinator that I am, I did not manage to complete in time for the release. This actually gave me a chance to realise that the spec that I pushed and had approved did not make a lot of sense. Even worse, there

[openstack-dev] [neutron] Microversioning work questions and kick-start

As most of you already know, work is beginning to move forward on the micro-versioned Neutron API, for which a specification is available at [1] From a practical perspective there is one non-negligible preliminary issue that needs attention. then Neutron API URI prefix includes the full version

Re: [openstack-dev] [Neutron] Issue with pymysql

It is however interesting that both lock wait timeouts and missing savepoint errors occur in operations pertaining the same table - securitygroups in this case. I wonder if the switch to pymysl has not actually uncovered some other bug in Neutron. I have no opposition to a revert, but since this

Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

As a further data point, Neutron has been trying to introduce microversioning for a while, without success so far. Given the sheer amount of backends the management layer integrates with, and the constant need for the various subteams to experiment with the API, the proposal [1] has probably some

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

Jay is pretty much right. In Neutron's case it is even more trivial. Somebody copied the extension manager from Nova, and a sort of extension interface with this namespace. And every neutron developer, including me felt compelled to filling that up with something that resembled an XML namespace

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

Kevin, On 8 June 2015 at 23:52, 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

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

, 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 proposed patch addresses the issue blindly - that is to say before declaring an agent dead let's wait

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

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 addresses the issue blindly - that is to say before declaring an agent dead let's wait for some more time because it could be stuck doing stuff. In that

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 2 June 2015 at 23:59, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/2/15, 16:24, Boris Pavlovic bo...@pavlovic.me wrote: Hi stackers, Issue --- Projects are becoming bigger and bigger overtime. More and more people would like to contribute code and usually core

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 3 June 2015 at 07:12, John Griffith john.griffi...@gmail.com wrote: On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand iwien...@redhat.com wrote: On 06/03/2015 07:24 AM, Boris Pavlovic wrote: Really it's hard to find cores that understand whole project, but it's quite simple to find people

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

I'm not sure if you can test this behaviour on your own because it requires the VMware plugin and the eventlet handling of backend response. But the issue was manifesting and had to be fixed with this mega-hack [1]. The issue was not about several workers executing the same code - the loopingcall

Re: [openstack-dev] Interconnecting projects

I suspect a BaaS (Bridge-as-a-service) proposal is lurking in this thread. While the idea of yet-another-aas is probably not desirable at this time, it might be worth trying and understand - from an exclusively logical perspective (ie: the API consumer point of view) - what would be the

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

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) should probably be the first thing to do - if nothing else because the original bug has not nearly the same level of

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

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 neutron contributors from this burden. It has been a pleasure for me serving the Neutron community (or Quantum as it

Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

On 15 May 2015 at 00:19, Debojyoti Dutta ddu...@gmail.com wrote: Hi! It is a great pleasure to announce the development of a new project called Cognitive. Cognitive provides Machine Learning [1] as a Service that enables operators to offer next generation data science based services on top

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

Just like the Neutron plugin manager, also ML2 driver manager ensure drivers are loaded only once regardless of the number of workers. What Kevin did proves that drivers are correctly loaded before forking (I reckon). However, forking is something to be careful about especially when using

Re: [openstack-dev] [Neutron][QoS] Neutron QoS (Quality Of Service) update

On 7 May 2015 at 10:32, Miguel Ángel Ajo majop...@redhat.com wrote: Gal, thank you very much for the update to the list, I believe it’s very helpful, I’ll add some inline notes. On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote: Hello All, I think that the Neutron QoS effort is

Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in

than happy to slap your hands too. Thanks, Kevin -- *From:* Salvatore Orlando [sorla...@nicira.com] *Sent:* Tuesday, May 05, 2015 3:13 PM *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [neutron][api] Extensions out, Micro-versions

Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?

I think Paul is correctly scoping this discussion in terms of APIs and management layer. For instance, it is true that dynamic routing support, and BGP support might be a prerequisite for BGP VPNs, but it should be possible to have at least an idea of how user and admin APIs for this VPN use case

Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in

Thanks Bob. Two answers/comments below. On 6 May 2015 at 14:59, Bob Melander (bmelande) bmela...@cisco.com wrote: Hi Salvatore, Two questions/remarks below. From: Salvatore Orlando sorla...@nicira.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack

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

Patch #153236 is introducing pluggable IPAM in the db base plugin class, and default to it at the same time, I believe. If the consensus is to default to IPAM driver then in order to satisfy grenade requirements those migrations scripts should be run. There should actually be a single script to

[openstack-dev] [neutron][api] Extensions out, Micro-versions in

There have now been a few iterations on the specification for Neutron micro-versioning [1]. It seems that no-one in the community opposes introducing versioning. In particular API micro-versioning as implemented by Nova and Ironic seems a decent way to evolve the API incrementally. What the

Re: [openstack-dev] [neutron][lbaas][tempest] Data-driven testing (DDT) samples

Among the OpenStack project of which I have some knowledge, none of them uses any DDT library. If you think there might be a library from which lbaas, neutron, or any other openstack project might take advantage, we should consider it. Salvatore On 14 April 2015 at 20:33, Madhusudhan Kandadai

Re: [openstack-dev] [Neutron] _get_subnet() in OpenContrail tests results in port deletion

I think the first workaround is the solution we're looking for as it better reflects the fact that opencontrail is a db-less plugin. I hope it will be the easier too, but you can never be too sure with neutron unit tests. Salvatore On 4 May 2015 at 12:56, Pavel Bondar pbon...@infoblox.com wrote:

Re: [openstack-dev] [QA] Question about tempest API tests that establish SSH connection to instances

At a first glance it seems run_ssh is disabled in gate tests [1]. I could not find any nova job where it is enabled. These tests are therefore skipped. For what is worth they might be broken now. Sharing a traceback or filing a bug might help. Salvatore [1]

Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation

I believe German is referring to the case where a user performs an operation on behalf of some other project to whom it bears no relationship. In this case the user performing the operation authenticates with keystone with a project_id which is not the one for which the operation is being

Re: [openstack-dev] Please stop reviewing code while asking questions

On 24 April 2015 at 14:11, Russell Bryant rbry...@redhat.com wrote: On 04/24/2015 07:21 AM, Amrith Kumar wrote: We had a hypothesis about why +0 was rarely used (never conclusively proved). Our hypothesis was that since Stackalytics didn't count +0's it led to an increased propensity to -1

Re: [openstack-dev] [Neutron] [Nova] [Cinder] [tc] Should Openstack project maintained by core team keep only API/DB in the future?

On 24 April 2015 at 15:13, Kyle Mestery mest...@mestery.com wrote: On Fri, Apr 24, 2015 at 4:06 AM, loy wolfe loywo...@gmail.com wrote: It's already away from the original thread, so I start this new one, also with some extra tag because I think it touch some corss-project area. Original

Re: [openstack-dev] Please stop reviewing code while asking questions

On 24 April 2015 at 16:50, Chris Friesen chris.frie...@windriver.com wrote: On 04/24/2015 07:26 AM, Salvatore Orlando wrote: If you think it might be beneficial to adjust tooling to that these contributions get counted this is fine by me. I just wanted to point out that I do not consider

Re: [openstack-dev] [Neutron] A big tent home for Neutron backend code

Doug, HMS Octavia was a British mine sweeper that served during WW2 figthing German warships and u-boats somewhere in the sea. I therefore believe if you have anything against this name you are secretly a nazi. Does that work for the Godwin's law call? Salvatore On 23 April 2015 at 22:09, Doug

Re: [openstack-dev] [neutron][QoS] service-plugin or not discussion

On 23 April 2015 at 01:30, Armando M. arma...@gmail.com wrote: On 22 April 2015 at 06:02, Miguel Angel Ajo Pelayo mangel...@redhat.com wrote: Hi everybody, In the latest QoS meeting, one of the topics was a discussion about how to implement QoS [1] either as in core, or as a service

  1   2   3   4   5   >