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
repositories is
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
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 [1] each
using a different executor for the same set of targets (e.g.
glance/notifications).
When I try this [2], only
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
replication should
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
email discussion.
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
What's the suggested approach for implementing a custom oslo messaging
driver given the existing impl [1] is private?
e.g. I want to provide my own notification messaging driver which adds
functionality atop the existing driver [1]. This can obviously be done
by extending the
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 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
the EOL.
Thanks
I recently added a Neutron RFE [1] 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
Today there are a number of places in nova, neutron and perhaps
elsewhere that employ backoff + timeout strategies (see [1] - [4]).
While we are working towards a unified approach in neutron for RPC [5],
it appears such logic could benefit the greater community as a reusable
oslo implementation.
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/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
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/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
>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 [1].
That said, please feel free to create
+1
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
> reservation.
>
>
A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron providernet API
extension [1].
A consumption patch to use the rehomed code has been submitted to
neutron [2] and once merged will impact consumers who use providernet
constants from
A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron portbindings API
extension [1].
A consumption patch to use the rehomed code has been submitted to
neutron [2] and once merged will impact consumers who use portbindings
constants from
Do any projects have an interest in generating python API signature
reports capable of showing "what's new/changed/removed" in a release
(ex: [2])? If so, read on.
We recently developed a tool in neutron-lib [1] capable of inspecting +
generating python API signature and diff reports.
Its
Today, most, if not all plugins forbid updating network provider
extended attributes. Our docs [1] 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
If your project is or plans to use neutron-lib moving forward, please
read on.
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 [1] (see 'doc/source/usage.rst' in that
patch for
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 [1].
Thanks
[1] http://goo.gl/cGVXMN
On 8/18/16 6:16 AM, Akihiro Motoki wrote:
> Hi Neutron team,
>
> As you may
> Source code is here: https://github.com/abashmak/chrome-irc-filter
>
> Comments, suggestions are welcome.
Nice thanks!
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 [1].
If time permits, please take a pass through the neutron-lib reviews [2].
Thanks
[1] https://etherpad.openstack.org/p/nl-planning
[2]
I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc [1] if you haven't
already.
In particular the 'Phase 4: Consume' section [2] provides some tips on
how we see this workflow playing out.
Thanks
[1]
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
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 [1].
For a summary read on...
For OpenStack APIs that support extensions (ex [2]),
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
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
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
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 [1] provides an overall picture and can be honed to
specific projects as needed. The search will identify
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 [1]
and consumption has begun [2].
Recommended action:
- If you're a stadium project; you should be covered in [2].
- If not, please update your project's
On 5/12/17 12:31 PM, Armando M. wrote:
>
> Please, do provide feedback in case I omitted some other key takeaway.
>
> [1] https://etherpad.openstack.org/p/pike-neutron-diagnostics
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/pike/diagnostics.html
>
Glad you all got a chance
If your project uses neutron.api.v2.attributes please read on.
A bulk of neutron.api.v2.attributes has been rehomed into neutron-lib
[1][2] and we've begun consuming these changes in neutron and stadium
projects.
Today we are working to consume:
- The core resource/collection name constants [3]
The neutron portsecurity extension has been rehomed into neutron-lib and
we are now in the process of consuming it.
Suggested actions:
- If your project consumes neutron.extensions.portsecurity [2] and
there's not an existing patch for your project in [1], please move your
imports over to
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 [1].
Suggested actions:
- If you're a stadium project, you should be already
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
[1] and we're ready to consume them neutron [2].
Suggested actions:
- If your project uses any rehomed constants [1], please update
If your project uses neutron callbacks, please read on.
As we discussed during the PTG [1] 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 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 [1] with:
c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or
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
>
[1] Based on [1] 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
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 [1].
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
> documentation?
More than likely :)
But even if they are, what's the fix/workaround?
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?
Along
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 [1], there are some gaps in the OSC/SDK model
that keep us from getting parity with
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
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 [1], all
(stadium/non-stadium) consumers
The 1.15.0 release of neutron-lib contains a syntax error in a LOG debug
call that was fixed with [1].
We are working to release the fix with 1.16.0 [2].
If you are running into this error [3], it maybe necessary to exclude
neutron-lib 1.15.0 and pickup 1.16.0 once we get it released.
Feel free
Is there anyone who can speak to the status of tricircle's adoption of
Zuul v3?
As per [1] it doesn't seem like the project is setup properly for Zuul
v3. Thus, it's difficult/impossible to land patches like [2] that
require neutron/master + a depends on patch.
Assuming tricircle is still being
Last week we had a total of 14 bugs come in [1]; 2 of which are RFEs.
Only 1 defect is high priority [2] 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
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 [1]?
[1] https://bugs.launchpad.net/tricircle/+bug/1776922
On 6/19/18 7:38 PM, linghucongsong wrote:
>
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 [1] 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
If your networking project is using neutron/neutron-lib, please read on.
SUMMARY:
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).
DETAILS:
To
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
On 8/22/18 2:10 AM, Slawomir Kaplonski wrote:> I will run it only for
projects like:
> * 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 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 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
neutron/master today.
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
read on.
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 [1]. If
you're a networking project that depends on (uses) neutron/master then
it's
Howdy,
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
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
> On 3/19/18 7:15 AM, Andreas Jaeger wrote:
>
> pip install -U breaks it, please double check that this does the right
> thing:
>
> https://review.openstack.org/554222
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
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
Just a friendly reminder that networking projects now need to opt-in for
neutron-lib consumption patches [1].
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
On 10/3/18 10:16 AM, Eric Fried wrote:
> We would like networking-powervm to be included, and have proposed [5],
> but are wondering why we weren't picked up in [6]. Your email [1] says
>
> "If your project isn't in [3][4],
> but you think it should be; it maybe missing a recent neutron-lib
>
On 8/30/18 5:49 AM, Michel Peterson wrote:
>
> There are pre releases available in PyPI [1]. You can use those from
> your requirements like we did in n-odl [2].
>
> That might be an acceptable solution.
>
> [1] https://pypi.org/project/neutron/#history
> [2]
Below is a summary of last weeks bug activity.
I've tried to organize the summary to highlight those bugs that still
need attention.
Thanks
Needs additional technical triage:
- [dvr][ha][dataplane down] router_gateway port binding host goes wrong
after the 'master' host down/up
Please read on if your project uses neutron-lib.
During the PTG [1] we decided that projects wanting to receive
neutron-lib consumption patches [2] (for free) need to explicitly opt-in
by adding the string "neutron-lib-current" to a comment in their
requirements.txt.
Based on the list of
73 matches
Mail list logo
