+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, Artur Svechnikov <
> asve
>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 wrote:
> Isn't it just a matter of updating upper-cons
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 lik
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 u
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 beta version sounds l
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 anybody know for sure what
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
Wo
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
> (nailgun/bareon/others) and orchestration. An
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 to
> go in and see what thei
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 reproduced locally if one
On Sat, Dec 12, 2015 at 10:27 PM Jeremy Stanley wrote:
> On 2015-12-12 19:00:23 + (+), 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 itself only since all
>
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 in DevStack applies
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
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 with some limitations.
>
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 take advantage of so
On Wed, Oct 7, 2015 at 3:14 AM Monty Taylor 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 >> <mailto:m...@romcheg.me>> wrote:
> >>
> &g
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
> > technical requirements.
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 aims at eliminati
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) version of
blueprint here: https
are available 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
> wrote:
>
>> Note that I'll speak of Fuel as an installer people put on MiniCD. It's a
&
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 process.
>
UX issues is w
Hello, Malhar.
It seems that the actual error is hidden behind ""-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:
https://github.com/openstack-infra/git-review/blob/1.25.0/git_review/cmd.py#L768
Can you edit f
On Wed, Jul 15, 2015 at 3:32 PM Thomas Goirand 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
_
On Wed, Jul 15, 2015 at 4:14 PM Yuriy Taraday 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
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 uncapp
On Thu, Jun 11, 2015, 18:09 KARR, DAVID 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
http://docs.opensta
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, Ap
On Sun Feb 22 2015 at 6:27:16 AM Michael Bayer wrote:
>
>
>
> > On Feb 21, 2015, at 9:49 PM, Joshua Harlow wrote:
> >
> > Some comments/questions inline...
> >
> > Mike Bayer wrote:
> >>
> >> Yuriy Taraday wrote:
> >>
> >
On Fri Feb 20 2015 at 9:14:30 PM Joshua Harlow 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:
>
> def __i
On Mon Feb 02 2015 at 11:49:31 AM Julien Danjou 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
> > spee
On Thu Jan 29 2015 at 12:59:34 AM Mike Bayer 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 perfectly fine and
>
Hello.
On Wed Jan 28 2015 at 11:30:43 PM Morgan Fainberg
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
> single backend for Ide
nd move it
> forward. Thank you very much for your contribution.
>
> --
> 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
2, Miguel Angel Ajo Pelayo wrote:
>
> +1
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
>
> -Original Message-
> From: Yuriy Taraday [yorik@gmail.com]
> Received: Thursday, 24 Jul 2014, 0:42
> To: OpenStack Development Mailing List [opens
On Tue, Sep 9, 2014 at 9:58 PM, Doug Hellmann wrote:
>
> On Sep 9, 2014, at 10:51 AM, Sean Dague wrote:
>
> > On 09/09/2014 10:41 AM, Doug Hellmann wrote:
> >>
> >> On Sep 8, 2014, at 8:18 PM, James E. Blair wrote:
> >>
> >>> Sean Dague writes:
> >>>
> The crux of the issue is that zookee
On Tue, Sep 9, 2014 at 8:25 AM, Nathan Kinder 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.)
> >
> > -
On Thu, Sep 4, 2014 at 4:47 AM, Jeremy Stanley 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 &quo
On Wed, Sep 3, 2014 at 8:21 PM, Doug Hellmann wrote:
>
> On Sep 3, 2014, at 11:57 AM, Clark Boylan wrote:
> > On Wed, Sep 3, 2014, at 08:22 AM, Doug Hellmann wrote:
> >>
> >> On Sep 2, 2014, at 3:17 PM, Clark Boylan wrote:
> >>> The setup.cfg classifiers should be able to do that for us, though
On Wed, Sep 3, 2014 at 7:24 PM, Doug Hellmann wrote:
>
> On Sep 3, 2014, at 5:27 AM, Yuriy Taraday wrote:
>
> On Tue, Sep 2, 2014 at 11:17 PM, Clark Boylan
> wrote:
>
>> It has been pointed out to me that one case where it won't be so easy is
>> oslo.mess
On Tue, Sep 2, 2014 at 11:17 PM, Clark Boylan 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 present
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
global-r
Hello.
It started (for me) with a bug [1] that stated one problem with POSIX
semaphores. I started implementing fix for that [2] and it appeared that
there are other issues with lockutils.
Discussion got spread over bug [1] and Gerrit [2] and got limited to those
who get notifications on them.
I'd
On Mon, Aug 11, 2014 at 5:44 AM, Joshua Harlow 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 in a static man
On Fri, Aug 8, 2014 at 3:03 AM, Chris Friesen
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.
>>
>
>
On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec wrote:
> On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec
> wrote:
> >> You keep mentioning detached HEAD and reflog. I have never had to deal
> >> with either when doing
On Thu, Aug 7, 2014 at 10:28 AM, Chris Friesen
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 -
On Thu, Aug 7, 2014 at 10:58 PM, Yuriy Taraday 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
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 le
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 wrote:
> On 08/06/2014 01:42 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec
> wrote:
> >
> >> On 08/06/20
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 wrote:
> On 04/08/14 19:18, Yuriy Taraday wrote:
>
>> Hello, git-review users!
>>
>> I'd like to gather feedback on a feature
On Wed, Aug 6, 2014 at 7:23 PM, Ben Nemec wrote:
> On 08/06/2014 12:41 AM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec
> wrote:
> >
> >> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> >>> On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
On Wed, Aug 6, 2014 at 6:20 PM, Ben Nemec 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 a
On Wed, Aug 6, 2014 at 12:55 PM, Sylvain Bauza 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
>> up
story that absolutely doesn't matter to anyone but this developer.
On Wed, Aug 6, 2014 at 12:03 PM, Martin Geisler wrote:
> Ben Nemec writes:
>
> > On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> >>
> >> When you're developing some big change you&#
On Wed, Aug 6, 2014 at 1:17 AM, Ben Nemec wrote:
> On 08/05/2014 03:14 PM, Yuriy Taraday wrote:
> > On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec
> wrote:
> >
> >> On 08/05/2014 10:51 AM, ZZelle wrote:
> >>> Hi,
> >>>
> >>>
> >
On Tue, Aug 5, 2014 at 10:48 PM, Ben Nemec 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 complex ch
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.
>
>
>
On Tue, Aug 5, 2014 at 7:51 PM, ZZelle 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? git review
On Tue, Aug 5, 2014 at 6:49 PM, Ryan Brown 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 default
On Tue, Aug 5, 2014 at 5:27 PM, Sylvain Bauza 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 Gerrit and local G
On Tue, Aug 5, 2014 at 3:06 PM, Ryan Brown wrote:
>
> On 08/04/2014 07:18 PM, Yuriy Taraday wrote:
> >
>
> +1, this is definitely a feature I'd want to see.
>
> Currently I run two branches "bug/LPBUG#-local" and "bug/LPBUG#" where
> the
On Tue, Aug 5, 2014 at 5:15 AM, Angus Salkeld
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
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 for development. It allows me to keep track of current
development process, it remembers everything I ever did with the code (and
more).
I also really like us
On Thu, Jul 31, 2014 at 12:30 PM, Thierry Carrez
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 oslo.rootwra
On Wed, Jul 30, 2014 at 11:52 AM, Kyle Mestery 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 in some ML thread n
On Thu, Jul 31, 2014 at 2:23 PM, Ihar Hrachyshka
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 settings, and fa
On Fri, Jul 25, 2014 at 2:35 AM, Doug Hellmann
wrote:
>
> On Jul 24, 2014, at 5:43 PM, Yuriy Taraday wrote:
>
>
>
>
> On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann
> wrote:
>
>>
>> On Jul 24, 2014, at 3:08 PM, Yuriy Taraday wrote:
>>
>&
On Fri, Jul 25, 2014 at 12:05 AM, Doug Hellmann
wrote:
>
> On Jul 24, 2014, at 3:08 PM, Yuriy Taraday wrote:
>
>
>
>
> On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann
> wrote:
>
>>
>> On Jul 24, 2014, at 1:58 PM, Yuriy Taraday wrote:
>>
>
On Thu, Jul 24, 2014 at 10:31 PM, Doug Hellmann
wrote:
>
> On Jul 24, 2014, at 1:58 PM, Yuriy Taraday wrote:
>
>
>
>
> On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann
> wrote:
>
>>
>> On Jul 23, 2014, at 11:10 PM, Baohua Yang wrote:
>>
>> Hi,
On Thu, Jul 24, 2014 at 4:14 PM, Doug Hellmann
wrote:
>
> On Jul 23, 2014, at 11:10 PM, Baohua Yang wrote:
>
> Hi, all
> The current oslo.cfg module provides an easy way to load name known
> options/groups from he configuration files.
> I am wondering if there's a possible solution to
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+ spee
Hello, Ben.
On Mon, Jul 21, 2014 at 7:23 PM, Ben Nemec 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 and has enough acks
ul 12, 2014 at 10:00 AM, Carl Baldwin < c...@ecbaldwin.net >
> wrote:
> >
> >
> >
> >
> > +1 This spec had already been proposed quite some time ago. I'd like to
> see
> > this work get in to juno.
> >
> > Carl
> > On Jul 12, 2014 9:53 AM,
Hello, Kyle.
On Fri, Jul 11, 2014 at 6:18 PM, Kyle Mestery
wrote:
> Just a note that yesterday we passed SPD for Neutron. We have a
> healthy backlog of specs, and I'm working to go through this list and
> make some final approvals for Juno-3 over the next week. If you've
> submitted a spec whic
On Fri, Jul 11, 2014 at 10:34 PM, Joshua Harlow
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 to see asyncio
On Thu, Jul 10, 2014 at 11:51 PM, Outlook wrote:
> On Jul 10, 2014, at 3:48 AM, Yuriy Taraday wrote:
>
> On Wed, Jul 9, 2014 at 7:39 PM, Clint Byrum wrote:
>
>> Excerpts from Yuriy Taraday's message of 2014-07-09 03:36:00 -0700:
>> > On Tue, Jul 8, 2014 at 11:
On Wed, Jul 9, 2014 at 7:39 PM, Clint Byrum 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
> > wrote:
> >
> > > I think clints response was likely better than what I can write here,
> but
> > > I'll add-on a few thi
On Tue, Jul 8, 2014 at 11:31 PM, Joshua Harlow
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 some_async_o
On Fri, Jul 4, 2014 at 12:57 PM, Amit Das 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 patch
> https:
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
wrote:
> git.openstack.org has an up-to-date log:
> http://git.openstack.org/cgit/o
On Thu, Jul 3, 2014 at 5:00 AM, Jeremy Stanley 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 wil
Thanks for clarification.
On Wed, Jul 2, 2014 at 6:59 PM, Jeremy Stanley wrote:
> On 2014-07-02 16:14:52 +0400 (+0400), Yuriy Taraday wrote:
> > Why do we need these short-lived 'proposed' branches in any form?
> > Why can't we just use release branches for thi
One problem that comes to mind is that screen tries to reopen your terminal
when you attach to existing session or run a new one.
So if you have one user you log in to a test server (ubuntu? root?) and
another user that runs screen session (stack), you won't be able to attach
to the session unless
Hello.
On Fri, Jun 27, 2014 at 4:44 PM, Thierry Carrez
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 parallel, we abandon
Hello, Doug.
On Mon, Jun 23, 2014 at 6:11 PM, Doug Hellmann
wrote:
> $ git log --abbrev-commit --pretty=oneline 0.15..1.0.0.0a1
> d37b47f Merge "Updated from global requirements"
> bc2d08a Updated from global requirements
> e8e9ca1 Fix incorrect image reference in documentation
> d39ef75 Fix req
Hello
On Fri, Jun 20, 2014 at 12:48 PM, Radoslav Gerganov
wrote:
> Hi,
>
> > On Wed, Jun 18, 2014 at 4:47 AM, Gary Kotton wrote:
> > > Hi,
> > > I have encountered a problem with string substitution with the nova
> > > configuration file. The motivation was to move all of the glance
> settings
Hello, Shlomi.
On Tue, Mar 25, 2014 at 7:07 PM, Shlomi Sasson 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 from
> iSCSI
>
>
On Fri, Jun 13, 2014 at 3:27 AM, Jamie Lennox
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 simple and cle
t; need to write code to pass 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 wrote:
>
>> This behavior of os.pipe() has changed in Python 3.x so it won'
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 descr
On Wed, May 28, 2014 at 3:54 AM, Joe Gordon wrote:
> On Fri, May 23, 2014 at 1:13 PM, Nachi Ueno wrote:
>
>> (2) Avoid duplication of works
>> I have several experience of this. Anyway, we should encourage people
>> to check listed bug before
>> writing patches.
>>
>
> That's a very good point,
On Tue, May 27, 2014 at 6:07 PM, James E. Blair wrote:
> 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, Yuriy.
___
Great idea!
On Mon, May 19, 2014 at 8:38 PM, Alexis Lee 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
analyzing the tree.
Hello, Anne.
On Sat, May 17, 2014 at 7:03 AM, Anne Gentle 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 paths start
Hello, Eric.
On Wed, May 7, 2014 at 10:15 PM, Pendergrass, Eric
wrote:
> 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 to run a single te
On Thu, May 1, 2014 at 10:41 PM, Paul Michali (pcm) wrote:
> ==
> FAIL: process-returncode
> tags: worker-1
> --
> *Binary content:*
> * traceback (test/plain;
On Thu, May 1, 2014 at 8:17 PM, Salvatore Orlando wrote:
> 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 SystemExit was being caug
On Fri, Apr 25, 2014 at 11:41 PM, Zaro 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 label score for
On Fri, Apr 25, 2014 at 8:10 PM, Zaro 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 patchsets. I'm no
Hello.
On Wed, Apr 23, 2014 at 2:40 AM, James E. Blair wrote:
>
> * 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
> (which will b
1 - 100 of 142 matches
Mail list logo
