Open Stack

On Fri, Jan 25, 2013 at 5:21 PM, Clark Boylan <clark.boylan at gmail.com> wrote:
> On Fri, Jan 25, 2013 at 4:09 PM, Joshua Harlow <harlowja at yahoo-inc.com> wrote:
>> Totally weird, is there anyway to get access to the raw jenkins logs for
>> that 'build'.
> The closest thing to the raw jenkins log is going to be the console.html file.
>>
>> I wonder if somehow something went south that might be in those logs?
> If you look in http://logs.openstack.org/18909/9/gate/gate-python-keystoneclient-python26/565/nose_results.html.gz
> you will see that nose failed to run those tests at all because
> setUpModule threw an exception. This didn't result in the tests
> failing instead the errors were ignored and nose continued to run and
> reported a successful test run.
>>
>> It seems like
>> http://logs.openstack.org/18909/9/gate/gate-python-keystoneclient-python26/
>> 565/ should not have passed.
> I agree. setUpModule appears to be a noseism and nose doesn't treat
> errors in setUpModule as a failure but probably should.
Er, the handling of setUpModule exceptions in this way appears to be a
noseism (there is no setUpModule in python2.6 unittest or testtools as
far as I can tell). From the python 2.7 unittest docs "If an exception
is raised in a setUpModule then none of the tests in the module will
be run and the tearDownModule will not be run. If the exception is a
SkipTest exception then the module will be reported as having been
skipped instead of as an error", which implies it should be treated as
an error.
>>
>> On 1/25/13 4:07 AM, "Henry Nash" <henryn at linux.vnet.ibm.com> wrote:
>>
>>>So a couple of things:
>>>
>>>1) Yes, keystone itself does use AssertDictEqual in a number of places in
>>>its tests (and as stated earlier imports unittest2 to achieve this)
>>>2) I have been trying work out how the error in client was not picked
>>>up...and I still can't really explain it.  The change that introduced
>>>assertDictEqual in keystoneclient was
>>>https://review.openstack.org/#/c/18909/ in test_auth_token_middleware.py
>>>- and it is clearly using testtools (i.e. it was correctly based on the,
>>>already merged, "move to testtools code").  Yet jenkins passed all the
>>>tests?  Any ideas?
>>>
>>>Henry
>>>On 25 Jan 2013, at 00:03, Monty Taylor wrote:
>>>
>>>>
>>>>
>>>> On 01/25/2013 11:01 AM, Robert Collins wrote:
>>>>> On 25 January 2013 12:54, Monty Taylor <mordred at inaugust.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 01/25/2013 09:49 AM, Joshua Harlow wrote:
>>>>>>> Ok, so would just having testtools use unittest2 work better?
>>>>>>
>>>>>> Ah. Hrm. Looping in Robert.
>>>>>
>>>>> It is a possibility. OTOH then that question can be asked for every
>>>>> other base class out there.
>>>>>
>>>>> I would say:
>>>>> - if you want to use a unittest2.TestCase only feature:
>>>>>  - subclass unittest2.TestCase (use multiple inheritance if you also
>>>>> need testtools features).
>>>>
>>>> Hrm. I think for the in-general case for openstack's usage of testtools,
>>>> additionally subclassing unittest2 at times is likely heavy-weight.
>>>>
>>>>>  - or file a bug that that feature isn't available in testtools
>>>>> (which explicitly supports Python2.6).
>>>>
>>>> How about let's start with a wiki page of suggested usage - and then in
>>>> parallel file bugs against testtools about missing bits?
>>>>
>>>> Monty
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>_______________________________________________
>>>OpenStack-dev mailing list
>>>OpenStack-dev at lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev