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
> vers
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 accordin
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 identif
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
https://bugs.launc
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] https://review.openstack.org/#/c/58
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 respec
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 small
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, bu
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 probably
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 bef
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
th
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 tes
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:
> w
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 m
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
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 f
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 appear
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 o
> 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
neu
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 stabl
on module attributes were applicable, we can minimize the number of
breakages that occur in this process.
Feel free to reach out to me (boden) on openstack-neutron with any
questions/comments.
Thank you!
[1] http://codesearch.openstack.org/
[2] https://review.openstack.org/#/c/544179/
[3]
h
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 w
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 playb
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 not
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/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/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 t
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 are
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?
___
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]. I've
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 t
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 [1].
For a summary read on...
For OpenStack APIs that support extensions (ex [2]), the
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 your
thing.
Feel free to catch me on #openstack-neutron as 'boden' if you have any
questions.
Thanks
[1] https://review.openstack.org/#/c/394244/
[2] https://review.openstack.org/#/c/449277/
[3]
https://review.openstack.org/#/q/message:%22use+core+resource+attribute+constants%22
[4] https://re
you all got a chance to discuss this topic!
I've added some additional notes and comments to the etherpad ([1] from
your list). Please feel free to reach out to me on IRC ('boden') for further
discussion.
Thanks
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 imp
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
identify all modules that
import the constants, but the respective source will need to be inspected
to determine which constants are applicable to neutron-lib.
Also, feel free to reach out to me ('boden') on #openstack-neutron if
there's questions/comments/etc..
[1]
http://codesear
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 oth
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 neutron-
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 projec
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
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 gor
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 A
+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.
>
> Cheers
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 n
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 neu
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]
https://github.com/opensta
> 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. However
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] https://review.openstack.org/#/q/proj
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 know
l gauge interest based on feedback here, and/or find me on
#openstack-neutron as 'boden'.
[1] https://github.com/openstack/neutron-lib/blob/master/tools/pyir.py
[2] http://paste.openstack.org/show/562199/
[3] http://paste.openstack.org/show/562200/
___
ate vmware-nsx defects [2] as needed
for any such failures and/or reach out to me on IRC ('boden').
Thanks
[1] https://review.openstack.org/#/c/342128
[2] https://bugs.launchpad.net/vmware-nsx
On 7/12/16 6:18 PM, Armando M. wrote:
> Hi Neutrinos,
>
> OpenStack infra is in
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
___
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 session
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 custom
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
> retr
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 impl
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
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 interest
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
= host1,host2
The above 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
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 oslo.messaging.noti
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/19/15 12:21 PM, Nikhil Komawar wrote:
> It would be great to open up a BP/spec on this.
I've opened a set of BPs / specs which capture my current thoughts in
the image replication space:
* Glance support for multiple stores of the same type / scheme. Think
cinder multi-backend support wit
> 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 /
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. Frankl
rocessing.
Is the dev team adverse to option #1 for the store driver's who wish to
implement it and / or what are the other (preferred) options here?
Thank you,
- boden
__
OpenStack Development Mailing List (not
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
> >> re
On 8/1/2014 4:37 AM, Eoghan Glynn wrote:
Heat cfntools is based on SSH, so I assume it requires TCP/IP connectivity
between VM and the central agent(or collector). But in the cloud, some
networks are isolated from infrastructure layer network, because of security
reasons. Some of our customers
Disclaimer: I'm not fully vested on ceilometer internals, so bear with me.
For consumers wanting to leverage ceilometer as a telemetry service atop
non-OpenStack Clouds or infrastructure they don't own, some edge cases
crop up. Most notably the consumer may not have access to the hypervisor
ho
On 7/28/2014 8:40 AM, Denis Makogon wrote:
On Fri, Jul 25, 2014 at 9:00 PM, boden mailto:bo...@linux.vnet.ibm.com>> wrote:
Gents,
As we discussed at the BP meeting on July 14 - I've created a new BP
and BP wiki to outline the dynamic extension loading using stevedo
g
PoC code:
https://github.com/bodenr/trove/commit/fa06e1d96e6a49a2a54057e8feb8e624edeaf728
I've also added this to the agenda for the next BP meeting:
https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting
Please feel free to add comments to wiki or via email / IRC (@boden);
otherwise w
We were recently having a discussion over here in trove regarding a
standardized format to use for log and error messages - obviously
consistency is ideal (within and across projects). As this discussion
involves the broader dev community, bringing this topic to the list for
feedback...
I'm
Hey guys,
Just a friendly reminder that we'll (re)review the configurable db
plugins BP on Monday June 23rd. The spec is here:
https://wiki.openstack.org/wiki/Trove/ConfigurableDBPlugins
Please take a moment to review prior to our BP meeting if you have an
interest in this topic.
I've updat
Guys,
In the BP meeting yesterday we briefly discussed the 'Configurable DB
Plugins' BP:
https://blueprints.launchpad.net/trove/+spec/configurable-db-plugins
It was clear I needed to hash this one out in greater detail to
optimally discuss the feature with the group - I've done that and you
On 4/28/2014 2:58 PM, Dan Smith wrote:
I'd like to propose the ability to support a pluggable trove conductor
manager. Currently the trove conductor manager is hard-coded [1][2] and
thus is always 'trove.conductor.manager.Manager'. I'd like to see this
conductor manager class be pluggable like no
On 4/28/2014 3:03 PM, Denis Makogon wrote:
Good day, Boden.
I think you should file the blueprint for it and put it into BP meeting
agenda.
Best regards,
Denis Makogon
On Mon, Apr 28, 2014 at 9:50 PM, boden mailto:bo...@linux.vnet.ibm.com>> wrote:
Guys,
I have a few small fe
Guys,
I have a few small features / enhancements I'd like to suggest. I'm
willing to contribute the code / unit tests myself, but am looking for a
consensus from the group before I invest the time.
There are a few enhancements on my list -- I will send details each in a
separate email to keep
Guys,
I have a few small features / enhancements I'd like to suggest. I'm
willing to contribute the code / unit tests myself, but am looking for a
consensus from the group before I invest the time.
There are a few enhancements on my list -- I will send details each in a
separate email to keep
Guys,
I have a few small features / enhancements I'd like to suggest. I'm
willing to contribute the code / unit tests myself, but am looking for a
consensus from the group before I invest the time.
There are a few enhancements on my list -- I will send details each in a
separate email to keep
On 11/14/2013 9:29 AM, Anastasia Sklyankina wrote:
Hello, everybody!
I have some problem with rally "boot_and_bounce_server" test
specifically with "stop_start".
I ran stop_start test 3 times with 12 instances booted in 5 threads
(used base_task.json file is attached).
Rally launches all 12 ins
87 matches
Mail list logo