Open Stack

Yes, I agree, basically the logic of introducing promises (or fake
threads or whatever they are called) should be tested itself too.

Basically what this is all about is mocking Astute and be able to
easily program it's responses in tests.

P.


On 02/18/2015 09:27 AM, Evgeniy L wrote:
> Hi Przemyslaw,
> 
> Thanks for bringing up the topic. A long time ago we had similar
> topic, I agree that the way it works now is not good at all,
> because it leads to a lot of problems, I remember the time when our
> tests were randomly broken because of deadlocks and race conditions
> with fake thread.
> 
> We should write some helpers for receiver module, to explicitly and
> easily change state of the system, as you mentioned it should be
> done in synchronous fashion.
> 
> But of course we cannot just remove fake and we should continue
> supporting it, some fake thread specific tests should be added to
> make sure that it's not broken.
> 
> Thanks,
> 
> On Mon, Feb 16, 2015 at 2:54 PM, Przemyslaw Kaminski 
> <pkaminski at mirantis.com <mailto:pkaminski at mirantis.com>> wrote:
> 
> Hello,
> 
> This somehow relates to [1]: in integration tests we have a class 
> called FakeThread. It is responsible for spawning threads to
> simulate asynchronous tasks in fake env. In BaseIntegrationTest
> class we have a method called _wait_for_threads that waits for all
> fake threads to terminate.
> 
> In my understanding what these things actually do is that they
> just simulate Astute's responses. I'm thinking if this could be
> replaced by a better solution, I just want to start a discussion on
> the topic.
> 
> My suggestion is to get rid of all this stuff and implement a 
> predictable solution: something along promises or coroutines that 
> would execute synchronously. With either promises or coroutines we 
> could simulate tasks responses any way we want without the need to 
> wait using unpredictable stuff like sleeping, threading and such.
> No need for waiting or killing threads. It would hopefully make our
> tests easier to debug and get rid of the random errors that are
> sometimes getting into our master branch.
> 
> P.
> 
> [1] https://bugs.launchpad.net/fuel/+bug/1421599
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>
> 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>