On 10/3/18 10:16 AM, Eric Fried wrote:
> We would like networking-powervm to be included, and have proposed ,
> but are wondering why we weren't picked up in . Your email  says
> "If your project isn't in ,
> but you think it should be; it maybe missing a recent neutron-lib
Just a friendly reminder that networking projects now need to opt-in for
neutron-lib consumption patches .
Starting next week (September 8) I'd like to start basing consumption
patches on those projects that have opted-in. If there are exceptions
please let me know so we can track them
Please read on if your project uses neutron-lib.
During the PTG  we decided that projects wanting to receive
neutron-lib consumption patches  (for free) need to explicitly opt-in
by adding the string "neutron-lib-current" to a comment in their
Based on the list of
Below is a summary of last weeks bug activity.
I've tried to organize the summary to highlight those bugs that still
Needs additional technical triage:
- [dvr][ha][dataplane down] router_gateway port binding host goes wrong
after the 'master' host down/up
On 8/30/18 5:49 AM, Michel Peterson wrote:
> There are pre releases available in PyPI . You can use those from
> your requirements like we did in n-odl .
> That might be an acceptable solution.
>  https://pypi.org/project/neutron/#history
On 8/29/18 12:06 AM, Takashi Yamamoto wrote:
> is there any preferred solution for this?
> i guess the simplest solution is to make an intermediate release of neutron
> and publish it on pypi. i wonder if it's acceptable or not.
What we've been doing to date is adding tox target(s) to the
On 8/22/18 2:10 AM, Slawomir Kaplonski wrote:> I will run it only for
> * neutron-lib
> If You have any concerns about running this script, please raise Your hand
> now :)
Thanks for this.
Personally I don't see a need to cleanup old reviews for neutron-lib;
it's a pretty
On 7/23/18 9:46 PM, Sangho Shin wrote:
> It applies also to the networking- projects. Right?
Yes. It should apply to any project that's using/depending-on
Note that I "think" the neutron-lib version required by neutron will
trump the project's required version anyway,
If you're a networking project that uses neutron/neutron-lib, please
We recently created the stable/rocky branch for neutron-lib based on
neutron-lib 1.18.0 and neutron is now using 1.18.0 as well . If
you're a networking project that depends on (uses) neutron/master then
On 7/12/18 4:10 AM, Takashi Yamamoto wrote:
> On Thu, Jul 12, 2018 at 6:13 PM, Tony Breeds wrote:
>> No we need more contributors to stable and extended maintenance periods.
>> This is not a new problem, and one we're trying to correct.
> actually it is a new problem. at least worse than
We need to have a final release of neutron-lib for Rocky by July 19th,
so we should probably propose a neutron-lib 1.18.0 release early next week.
To help focus our review efforts between now and then I'd like to ask
folks to tag any neutron-lib patches they deem necessary for Rocky with
It appears a number of networking related projects aren't setup properly
for Zuul v3 gate jobs, as well as for local testing when it comes to
pulling in dependencies from source.
Since this may not be a common concept, ask yourself: "should my
project's master branch source be running with and
Thanks for that.
I'm a bit concerned about how to proceed with dependencies in the
meantime, it's not realistic to hold all such patches until S.
Perhaps we can continue this discussion in ?
On 6/19/18 7:38 PM, linghucongsong wrote:
Is there anyone who can speak to the status of tricircle's adoption of
As per  it doesn't seem like the project is setup properly for Zuul
v3. Thus, it's difficult/impossible to land patches like  that
require neutron/master + a depends on patch.
Assuming tricircle is still being
The 1.15.0 release of neutron-lib contains a syntax error in a LOG debug
call that was fixed with .
We are working to release the fix with 1.16.0 .
If you are running into this error , it maybe necessary to exclude
neutron-lib 1.15.0 and pickup 1.16.0 once we get it released.
Last week we had a total of 14 bugs come in ; 2 of which are RFEs.
Only 1 defect is high priority  and is already in progress.
There are still a few bugs under discussion/investigation:
- 1774257 "neutron-openvswitch-agent RuntimeError: Switch connection
timeout" could use some input from
Back in 2016 we tagged neutron-lib as a "tc-approved-release" and as a
result neutron-lib commits/reviews showed up on stackalytics under
TC-approved Project Types.
However as of recent that's seemed to have changed and neutron-lib
commits/reviews are no longer showing up  even though it
On 4/25/18 10:13 PM, Shu M. wrote:
> Hi folks,
>> unwinding things
>> There are a few different options, but it's important to keep in mind
>> that we ultimately want all of the following:
>> * The code works
>> * Tests can run properly in CI
>> * "Depends-On" works in
On 3/14/18 6:59 PM, Tony Breeds wrote:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
>> (1) it makes difficult to run tests in local environment
>> We have only released version of neutron/horizon on PyPI. It means
>> PyPI version (i.e. queens) is installed when we run tox in
> On 3/19/18 7:15 AM, Andreas Jaeger wrote:
> pip install -U breaks it, please double check that this does the right
I'm not yet convinced the pip -U is the only factor here.
When I run with 554222 in my local env I still get a back-leveled
Could I please ask the folks from networking-vsphere to keep an eye on
their review queue for incoming neutron-lib related patches?
Today we have at least 3 in the networking-vsphere queue that haven't
gotten a core review for over a month.
In order to keep the neutron-lib effort moving and
If your networking project is using neutron/neutron-lib, please read on.
If you're using neutron or neutron-lib code (for example extensions),
please ensure you import/use the respective attributes of those modules
rather than duplicate such values (str constants and such).
Just a quick update on the neutron-lib workstream.
Although there hasn't been many "neutron-lib impact" emails lately, the
effort is still active. The reason for decreased email volume is that
rather than just updating stadium consumers during consumption , all
On 10/27/17 6:35 PM, James E. Blair wrote:
> We're rolling out a new version of Zuul that corrects the issues, and
> the migration doc has been updated. The main things to know are:
> * If your project has stable branches, we recommend backporting the Zuul
> config along with all the
On 10/10/17 3:40 AM, Andreas Jaeger wrote:
> The common jobs have been fixed whenever bugs got reported. So, if you
> have current failures, tell us.
How can projects validate zuul v3 jobs in our current state to prepare
for the transition?
Some projects don't even have a verified zuul v3 patch
On 10/5/17 5:43 AM, Goutham Pratapa wrote:
> failed with the error *TIMED_OUT in 2h 32m 23s *which resulted in -1 how
> can I retrigger it is
 Based on  I though Zuul v3 jobs were non-voting at this point in time and
