Re: [openstack-dev] [neutron] Please opt-in for neutron-lib patches

2018-10-03 Thread Boden Russell
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 >

[openstack-dev] [neutron] Please opt-in for neutron-lib patches

2018-10-03 Thread Boden Russell
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

[openstack-dev] [neutron] Opting-in to receive neutron-lib consumption patches

2018-09-25 Thread Boden Russell
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

[openstack-dev] [neutron] Bug deputy report week of Sept 17

2018-09-24 Thread Boden Russell
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

Re: [openstack-dev] [neutron] tox-siblings alternative for local testing

2018-08-30 Thread Boden Russell
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] > [2]

Re: [openstack-dev] [neutron] tox-siblings alternative for local testing

2018-08-29 Thread Boden Russell
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

Re: [openstack-dev] [neutron] Old patches cleaning

2018-08-22 Thread Boden Russell
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

Re: [openstack-dev] [neutron] Please use neutron-lib 1.18.0 for Rocky

2018-07-24 Thread Boden Russell
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,

[openstack-dev] [neutron] Please use neutron-lib 1.18.0 for Rocky

2018-07-23 Thread Boden Russell
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

Re: [openstack-dev] [neutron] Stable review

2018-07-12 Thread Boden Russell
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

[openstack-dev] [neutron] Finalizing neutron-lib release for Rocky

2018-07-11 Thread Boden Russell
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

[openstack-dev] [neutron] Networking projects not setup properly for Zuul v3 and local testing

2018-06-25 Thread Boden Russell
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

Re: [openstack-dev] [tricircle] Zuul v3 integration status

2018-06-20 Thread Boden Russell
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] On 6/19/18 7:38 PM, linghucongsong wrote: >

[openstack-dev] [tricircle] Zuul v3 integration status

2018-06-15 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib 1.15.0 syntax error in LOG.debug

2018-06-11 Thread Boden Russell
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

[openstack-dev] [neutron] Bug deputy report May 28 - June 3

2018-06-04 Thread Boden Russell
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

[openstack-dev] [tc][stackalytics][neutron] neutron-lib not showing as TC-approved project on stackalytics

2018-05-02 Thread Boden Russell
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

Re: [openstack-dev] [requirements][horizon][neutron] plugins depending on services

2018-04-26 Thread Boden Russell
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

Re: [openstack-dev] [horizon][neutron] tools/tox_install changes - breakage with constraints

2018-03-22 Thread Boden Russell
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

Re: [openstack-dev] [requirements][neutron] Depending on pypi versions

2018-03-19 Thread Boden Russell
> On 3/19/18 7:15 AM, Andreas Jaeger wrote: > > pip install -U breaks it, please double check that this does the right > thing: > > 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

[openstack-dev] [neutron][networking-vsphere] neutron-lib patches for review

2018-02-20 Thread Boden Russell
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

[openstack-dev] [neutron] Proper usage of neutron extensions/modules

2018-02-15 Thread Boden Russell
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

[openstack-dev] [neutron] reusable code moving to neutron-lib

2017-10-30 Thread Boden Russell
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

Re: [openstack-dev] [infra][all][stable] Zuul v3 changes and stable branches

2017-10-30 Thread Boden Russell
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

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

2017-10-13 Thread Boden Russell
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

Re: [openstack-dev] [all] Zuul Error for commits

2017-10-05 Thread Boden Russell
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

[openstack-dev] [python-openstackclient][python-openstacksdk][neutron] Bridging neutronclient gaps

2017-10-04 Thread Boden Russell
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

Re: [openstack-dev] [all] Important information for people with in-repo Zuul v3 config

2017-10-04 Thread Boden Russell
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

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

2017-10-03 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: transitioning to callback payload objects

2017-09-19 Thread Boden Russell
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

Re: [openstack-dev] [docs][neutron] checking link integrity in the gate

2017-09-05 Thread Boden Russell
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?

[openstack-dev] [docs][neutron] checking link integrity in the gate

2017-09-05 Thread Boden Russell
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].

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron] supporting resource extensions with our CLI

2017-08-08 Thread Boden Russell
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

Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-08 Thread Boden Russell
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

