Hi all,

The couchDB issue Michael mentioned in independent and had to do with a
system update on my system; so ignore it.

I just ran the test on my ubuntu system running on vmware ( where I am also
running Rabbit 2.7.1 and Couchdb 111 ) and it passed:

bin/nosetests -v -a INT ion/services/dm/distribution/test/test_pubsub.py -s


----------------------------------------------------------------------
Ran 1 test in 3.572s

OK


So I think the issue is with Ian's environment and not the software stack.
He should always assume that it is his environment before trying to get
others involved and spending more time, per Michael's comments. Linux and
all of the variations are tricky and do consume a lot of extra time that
could be spent developing in the supported environment.


Stephen


----------------
Stephen P. Henrie  mailto:shenrie@ucsd.edu
System Architect
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org <http://ci.oceanobservatories.org/>

From:  Michael Meisinger <mmeisinger@ucsd.edu>
Date:  Mon, 23 Jan 2012 20:36:49 +0000
To:  "Manning, Maurice" <mmmanning@mail.ucsd.edu>
Cc:  Stephen Henrie <shenrie@eng.ucsd.edu>, "Ampe, Tim" <tampe@ucsd.edu>
Subject:  Re: AMQP bugs

Hi all, 

I think Stephen has found an issue with Ubuntu CouchDB and is working on it.

The bigger question is why do we allow developers to work with environments
other than our standard development enviornment (MacOS Snow Leopard) and our
standard deployment environment (buildbot or hopefully soon CentOS 6.2)?

Working on Ubuntu and setting thigns up there burns cycles (see Ian's "spent
a day here and a day there). If it's Jamie doing it for the production
environment it's one thing. If it's a developer doing it by themselves, it's
wasted time. Burning time here and there...

Thanks,
Michael

------------
Michael Meisinger    <mailto:mmeisinger@ucsd.edu>    phone: 858.822.7882
Managing System Architect
Ocean Observatories Initiative Cyberinfrastructure Project:
http://ci.oceanobservatories.org




On Jan 23, 2012, at 6:21 AM, Maurice Manning wrote:

> 
> Hi Michael
> Not sure if Dave has talked with you about this issue yet or who else has run
> into it. If we cant run integration tests, it is going to be a problem to meet
> Tim's integration goals.
> 
> Btw, the nosetest that Ian's identifies below (test_pubsub) works fine for me
> running locally on my fresh build.
> 
> Thanks
> 
> Maurice Manning
> 858.822.4433
> mmmanning@ucsd.edu
> 
> 
> Begin forwarded message:
> 
>> From: Tim Ampe <tampe@ucsd.edu>
>> Date: January 21, 2012 11:29:00 AM PST
>> To: Ian Katz <ifreecarve@gmail.com>
>> Cc: Maurice Manning <mmmanning@ucsd.edu>
>> Subject: Re: AMQP bugs
>> 
>> Ian, are there any other tasks you can work on (now that all the E3 tasks are
>> in Jira) in the meantime?
>> 
>> ----------------------------------------------------
>> Tim Ampe
>> System Development Manager
>> Ocean Observatories Initiative Cyberinfrastructure Project:
>> http://ci.oceanobservatories.org <http://ci.oceanobservatories.org/>
>> 
>> 858.822.5141 Office
>> 858.232.3844 Cell
>> tampe@ucsd.edu
>> 
>> 
>> On Jan 21, 2012, at 6:17 AM, Ian Katz wrote:
>> 
>>> It became a full-time thing for me, and I'm not sure what changed.  It
>>> fails in any of a few ways, based on timing.  Only one of the ways
>>> results in an actual error traceback, the rest produce "Container did
>>> not shutdown correctly.  Killed".
>>> 
>>> Here is the example I showed Dave:
>>> https://gist.github.com/f2173bdcfbc8ee2f6bcf
>>> 
>>> Dave and I did a bit more with it yesterday, and I helped him get to
>>> the point where he could reproduce it reliably on his setup.  If
>>> integration tests work on your machine (for example: bin/nosetests -v
>>> -a INT ion/services/dm/distribution/test/test_pubsub.py -s) then you
>>> can probably push forward, but for the time being I'm stuck.
>>> 
>>> -Ian
>>> 
>>> On Fri, Jan 20, 2012 at 6:24 PM, Maurice Manning <mmmanning@ucsd.edu> wrote:
>>>> Hi Ian
>>>> So is this bug a full-stop blocker for integration testing or does it only
>>>> occur occasionally? If it is occasional, is there a characteristic by which
>>>> we can recognize it and then just re-run? I am wondering if it is possible
>>>> for us to push forward or do we all need to fall back to mock testing.
>>>> 
>>>> Thanks
>>>> 
>>>> Maurice Manning
>>>> 858.822.4433
>>>> mmmanning@ucsd.edu
>>>> 
>>>> 
>>>> On Jan 20, 2012, at 6:34 AM, Ian Katz wrote:
>>>> 
>>>>> Hi Maurice-
>>>>> 
>>>>> I spent almost all of yesterday tracing down a bug with Dave Foster
>>>>> (the same one that I started on with Jamie).  He was unable to
>>>>> reproduce it on his machine, so we did a lot of back and forth.  There
>>>>> is apparently some race condition in the messaging layer that causes
>>>>> the integration tests to error out, and it's not clear whether its
>>>>> part of our code or the pika library.  Dave would have the details.
>>>>> Anyway, this morning Chris was able to reproduce it on a machine at
>>>>> ASA, so hopefully they will get to the bottom of it more efficiently
>>>>> now.  Dave says it's his top priority, so I'm going to wait for his
>>>>> instructions on how to proceed.
>>>>> 
>>>>> For now, I'm turning my attention back to the sequence diagram I never
>>>>> finished -- the one for changing over an instrument.
>>>>> 
>>>>> -Ian
>>>>> 
>>>>> --
>>>>> Ian Katz
>>>>> Research Software Engineer, MIT LAMSS
>>>>> ijk5@mit.edu
>>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Ian Katz
>>> Research Software Engineer, MIT LAMSS
>>> ijk5@mit.edu
>> 
>