so a v3 job failure wouldn't -1V stalling a patch.
However, I'm also
While I realize my timing may be a little bad here with all the other
things we have going on, I wanted to follow up on our plans for the SDK
and OSC as time is already flying by for Queens.
As we discussed before , there are some gaps in the OSC/SDK model
that keep us from getting parity with
On 10/3/17 1:37 PM, Monty Taylor wrote:
> The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as your
> gate keeper once again.
Since the rollback, one of the neutron-lib (v2) jobs has been
consistently failing  with:
c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or
On 10/3/17 5:17 AM, Sean Dague wrote:
> Do we have a defined point on the calendar for getting the false
> negatives back below the noise threshold otherwise a rollback is
> implemented so that some of these issues can be addressed in parallel
> without holding up community development?
If your project uses neutron callbacks, please read on.
As we discussed during the PTG  in the "Cross project related topics"
section, we'll treat the adoption of the new payload style objects as we
have been with other lib impact changes.
That said, the first (and easiest) set of patches
On 9/5/17 11:03 AM, Doug Hellmann wrote:
> Is eventlet being initialized (or partially initialized) when a module
> from the application is imported for the auto-generated API
More than likely :)
But even if they are, what's the fix/workaround?
We've (neutron) run into a few cases where our doc links become
outdated/invalid and are dead. These dead links are not detected in the
doc build today, but is something we might be interested in enabling.
I'm no sphinx expert, but best I can tell that's done with the
"linkcheck" builder .
On 8/8/17 10:29 AM, Akihiro Motoki wrote:
> My reply applies to 'resource' extension but does not apply to
> 'attribute extension'
My apologies for using confusing terminology; as you pointed out we
don't currently have a good solution for attribute extensions with OSC
and I've tried to outline
On 8/7/17 10:39 PM, Clint Byrum wrote:
> If the thing you're doing doesn't fit in the mainline API, then what
> you're doing is making a new API. Extensions just bypass the important
> part where that API gets designed and thought through.
Irrespective of opinions as to if API extensions are good
On 8/4/17 1:26 PM, Boris Pavlovic wrote:
> That's not going to work for dozens of OpenStack projects. It's just
> won't scale. Every project should maintain plugin for their project. And
> it should be enough to say "pip install python-client" that
> extend the Core OpenStack python client and
I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.
For details, go directly to .
For a summary read on...
For OpenStack APIs that support extensions (ex ),
If your project uses the constants from neutron.plugins.common.constants
please read on.
Many of the common plugin constants from neutron are now in neutron-lib
 and we're ready to consume them neutron .