Re: [openstack-dev] [python-openstacksdk] Status of python-openstacksdk project

2017-08-07 Thread Boden Russell
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

[openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-03 Thread Boden Russell
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]),

[openstack-dev] [neutron] neutron-lib impact: use plugin common constants from neutron-lib

2017-05-31 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: attribute functions and constants now in neutron-lib

2017-05-30 Thread Boden Russell
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]

Re: [openstack-dev] [neutron] diagnostics

2017-05-15 Thread Boden Russell
On 5/12/17 12:31 PM, Armando M. wrote: > > Please, do provide feedback in case I omitted some other key takeaway. > > [1] > [2] > > Glad you all got a chance

[openstack-dev] [neutron] neutron-lib impact: extra_dhcp_opt extension now in neutron-lib

2017-05-11 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: ml2 MechanismDriver and constants are now in neutron-lib

2017-05-04 Thread Boden Russell
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

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

2017-05-03 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

2017-05-03 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: Port security extension moved

2017-05-01 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: neutron.callbacks moved to neutron-lib

2017-04-25 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: ServicePluginBase and PluginInterface moved

2017-03-03 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib pep8 hacking checks

2017-02-27 Thread Boden Russell
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

[openstack-dev] [neutron] Does your plugin support updating network provider extended attributes?

2017-02-27 Thread Boden Russell
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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

2017-02-22 Thread Boden Russell
+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. > >

[openstack-dev] [neutron] neutron-lib impact: portbindings extension moved to neutron-lib

2017-01-19 Thread Boden Russell
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

[openstack-dev] [neutron] neutron-lib impact: providernet extension moved to neutron-lib

2017-01-19 Thread Boden Russell
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

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-23 Thread Boden Russell
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]

Re: [openstack-dev] [all] Useful tool for easier viewing of IRC logs online

2016-09-21 Thread Boden Russell
> Source code is here: > > 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.

[openstack-dev] [neutron][neutron-lib] No meeting today

2016-08-24 Thread Boden Russell
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] [2]

Re: [openstack-dev] [neutron] Let's clean up APi reference

2016-08-23 Thread Boden Russell
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] On 8/18/16 6:16 AM, Akihiro Motoki wrote: > Hi Neutron team, > > As you may

[openstack-dev] [all] Generating python API signature + diff reports

2016-08-22 Thread Boden Russell
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

Re: [openstack-dev] [Neutron][infra] Switch to xenial and Neutron unit tests

2016-07-14 Thread Boden Russell
>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

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-10 Thread Boden Russell
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

Re: [openstack-dev] [Neutron] Diagnostics & troubleshooting design summit summary and next steps

2016-05-09 Thread Boden Russell
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

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

2016-04-21 Thread Boden Russell
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

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

2016-04-21 Thread Boden Russell
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 >

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

2016-04-21 Thread Boden Russell
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

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

2016-04-20 Thread Boden Russell
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.

[openstack-dev] [neutron] PBAM Extension RFE

2016-03-30 Thread Boden Russell
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

Re: [openstack-dev] [oslo.messaging] extending notification MessagingDriver

2015-03-11 Thread Boden Russell
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:

Re: [openstack-dev] [oslo.messaging] extending notification MessagingDriver

2015-02-26 Thread Boden Russell
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

Re: [openstack-dev] [oslo.messaging] extending notification MessagingDriver

2015-02-26 Thread Boden Russell
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

[openstack-dev] [oslo.messaging] extending notification MessagingDriver

2015-02-26 Thread Boden Russell
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

[openstack-dev] [oslo.messaging] notification listener; same target with multiple executors

2015-02-12 Thread Boden Russell
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

Re: [openstack-dev] [glance] Replication on image create

2015-01-19 Thread Boden Russell
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

Re: [openstack-dev] [glance] Replication on image create

2015-01-14 Thread Boden Russell
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

[openstack-dev] [glance] Replication on image create

2015-01-13 Thread Boden Russell
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

Re: [openstack-dev] OpenStack Havana End of Upstream Support Lifetime

2014-10-09 Thread Boden Russell
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