Re: [openstack-dev] [fuel-octane] Nominate Sergey Abramov to fuel-octane core

+1 We need more cores anyway ;) On Thu, Jul 21, 2016 at 11:56 AM Oleg Gelbukh wrote: > +1 here > > Sergey's performance and quality of the code he submitted are impressive. > Please, keep going. > > -- > Best regards, > Oleg Gelbukh > > On Thu, Jul 21, 2016 at 10:21 AM,

Re: [openstack-dev] [telemetry] Gate broken by openstack/requirements

>From IRC discussion I got that Telemetry team opted out of using global-requirements and upper-constraints altogether a while ago, so I understand why my proposal is not an option. On Mon, May 16, 2016 at 3:33 PM Yuriy Taraday <yorik@gmail.com> wrote: > Isn't it just a matter

Re: [openstack-dev] [telemetry] Gate broken by openstack/requirements

Isn't it just a matter of updating upper-constraints? It seems latest generate-constraints CR [0] that includes this update is stuck for some reason so why not just update gnocchiclient in upper-constraints separately instead of dropping it from globar-requirements guard altogether? Later seems

[openstack-dev] [oslo] Liberty backward compatibility jobs are bound to fail

Hello. I've noticed once again that job "gate-tempest-dsvm-neutron-src-oslo.concurrency-liberty" is always failing. After looking at the failure I found that the core issue is ContextualVersionConflict [0]. It seems that we have conflicting requirements for oslo.utils here, and we do: in Liberty

Re: [openstack-dev] [fuel] [fuelclient] Pre-release versions of fuelclient for testing purposes

By the way, it would be very helpful for testing external tools if we had 7.0.1 release on PyPI as well. It seems python-fuelclient somehow ended up with a "stable/7.0.1" branch instead of "7.0.1" tag. On Wed, Jan 20, 2016 at 2:49 PM Roman Prykhodchenko wrote: > Releasing a

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On Thu, Jan 14, 2016 at 5:48 PM Jeremy Stanley wrote: > On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: > [...] > > Is there any plan to add Python 3.5 to infra? > > I expect we'll end up with it shortly after Ubuntu 16.04 LTS > releases in a few months (does

[openstack-dev] [zuul][infra] Synchronizing state of Zuul with Gerrit

Today we had a change [0] that somehow weren't being picked up by Zuul to gate queue although it had Workflow+1 and Verified+1. Only after I added another Workflow+1 it did get Zuul's attention. I don't know what exactly happen, but it seems Zuul didn't notice (lost) either initial Verified+1 or

Re: [openstack-dev] [Fuel][Solar] SolarDB/ConfigDB place in Fuel

Hello, everybody. It's a week old thread and I should've jumped in earlier. Better late than never. On Wed, Dec 16, 2015 at 2:04 AM Dmitriy Shulyak wrote: > Hello folks, > > This topic is about configuration storage which will connect data sources >

Re: [openstack-dev] [nova] proposed new compute review dashboard

On Fri, Dec 18, 2015 at 5:52 PM Matt Riedemann wrote: > This has come up before, but I think we should put something like this > in the nova IRC channel topic. Swift has something like this in their > IRC channel topic and it's very easy for someone new to the channel

Re: [openstack-dev] [all] tox 2.3.0 broke tempest jobs

On Sun, Dec 13, 2015 at 12:14 PM Shinobu Kinjo wrote: > What is the current status of this failure? > > > 2015-12-13 08:55:04.863 | ValueError: need more than 1 value to unpack > It shouldn't reappear in gate because CI images have been reverted to tox 2.2.1. It can be

[openstack-dev] [all] tox 2.3.0 broke tempest jobs

Tempest jobs in all our projects seem to become broken after tox 2.3.0 release yesterday. It's a regression in tox itself: https://bitbucket.org/hpk42/tox/issues/294 I suggest us to add tox to upper-constraints to avoid this breakage for now and in the future: https://review.openstack.org/256947

Re: [openstack-dev] [all] tox 2.3.0 broke tempest jobs

