Open Stack

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.
>
> 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