- If your project uses any rehomed constants , please update
If your project uses neutron.api.v2.attributes please read on.
A bulk of neutron.api.v2.attributes has been rehomed into neutron-lib
 and we've begun consuming these changes in neutron and stadium
Today we are working to consume:
- The core resource/collection name constants 
On 5/12/17 12:31 PM, Armando M. wrote:
> Please, do provide feedback in case I omitted some other key takeaway.
>  https://etherpad.openstack.org/p/pike-neutron-diagnostics
Glad you all got a chance
If your project uses neutron.extensions.extra_dhcp_opt please read on.
The extra_dhcp_opt is now available as a neutron-lib API definition 
and consumption has begun .
- If you're a stadium project; you should be covered in .
- If not, please update your project's
If your project uses the MechanismDriver class or associated constants
in neutron.plugins.ml2.driver_api, please read on. If not, it's probably
safe to delete this message.
For details on what's been rehomed, please see .
- If you're a stadium project, you should be already
On 5/3/17 8:55 AM, Eric Fried wrote:
> Can you please point to the change(s) that move the constants? Or
> provide some other way to figure out which are affected?
This Hound search  provides an overall picture and can be honed to
specific projects as needed. The search will identify
If your project uses neutron.plugins.common.constants please read on. If
not, it's probably safe to discard this message.
A number of the constants from neutron.plugins.common.constants have
moved into neutron-lib:
- The service type constants are in neutron_lib.plugins.constants
- Many of the
The neutron portsecurity extension has been rehomed into neutron-lib and
we are now in the process of consuming it.
- If your project consumes neutron.extensions.portsecurity  and
there's not an existing patch for your project in , please move your
imports over to
If you work on a neutron sub-project that uses neutron.callbacks, please
read on. If not, it's probably safe to discard this message.
We've been talking about it for awhile, but it's finally coming to
fruition; we're transitioning over to neutron-lib's callbacks.
To ease sync issues across
Head's up: the ServicePluginBase and PluginInterface classes are being
removed from neutron.
- ServicePluginBase is available in neutron-lib.
- PluginInterface is likely going to remain private in neutron-lib;
pretty much everyone is using ServicePluginBase anyway.
A patch is proposed to neutron
If your project is or plans to use neutron-lib moving forward, please
At the PTG we discussed how to roll-out new hacking checks in
neutron-lib. In summary we decided to move forward using a single set of
hacking checks, as proposed by  (see 'doc/source/usage.rst' in that
Today, most, if not all plugins forbid updating network provider
extended attributes. Our docs  even say so:
"Most Networking plug-ins and drivers do not support updating any
provider related attributes."
To formalize this we were discussing the possibility of forbidding
updates (PUT) at the
On 2/17/17 2:18 PM, Kevin Benton wrote:
> Hi all,
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron portbindings API
A consumption patch to use the rehomed code has been submitted to
neutron  and once merged will impact consumers who use portbindings
A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron providernet API
A consumption patch to use the rehomed code has been submitted to
neutron  and once merged will impact consumers who use providernet
I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc  if you haven't
In particular the 'Phase 4: Consume' section  provides some tips on
how we see this workflow playing out.
> Source code is here: https://github.com/abashmak/chrome-irc-filter
> Comments, suggestions are welcome.
I've always wanted a tool that could alert me of "missed mentions" when
I'm offline IRC rather than having to manually parse the IRC logs for
those times I'm offline.
Our small neutron-lib crowd is busy today, so we won't hold the meeting.
For neutron-lib planning/tasks/etc., please see .
If time permits, please take a pass through the neutron-lib reviews .
I probably missed this, but is there a way for out-of-tree plugins that
have extensions to add them to the api-ref?
For example, suppose we wanted to api-ref the extensions in .
On 8/18/16 6:16 AM, Akihiro Motoki wrote:
> Hi Neutron team,
> As you may
Do any projects have an interest in generating python API signature
reports capable of showing "what's new/changed/removed" in a release
(ex: )? If so, read on.
We recently developed a tool in neutron-lib  capable of inspecting +
generating python API signature and diff reports.
>From a vmware-nsx perspective, we have added some temp gate jobs that
run pep8, py27 and py35 on Xenial (check-xenial-epep8,
check-xenial-epy27 and check-xenial-epy35 respectively). Everything (on
Xenial) is passing as indicated in recent job results .
That said, please feel free to create
On 6/2/16 4:31 AM, Tony Breeds wrote:
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed.
openstack/vmware-nsx kilo patches have been abandoned in preparation for
Assaf, thanks for driving this session.
As a newbie to the design sessions, I think presenting a brief "context"
up-front is helpful. IMO the key word here is "brief" (5 min or less for
example) and furthermore should not open the floor for digression given
the short time-frame we have per
On 4/21/16 1:38 PM, Joshua Harlow wrote:
> This might be harder in retrying, but I think I can help u make
> something that will work, since retrying has a way to provide a custom
> delay function.
Thanks for that. My question was if this might be useful as a new
backoff in retrying (vs a
I haven't spent much time on this, so the answers below are a first
approximation based on a quick visual inspection (e.g. subject to change
when I get a chance to hack on some code).
On 4/21/16 12:10 PM, Salvatore Orlando wrote:
> Can you share more details on the "few things we need" that
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 (already in global requirements).
It lacks a few things we need, but those can be
Today there are a number of places in nova, neutron and perhaps
elsewhere that employ backoff + timeout strategies (see  - ).
While we are working towards a unified approach in neutron for RPC ,
it appears such logic could benefit the greater community as a reusable
I recently added a Neutron RFE  that proposes a new extension called
Pluggable Backend Association Mappings (PBAM). This admin-based
extension allows consumers to view Neutron / backend resource mappings,
quickly identify mappings that are out of sync and remediate them.
If this sounds
Regarding bug 1426046 (see below) -- Is this just a matter of making the
classes public or are you thinking the driver interface needs more
thought + solidifying before making something extendable?
Perhaps I can donate a cycle to 2 to help get this in.
On 2/26/15 10:33 AM, Doug Hellmann wrote:
I don't have a public repo -- have been PoCing using a private gitlab to
date... I figured any interest in the driver impl would come out of this
More than happy to provide my PoC code publicly (after a little
clean-up) if there's an interest.
On 2/26/15 12:01 PM, Sandy Walsh
will send a copy of image.delete and image.upload events to
the glance.multicast.host1 and glance.multicast.host2 topics. It will
use 'GLANCE:MASTER' as the publisher ID in the multicasted events.
Your feedback is appreciated.
On Thu, Feb 26, 2015, at 07:24 AM, Boden Russell wrote:
What's the suggested approach for implementing a custom oslo messaging
driver given the existing impl  is private?
e.g. I want to provide my own notification messaging driver which adds
functionality atop the existing driver . This can obviously be done
by extending the
Is it possible to have multiple oslo messaging notification listeners
using different executors on the same target?
For example, I was to create multiple notification listeners  each
using a different executor for the same set of targets (e.g.
When I try this , only
On 1/15/15 12:59 AM, Flavio Percoco wrote:
All that being said, it'd be very nice if you could open a spec on
this topic so we can discuss over the spec review and one of us (or
you) can implement it if we reach consensus.
I'll create a BP + spec; doing a little homework now...
W / R / T
On 1/14/15 1:38 AM, Flavio Percoco wrote:
On 13/01/15 21:24 -0500, Jay Pipes wrote:
On 01/13/2015 04:55 PM, Boden Russell wrote:
Looking for some feedback from the glance dev team on a potential BP…
This is the solution that I would recommend. Frankly, this kind of
Looking for some feedback from the glance dev team on a potential BP…
The use case I’m trying to solve is —
As an admin, I want my glance image bits replicated to multiple store
locations (of the same store type) during a glance create operation.
For example, I have 3 HTTP based backend
On 10/9/14 1:31 PM, Chris Friesen wrote:
On 10/09/2014 08:12 AM, Jeremy Stanley wrote:
On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
the tips of these branches have been tagged havana-eol in
preparation for branch deletion. The list of affected Git
Mail list logo