Hi, Jeremy. On Sat, Dec 12, 2015 at 8:27 PM Jeremy Stanley wrote: > On 2015-12-12 16:51:09 + (+), Jeremy Stanley wrote: > [...] > > No, it won't, since upper-constraints is merely used to constrain > > requirements lists. > > I take that back, the pip_install function

Re: [openstack-dev] [all] tox 2.3.0 broke tempest jobs

On Sat, Dec 12, 2015 at 10:27 PM Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2015-12-12 19:00:23 + (+0000), Yuriy Taraday wrote: > > I think it should be a good first step in right direction. For example, > > with today's issue it would break gate for tempest

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

Hi, Roman. On Thu, Dec 3, 2015 at 5:36 PM Roman Sokolkov wrote: > I've selected 13 real-world tasks from customer (i.e. update flag X in > nova.conf): > - 6/13 require fuel-library patching (or is #2 unusable) > - 3/13 are OK and can be done with #2 > - 4/13 can be done

Re: [openstack-dev] [infra] Upgrade to Gerrit 2.11

On Wed, Oct 14, 2015 at 3:08 AM Zaro wrote: > Hello All, > > The openstack-infra team would like to upgrade from our Gerrit 2.8 to > Gerrit 2.11. We are proposing to do the upgrade shortly after the > Mitaka summit. The main motivation behind the upgrade is to allow us > to

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 12:51 AM Monty Taylor wrote: > On 10/06/2015 10:52 AM, Sebastian Kalinowski wrote: > > I've already wrote in the review that caused this thread that I do not > want > > to blindly follow rules for using one or another. We should always > consider > >

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Wed, Oct 7, 2015 at 3:14 AM Monty Taylor <mord...@inaugust.com> wrote: > On 10/06/2015 06:01 PM, Thomas Goirand wrote: > > On 10/06/2015 01:14 PM, Yuriy Taraday wrote: > >> On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko <m...@romcheg.me > >

Re: [openstack-dev] [Fuel] py.test vs testrepository

On Mon, Oct 5, 2015 at 5:40 PM Roman Prykhodchenko wrote: > Atm I have the following pros. and cons. regarding testrepository: > > pros.: > > 1. It’s ”standard" in OpenStack so using it gives Fuel more karma and > moves it more under big tent > I don't think that big tent model

Re: [openstack-dev] [neutron] [oslo.privsep] Any progress on privsep?

Hello, Li. On Sat, Sep 19, 2015 at 6:15 AM Li Ma wrote: > Thanks for your reply, Gus. That's awesome. I'd like to have a look at > it or test if possible. > > Any source code available in the upstream? > You can find latest (almost approved from the looks of it)

[openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

Hello, thread! First let me address some of the very good points Alex raised in his email. On Wed, Sep 9, 2015 at 10:33 PM Alex Schultz wrote: > Fair enough, I just wanted to raise the UX issues around these types of > things as they should go into the decision making

Re: [openstack-dev] [Fuel] Let's change the way we distribute Fuel (was: [Fuel] Remove MOS DEB repo from master node)

able on Linux DVDs but it makes little sense to use them w/o > internet connection. > > > Vladimir Kozhukalov > > On Thu, Sep 10, 2015 at 2:53 PM, Yuriy Taraday <yorik@gmail.com> > wrote: > >> Note that I'll speak of Fuel as an installer people put on Mi

Re: [openstack-dev] [ironic] AttributeError: 'GitReviewException' object has no attribute 'EXIT_CODE'

Hello, Malhar. It seems that the actual error is hidden behind traceback object at 0x7f337522e3f8-like lines. Judging by line numbers in traceback that is seen, you're using version 1.25.0, and there I can see how the error got away:

[openstack-dev] [oslo] Need new release of stable oslotest with capped mock

Hello, oslo team. With recent mock nightmare we should not release a new stable version of oslotest so that projects that depend on oslotest but don't directly depend on mock will be unblocked in gate. I found out about this from this review: [0] It fails because stable oslotest 1.5.1 have

Re: [openstack-dev] [oslo] Need new release of stable oslotest with capped mock

On Wed, Jul 15, 2015 at 4:14 PM Yuriy Taraday yorik@gmail.com wrote: Hello, oslo team. With recent mock nightmare we should not release a new stable version of oslotest so that projects that depend on oslotest but don't directly depend on mock will be unblocked in gate. I found out

Re: [openstack-dev] Why do we need python-fasteners and not just oslo.concurrency?

On Wed, Jul 15, 2015 at 3:32 PM Thomas Goirand z...@debian.org wrote: I've seen that the latest version of taskflow needs fasteners, which handles lock stuff. Why can't this goes into oslo.concurrency? It already did (in a way): https://review.openstack.org/185291

Re: [openstack-dev] Looking for help getting git-review to work over https

On Thu, Jun 11, 2015, 18:09 KARR, DAVID dk0...@att.com wrote: I could use some help with setting up git-review in a slightly unfriendly firewall situation. I'm trying to set up git-review on my CentOS7 VM, and our firewall blocks the non-standard ssh port. I'm following the instructions at

Re: [openstack-dev] [infra][third-party][neutron-lbaas] git review - how to provide the URL to the test artifacts

Hello, Shane. git-review doesn't support this. You can add a comment using existing Gerrit APIs: either via SSH [0] or via HTTP [1]. [0] https://review.openstack.org/Documentation/cmd-review.html#_examples [1] https://review.openstack.org/Documentation/rest-api-changes.html#set-review On Tue,

Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues

On Sun Feb 22 2015 at 6:27:16 AM Michael Bayer mba...@redhat.com wrote: On Feb 21, 2015, at 9:49 PM, Joshua Harlow harlo...@outlook.com wrote: Some comments/questions inline... Mike Bayer wrote: Yuriy Taradayyorik@gmail.com wrote: On Fri Feb 20 2015 at 9:14:30 PM Joshua

Re: [openstack-dev] [all][oslo] Dealing with database connection sharing issues

On Fri Feb 20 2015 at 9:14:30 PM Joshua Harlow harlo...@outlook.com wrote: This feels like something we could do in the service manager base class, maybe by adding a post fork hook or something. +1 to that. I think it'd be nice to have the service __init__() maybe be something like:

Re: [openstack-dev] [oslo.db] PyMySQL review

On Mon Feb 02 2015 at 11:49:31 AM Julien Danjou jul...@danjou.info wrote: On Fri, Jan 30 2015, Yuriy Taraday wrote: That's a great research! Under its impression I've spent most of last evening reading PyMySQL sources. It looks like it not as much need C speedups currently as plain old

Re: [openstack-dev] [oslo.db] PyMySQL review

On Thu Jan 29 2015 at 12:59:34 AM Mike Bayer mba...@redhat.com wrote: Hey list - Hey, Mike. While PyMySQL is lacking test coverage in some areas, has no external documentation, and has at least some areas where Python performance can be improved, the basic structure of the driver is

Re: [openstack-dev] [Keystone] Deprecation of LDAP Assignment (Only Affects Project/Tenant/Role/Assignment info in LDAP)

Hello. On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg morgan.fainb...@gmail.com wrote: LDAP is used in Keystone as a backend for both the Identity (Users and groups) and assignments (assigning roles to users) backend. Where did the LDAP Assignment backend come from? We originally had a

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

(www.nitrodesk.com) -Original Message- From: Yuriy Taraday [yorik@gmail.com] Received: Thursday, 24 Jul 2014, 0:42 To: OpenStack Development Mailing List [openstack-dev@lists.openstack.org] Subject: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support Hello

Re: [openstack-dev] [Nova] [Neutron] Rootwrap daemon ode support

. -- Miguel Ángel Ajo Sent with Sparrow http://www.sparrowmailapp.com/?sig On Friday, 7 de November de 2014 at 11:44, Yuriy Taraday wrote: Hello, Miguel. I switched departments recently and unfortunately don't have much free time for community work. Feel free to pick up my change requests and push

Re: [openstack-dev] [kesytone][multidomain] - Time to leave LDAP backend?

On Tue, Sep 9, 2014 at 8:25 AM, Nathan Kinder nkin...@redhat.com wrote: On 09/01/2014 01:43 AM, Marcos Fermin Lobo wrote: Hi all, I found two functionalities for keystone that could be against each other. Multi-domain feature (This functionality is new in Juno.)

Re: [openstack-dev] how to provide tests environments for python things that require C extensions

On Tue, Sep 9, 2014 at 9:58 PM, Doug Hellmann d...@doughellmann.com wrote: On Sep 9, 2014, at 10:51 AM, Sean Dague s...@dague.net wrote: On 09/09/2014 10:41 AM, Doug Hellmann wrote: On Sep 8, 2014, at 8:18 PM, James E. Blair cor...@inaugust.com wrote: Sean Dague s...@dague.net

Re: [openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x

On Wed, Sep 3, 2014 at 7:24 PM, Doug Hellmann d...@doughellmann.com wrote: On Sep 3, 2014, at 5:27 AM, Yuriy Taraday yorik@gmail.com wrote: On Tue, Sep 2, 2014 at 11:17 PM, Clark Boylan cboy...@sapwetik.org wrote: It has been pointed out to me that one case where it won't be so easy

Re: [openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x

On Wed, Sep 3, 2014 at 8:21 PM, Doug Hellmann d...@doughellmann.com wrote: On Sep 3, 2014, at 11:57 AM, Clark Boylan cboy...@sapwetik.org wrote: On Wed, Sep 3, 2014, at 08:22 AM, Doug Hellmann wrote: On Sep 2, 2014, at 3:17 PM, Clark Boylan cboy...@sapwetik.org wrote: The setup.cfg

Re: [openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x

On Thu, Sep 4, 2014 at 4:47 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-09-03 13:27:55 +0400 (+0400), Yuriy Taraday wrote: [...] May be we should drop 3.3 already? It's in progress. Search review.openstack.org for open changes in all projects with the topic py34. Shortly I'll also

Re: [openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x

On Tue, Sep 2, 2014 at 11:17 PM, Clark Boylan cboy...@sapwetik.org wrote: On Tue, Sep 2, 2014, at 11:30 AM, Yuriy Taraday wrote: Hello. Currently for alpha releases of oslo libraries we generate either universal or Python 2.x-only wheels. This presents a problem: we can't adopt alpha

[openstack-dev] [oslo] [infra] Alpha wheels for Python 3.x

Hello. Currently for alpha releases of oslo libraries we generate either universal or Python 2.x-only wheels. This presents a problem: we can't adopt alpha releases in projects where Python 3.x is supported and verified in the gate. I've ran into this in change request [1] generated after

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Mon, Aug 11, 2014 at 5:44 AM, Joshua Harlow harlo...@outlook.com wrote: One question from me: Will there be later fixes to remove oslo.config dependency/usage from oslo.concurrency? I still don't understand how oslo.concurrency can be used as a library with the configuration being set

[openstack-dev] [oslo] oslo.concurrency repo review

Hello, oslo cores. I've finished polishing up oslo.concurrency repo at [0] - please take a look at it. I used my new version of graduate.sh [1] to generate it, so history looks a bit different from what you might be used to. I've made as little changes as possible, so there're still some steps

Re: [openstack-dev] [oslo] oslo.concurrency repo review

On Thu, Aug 7, 2014 at 10:58 PM, Yuriy Taraday yorik@gmail.com wrote: Hello, oslo cores. I've finished polishing up oslo.concurrency repo at [0] - please take a look at it. I used my new version of graduate.sh [1] to generate it, so history looks a bit different from what you might

Re: [openstack-dev] [git-review] Supporting development in local branches

On Thu, Aug 7, 2014 at 10:28 AM, Chris Friesen chris.frie...@windriver.com wrote: On 08/06/2014 05:41 PM, Zane Bitter wrote: On 06/08/14 18:12, Yuriy Taraday wrote: Well, as per Git author, that's how you should do with not-CVS. You have cheap merges - use them instead of erasing parts

Re: [openstack-dev] [git-review] Supporting development in local branches

On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 05:35 PM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec openst...@nemebean.com wrote: You keep mentioning detached HEAD and reflog. I have never had to deal with either when doing

Re: [openstack-dev] [git-review] Supporting development in local branches

On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen chris.frie...@windriver.com wrote: On 08/07/2014 04:52 PM, Yuriy Taraday wrote: I hope you don't think that this thread was about rebases vs merges. It's about keeping track of your changes without impact on review process. But if you rebase

Re: [openstack-dev] [git-review] Supporting development in local branches

that absolutely doesn't matter to anyone but this developer. On Wed, Aug 6, 2014 at 12:03 PM, Martin Geisler mar...@geisler.net wrote: Ben Nemec openst...@nemebean.com writes: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: When you're developing some big change you'll end up with trying

Re: [openstack-dev] [git-review] Supporting development in local branches

On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza sba...@redhat.com wrote: Le 06/08/2014 10:35, Yuriy Taraday a écrit : I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes

Re: [openstack-dev] [git-review] Supporting development in local branches

On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 03:35 AM, Yuriy Taraday wrote: I'd like to stress this to everyone: I DO NOT propose squashing together commits that should belong to separate change requests. I DO NOT propose to upload all your changes

Re: [openstack-dev] [git-review] Supporting development in local branches

On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 12:41 AM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst

Re: [openstack-dev] [git-review] Supporting development in local branches

I'll start using pictures now, so let's assume M is the latest commit on the master. On Wed, Aug 6, 2014 at 9:31 PM, Zane Bitter zbit...@redhat.com wrote: On 04/08/14 19:18, Yuriy Taraday wrote: Hello, git-review users! I'd like to gather feedback on a feature I want to implement that might

Re: [openstack-dev] [git-review] Supporting development in local branches

Oh, looks like we got a bit of a race condition in messages. I hope you don't mind. On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014 01:42 PM, Yuriy Taraday wrote: On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec openst...@nemebean.com wrote: On 08/06/2014

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld angus.salk...@rackspace.com wrote: On Tue, 2014-08-05 at 03:18 +0400, Yuriy Taraday wrote: Hello, git-review users! I'd like to gather feedback on a feature I want to implement that might turn out useful for you. I like using Git

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 3:06 PM, Ryan Brown rybr...@redhat.com wrote: On 08/04/2014 07:18 PM, Yuriy Taraday wrote: snip +1, this is definitely a feature I'd want to see. Currently I run two branches bug/LPBUG#-local and bug/LPBUG# where the local is my full history of the change

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza sba...@redhat.com wrote: -1 to this as git-review default behaviour. I don't suggest to make it the default behavior. As I wrote there will definitely be a config option that would turn it on. Ideally, branches should be identical in between

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 6:49 PM, Ryan Brown rybr...@redhat.com wrote: On 08/05/2014 09:27 AM, Sylvain Bauza wrote: Le 05/08/2014 13:06, Ryan Brown a écrit : -1 to this as git-review default behaviour. Ideally, branches should be identical in between Gerrit and local Git. Probably not as

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 7:51 PM, ZZelle zze...@gmail.com wrote: Hi, I like the idea ... with complex change, it could useful for the understanding to split it into smaller changes during development. Do we need to expose such feature under git review? we could define a new subcommand?

Re: [openstack-dev] [OpenStack-Infra] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 8:20 PM, Varnau, Steve (Trafodion) steve.var...@hp.com wrote: Yuriy, It looks like this would automate a standard workflow that my group often uses: multiple commits, create “delivery” branch, git merge --squash, git review. That looks really useful. Having it

Re: [openstack-dev] [git-review] Supporting development in local branches

On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 10:51 AM, ZZelle wrote: Hi, I like the idea ... with complex change, it could useful for the understanding to split it into smaller changes during development. I don't understand this. If it's a

Re: [openstack-dev] [git-review] Supporting development in local branches

On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 03:14 PM, Yuriy Taraday wrote: On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec openst...@nemebean.com wrote: On 08/05/2014 10:51 AM, ZZelle wrote: Hi, I like the idea ... with complex change

Re: [openstack-dev] [all][gerrit] any way to see my votes?

On Thu, Jul 31, 2014 at 2:23 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, in Gerrit UI, I would like to be able to see a separate column with my votes, so that I have a clear view of what was missed from my eye. I've looked in

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery mest...@mestery.com wrote: and even less possibly rootwrap [3] if the security implications can be worked out. Can you please provide some input on those security implications that are not worked out yet? I'm really surprised to see such comments

Re: [openstack-dev] [neutron] Spec exceptions are closed, FPF is August 21

On Thu, Jul 31, 2014 at 12:30 PM, Thierry Carrez thie...@openstack.org wrote: Carl Baldwin wrote: Let me know if I can help resolve the concerns around rootwrap. I think in this case, the return on investment could be high with a relatively low investment. I agree the daemon work around

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann d...@doughellmann.com wrote: On Jul 23, 2014, at 11:10 PM, Baohua Yang yangbao...@gmail.com wrote: Hi, all The current oslo.cfg module provides an easy way to load name known options/groups from he configuration files. I am

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann d...@doughellmann.com wrote: On Jul 24, 2014, at 1:58 PM, Yuriy Taraday yorik@gmail.com wrote: On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann d...@doughellmann.com wrote: On Jul 23, 2014, at 11:10 PM, Baohua Yang yangbao...@gmail.com

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann d...@doughellmann.com wrote: On Jul 24, 2014, at 3:08 PM, Yuriy Taraday yorik@gmail.com wrote: On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann d...@doughellmann.com wrote: On Jul 24, 2014, at 1:58 PM, Yuriy Taraday yorik@gmail.com

Re: [openstack-dev] [oslo.cfg] Dynamically load in options/groups values from the configuration files

On Fri, Jul 25, 2014 at 2:35 AM, Doug Hellmann d...@doughellmann.com wrote: On Jul 24, 2014, at 5:43 PM, Yuriy Taraday yorik@gmail.com wrote: On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann d...@doughellmann.com wrote: On Jul 24, 2014, at 3:08 PM, Yuriy Taraday yorik@gmail.com

[openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon mode support

Hello. I'd like to propose making a spec freeze exception for rootwrap-daemon-mode spec [1]. Its goal is to save agents' execution time by using daemon mode for rootwrap and thus avoiding python interpreter startup time as well as sudo overhead for each call. Preliminary benchmark shows 10x+

Re: [openstack-dev] [oslo] oslo.serialization and oslo.concurrency graduation call for help

Hello, Ben. On Mon, Jul 21, 2014 at 7:23 PM, Ben Nemec openst...@nemebean.com wrote: Hi all, The oslo.serialization and oslo.concurrency graduation specs are both approved, but unfortunately I haven't made as much progress on them as I would like. The serialization repo has been created

Re: [openstack-dev] [neutron] Spec Proposal Deadline has passed, a note on Spec Approval Deadline

proposed quite some time ago. I'd like to see this work get in to juno. Carl On Jul 12, 2014 9:53 AM, Yuriy Taraday yorik@gmail.com wrote: Hello, Kyle. On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery mest...@noironetworks.com wrote: Just a note that yesterday we

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On Fri, Jul 11, 2014 at 10:34 PM, Joshua Harlow harlo...@outlook.com wrote: S, how about we can continue this in #openstack-state-management (or #openstack-oslo). Since I think we've all made the point and different viewpoints visible (which was the main intention). Overall, I'd like

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On Thu, Jul 10, 2014 at 11:51 PM, Outlook harlo...@outlook.com wrote: On Jul 10, 2014, at 3:48 AM, Yuriy Taraday yorik@gmail.com wrote: On Wed, Jul 9, 2014 at 7:39 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Yuriy Taraday's message of 2014-07-09 03:36:00 -0700: On Tue, Jul 8

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On Wed, Jul 9, 2014 at 7:39 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Yuriy Taraday's message of 2014-07-09 03:36:00 -0700: On Tue, Jul 8, 2014 at 11:31 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I think clints response was likely better than what I can write here, but

Re: [openstack-dev] [oslo] Asyncio and oslo.messaging

On Tue, Jul 8, 2014 at 11:31 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I think clints response was likely better than what I can write here, but I'll add-on a few things, How do you write such code using taskflow? @asyncio.coroutine def foo(self): result = yield from

Re: [openstack-dev] [neutron] Specs repo

Every commit landing to every repo should be synchronized to GitHub. I filed a bug to track this issue here: https://bugs.launchpad.net/openstack-ci/+bug/1337735 On Fri, Jul 4, 2014 at 3:30 AM, Salvatore Orlando sorla...@nicira.com wrote: git.openstack.org has an up-to-date log:

Re: [openstack-dev] [Jenkins] [Cinder] InvocationError in gate-cinder-python26 python27

On Fri, Jul 4, 2014 at 12:57 PM, Amit Das amit@cloudbyte.com wrote: Hi All, I can see a lot of cinder gerrit commits that pass through the gate-cinder-python26 gate-cinder-python27 successfully. ref - https://github.com/openstack/cinder/commits/master Whereas its not the case for my

Re: [openstack-dev] [all] milestone-proposed is dead, long lives proposed/foo

On Thu, Jul 3, 2014 at 5:00 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-07-02 22:19:29 +0400 (+0400), Yuriy Taraday wrote: [...] It looks like mirrors will have to bear having a number of dead branches in them - one for each release. A release manager will delete proposed/juno

Re: [openstack-dev] [all] milestone-proposed is dead, long lives proposed/foo

Hello. On Fri, Jun 27, 2014 at 4:44 PM, Thierry Carrez thie...@openstack.org wrote: For all those reasons, we decided at the last summit to use unique pre-release branches, named after the series (for example, proposed/juno). That branch finally becomes stable/juno at release time. In

Re: [openstack-dev] [Nova][Oslo.cfg] Configuration string substitution

Hello On Fri, Jun 20, 2014 at 12:48 PM, Radoslav Gerganov rgerga...@vmware.com wrote: Hi, On Wed, Jun 18, 2014 at 4:47 AM, Gary Kotton gkot...@vmware.com wrote: Hi, I have encountered a problem with string substitution with the nova configuration file. The motivation was to move all

Re: [openstack-dev] [nova][cinder] Refactor ISCSIDriver to support other iSCSI transports besides TCP

Hello, Shlomi. On Tue, Mar 25, 2014 at 7:07 PM, Shlomi Sasson shlo...@mellanox.com wrote: I want to share with the community the following challenge: Currently, Vendors who have their iSCSI driver, and want to add RDMA transport (iSER), cannot leverage their existing plug-in which inherit

Re: [openstack-dev] [nova][cinder][ceilometer][glance][all] Loading clients from a CONF object

On Fri, Jun 13, 2014 at 3:27 AM, Jamie Lennox jamielen...@redhat.com wrote: And as we're going to have to live with this for a while, I'd rather use the more clear version of this in keystone instead of the Heat stanzas. Anyone else have an opinion on this? I like keeping sections' names

Re: [openstack-dev] [Nova] nova-compute deadlock

This behavior of os.pipe() has changed in Python 3.x so it won't be an issue on newer Python (if only it was accessible for us). From the looks of it you can mitigate the problem by running libguestfs requests in a separate process (multiprocessing.managers comes to mind). This way the only

Re: [openstack-dev] [Nova] nova-compute deadlock

the return value and exception between these two processes. That will make this solution very complex. Do you agree? On Thu, Jun 5, 2014 at 9:39 PM, Yuriy Taraday yorik@gmail.com wrote: This behavior of os.pipe() has changed in Python 3.x so it won't be an issue on newer Python (if only

Re: [openstack-dev] [all] Hide CI comments in Gerrit

On Tue, May 27, 2014 at 6:07 PM, James E. Blair jebl...@openstack.orgwrote: I wonder if it would be possible to detect them based on the presence of a Verified vote? Not all CIs always add a vote. Only 3 or so of over 9000 Neutron's CIs put their +/-1s on the change. -- Kind regards,

Re: [openstack-dev] Policy for linking bug or bp in commit message

On Wed, May 28, 2014 at 3:54 AM, Joe Gordon joe.gord...@gmail.com wrote: On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno na...@ntti3.com wrote: (2) Avoid duplication of works I have several experience of this. Anyway, we should encourage people to check listed bug before writing patches.

Re: [openstack-dev] Divergence of *-specs style checking

Great idea! On Mon, May 19, 2014 at 8:38 PM, Alexis Lee alex...@hp.com wrote: Potentially the TITLES structure could be read from a per-project YAML file and the test itself could be drawn from some common area? I think you can get that data from template.rst file by parsing it and

Re: [openstack-dev] Searching for docs reviews in Gerrit

Hello, Anne. On Sat, May 17, 2014 at 7:03 AM, Anne Gentle a...@openstack.org wrote: file:section_networking-adv-config.xml project:openstack/openstack-manuals As it's stated in the manual: The regular expression pattern must start with ^. Meaning that it'll always look only for files whose

Re: [openstack-dev] [qa] Debugging tox tests with pdb?

Hello, Eric. On Wed, May 7, 2014 at 10:15 PM, Pendergrass, Eric eric.pendergr...@hp.comwrote: Hi, I’ve read much of the documentation around Openstack tests, tox, and testr. All I’ve found indicates debugging can be done, but only by running the entire test suite. I’d like the ability

Re: [openstack-dev] [infra][neutron]SystemExit() vs sys.exit()?

On Thu, May 1, 2014 at 8:17 PM, Salvatore Orlando sorla...@nicira.comwrote: The patch you've been looking at just changes the way in which SystemExit is used, it does not replace it with sys.exit. In my experience sys.exit was causing unit test threads to interrupt abruptly, whereas

Re: [openstack-dev] [infra][neutron]SystemExit() vs sys.exit()?

On Thu, May 1, 2014 at 10:41 PM, Paul Michali (pcm) p...@cisco.com wrote: == FAIL: process-returncode tags: worker-1 -- *Binary content:* * traceback

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

On Fri, Apr 25, 2014 at 11:41 PM, Zaro zaro0...@gmail.com wrote: Do you mean making it default to WIP on every patchset that gets uploaded? No. I mean carrying WIP to all new patch sets once it is set just like Code-Review -2 is handled by default. Gerrit 2.8 does allow you to carry the same

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

Hello. On Wed, Apr 23, 2014 at 2:40 AM, James E. Blair jebl...@openstack.orgwrote: * The new Workflow label will have a -1 Work In Progress value which will replace the Work In Progress button and review state. Core reviewers and change owners will have permission to set that value

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

On Fri, Apr 25, 2014 at 8:10 PM, Zaro zaro0...@gmail.com wrote: Gerrit 2.8 allows setting label values on patch sets either thru the command line[1] or REST API[2]. Since we will setup WIP as a -1 score on a label this will just be a matter of updating git-review to set the label on new

Re: [openstack-dev] Decorator behavior

Hello. On Mon, Mar 31, 2014 at 9:32 PM, Dan Smith d...@danplanet.com wrote: (self, context, [], {'migration': migration, 'image': image, 'instance': instance, 'reservations': reservations}) while when running a test case, they see these arguments: (self, context, [instance,

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin c...@ecbaldwin.net wrote: Don't discard the first number so quickly. For example, say we use a timeout mechanism for the daemon running inside namespaces to avoid using too much memory with a daemon in every namespace. That means we'll pay the

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Fri, Mar 21, 2014 at 2:01 PM, Thierry Carrez thie...@openstack.orgwrote: Yuriy Taraday wrote: Benchmark included showed on my machine these numbers (average over 100 iterations): Running 'ip a': ip a : 4.565ms

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Tue, Mar 18, 2014 at 7:38 PM, Yuriy Taraday yorik@gmail.com wrote: I'm aiming at ~100 new lines of code for daemon. Of course I'll use some batteries included with Python stdlib but they should be safe already. It should be rather easy to audit them. Here's my take on this: https

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Tue, Mar 11, 2014 at 12:58 AM, Carl Baldwin c...@ecbaldwin.net wrote: https://etherpad.openstack.org/p/neutron-agent-exec-performance I've added info on how we can speedup work with namespaces by setting namespaces by ourselves using setns() without ip netns exec overhead. -- Kind

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

On Thu, Mar 20, 2014 at 7:28 PM, Rick Jones rick.jon...@hp.com wrote: On 03/20/2014 05:41 AM, Yuriy Taraday wrote: Benchmark included showed on my machine these numbers (average over 100 iterations): Running 'ip a': ip a : 4.565ms

  1   2   >