Oh, no I didn't. By the time I got around to it I saw 264 and figured that
would cover the issue.
On Mon, Jul 13, 2015 at 7:33 PM, Robert Collins robe...@robertcollins.net
wrote:
On 10 July 2015 at 22:07, Kevin Benton blak...@gmail.com wrote:
No prob. The fixes for Neutron were relatively
On 13 July 2015 at 13:04, Dave McCowan (dmccowan) dmcco...@cisco.com wrote:
Has anyone else seen this error with the new mock?
'self' parameter lacking default value
My function under test runs correctly, but then Mock throws this TypeError
when comparing the parameters in
On 14 July 2015 at 22:41, Kevin Benton blak...@gmail.com wrote:
Oh, no I didn't. By the time I got around to it I saw 264 and figured that
would cover the issue.
Ok - could you check? 1.1.3 has issue 264 fixed, and I'd like to fix
this one too, if its still an issue. Bonus points for checking
On 10 July 2015 at 22:07, Kevin Benton blak...@gmail.com wrote:
No prob. The fixes for Neutron were relatively trivial.
https://review.openstack.org/#/c/200420/
The only one that was a bit surprising was the failure of autospec in this
file:
Has anyone else seen this error with the new mock?
'self' parameter lacking default value
My function under test runs correctly, but then Mock throws this TypeError
when comparing the parameters in assert_calls_with().
I'm seeing this in Barbican. More info below [1][2].
--Dave
[1]
Robert Collins wrote:
Good news everybody, mock 1.1.0 is now out. This backports all the
improvements over the last couple of years, making it fully
synchronised with cPython master. Yay.
Bad news. Lots of unit tests jobs have suffered falled from this.
But - none of the things I've
How do we test to see what is failing in each project with the new version?
Also, I'm responsible for the reference to the private mock method in
Neutron. That particular reference is to prevent people from patching the
same target twice because mock.patch.stopall() unwinds patches in a
On 10 July 2015 at 20:23, Kevin Benton blak...@gmail.com wrote:
How do we test to see what is failing in each project with the new version?
Look at any CI failure in the last 5 hours or so.
Or run tox :).
Also, I'm responsible for the reference to the private mock method in
Neutron. That
On 10 July 2015 at 20:18, Thierry Carrez thie...@openstack.org wrote:
Robert Collins wrote:
Good news everybody, mock 1.1.0 is now out. This backports all the
...
1.1.0 makes that an error, for methods with assert prefixes - unless
unsafe is specifically requested. So a big chunk of the
Kevin Benton wrote:
How do we test to see what is failing in each project with the new version?
Just watch one of the thousands tests currently failing in zuul:
http://status.openstack.org/zuul/
Or see the recent periodic stable maint jobs fail reports at:
Thanks. I didn't realize it was already breaking everything. I thought it
might have been stuck in requirements bump patch somewhere.
Thats fixed in 1.1.0. So you should be able to unwind that. If you need a
short term workaround, its in mock.mock now.
Yeah, I know it's fixed, I reported the
On 10 July 2015 at 20:50, Kevin Benton blak...@gmail.com wrote:
Thanks. I didn't realize it was already breaking everything. I thought it
might have been stuck in requirements bump patch somewhere.
Thats fixed in 1.1.0. So you should be able to unwind that. If you need a
short term workaround,
Good news everybody, mock 1.1.0 is now out. This backports all the
improvements over the last couple of years, making it fully
synchronised with cPython master. Yay.
Bad news. Lots of unit tests jobs have suffered falled from this.
But - none of the things I've looked into so far are bugs in
No prob. The fixes for Neutron were relatively trivial.
https://review.openstack.org/#/c/200420/
The only one that was a bit surprising was the failure of autospec in this
file:
https://review.openstack.org/#/c/200420/4/neutron/tests/unit/services/metering/agents/test_metering_agent.py
It was
I'm looking at Nova unit tests, there are at least 3 issues.
The first one is assert_has_calls *used* to work with a single value
m.assert_has_calls(foo)
The documentation says m.assert_has_calls([foo]) is what you should use,
but the other form used to work. That appears to be tightened up.
On 10 July 2015 at 22:07, Kevin Benton blak...@gmail.com wrote:
No prob. The fixes for Neutron were relatively trivial.
https://review.openstack.org/#/c/200420/
The only one that was a bit surprising was the failure of autospec in this
file:
On 07/10/2015 03:45 AM, Robert Collins wrote:
Good news everybody, mock 1.1.0 is now out. This backports all the
improvements over the last couple of years, making it fully
synchronised with cPython master. Yay.
Bad news. Lots of unit tests jobs have suffered falled from this.
But - none
On 2015-07-10 13:21:56 +0200 (+0200), Victor Stinner wrote:
I see mock===1.0.1 in upper-constraints.txt, but the python27
check job of Swift was broken by the release of mock 1.1.
Can someone please explain me why Swift check job failed?
As far as I'm aware, only DevStack is making use of
On 10/07/2015 10:42, Robert Collins wrote:
Releasing this on a Friday sounds like bad timing, especially without
advance notice that we'd have to rush to fix the dozens of new issues it
would expose.
There would never be a good time to release such things. The whole
point of the constraints
On 2015-07-10 19:45:10 +1200 (+1200), Robert Collins wrote:
[...]
Python 2.6 support was dropped in 1.1.0, so we need to use markers
to select 1.0.1 for the remaining 2.6 gate jobs. (We should kill
those of asap).
[...]
Unless we convince ourselves it's worthwhile to EOL Juno early, we
can't
Le 10/07/2015 13:39, Jeremy Stanley a écrit :
On 2015-07-10 13:21:56 +0200 (+0200), Victor Stinner wrote:
I see mock===1.0.1 in upper-constraints.txt, but the python27
check job of Swift was broken by the release of mock 1.1.
Can someone please explain me why Swift check job failed?
As far
On 2015-07-10 18:15:18 +0200 (+0200), Victor Stinner wrote:
Is there a plan to use pinned versions on other gates to avoid similar
issues in the future? (Decide when we upgrade a dependency)
Sachi has a design underway for applying constraints files to tox
envs as well:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OK, we got 1.1.1 released today, and now gate is broken in some other wa
y:
ImportError: No module named funcsigs
Apparently there is a missing dependency, or it fails to apply, in the
package. I see jobs failing with it, as well as my local tox
On 11 July 2015 at 10:14, Ihar Hrachyshka ihrac...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
OK, we got 1.1.1 released today, and now gate is broken in some other wa
y:
ImportError: No module named funcsigs
Apparently there is a missing dependency, or it fails to
On 11 July 2015 at 04:50, Jeremy Stanley fu...@yuggoth.org wrote:
On 2015-07-10 18:15:18 +0200 (+0200), Victor Stinner wrote:
Is there a plan to use pinned versions on other gates to avoid similar
issues in the future? (Decide when we upgrade a dependency)
Sachi has a design underway for
25 matches
Mail list logo
