UnitTest: log to stdout

By printing the log messages to stdout, they will be captured by nose,
thus not disturbing the user. Should a test fail, the messages will
still be displayed.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Acked-by: Germano Percossi <germano.percossi@citrix.com>
UnitTest: Enable custom context

Should the user want to use a custom context implementation, he can use
the with_custom_context decorator to do that. It enables users to
inherit from TestContext, extend its functionality, and use the extended
version in a test. This could be useful if someone wanted to use a
custom implementation for `open`.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Acked-by: Germano Percossi <germano.percossi@citrix.com>
CA-140596: [UnitTest] Test to reproduce gc error

This test will reproduce the issue that was seen in the referenced
ticket. Whenever a new Lock instance is created, and the file() call
fails, the instance's lockfile attribute remained uninitialised. As the
instance has a custom destructor, that will be called by the garbage
collector. That function assumes that the instance has a lockfile
attribute, and thus prints a message.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Acked-by: Germano Percossi <germano.percossi@citrix.com>
CA-140596: Fix lockfile attribute in Lock

As Lock's destructor was assuming that lockfile attribute exists, it
printed out an AttributeError on stdout while the GC was cleaning it up.
This fix initialises the lockfile field in the constructor.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Reviewed-by: Germano Percossi <germano.percossi@citrix.com>
CA-140596: Add seam for file call

Extract the file call to a separate method, so that the extracted method
could be used in tests as a seam, emulating situations like: what would
happen if the file call failed.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Reviewed-by: Germano Percossi <germano.percossi@citrix.com>
CA-140596: [UnitTest] Test file not found in Lock

These are test cases covering the lock module, and also testing what
happens if file() raises an IOError. This can happen as a race
condition, if two locks - A and B are created in the same namespace and
by the time A gets to open the lockfile, B already cleaned up the
namespace.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Acked-by: Germano Percossi <germano.percossi@citrix.com>
CA-140596: Fix file creation error

If creating the lockfile failed with IOError having ENOENT error code,
that means that another lock within the same namespace already cleaned
up the namespace. With this change, should IOError happen with ENOENT,
the lock will re-create the namespace, and the file 10 times, and only
bubble up the exception if it failed all those retries.

Signed-off-by: Mate Lakat <mate.lakat@citrix.com>
Reviewed-by: Germano Percossi <germano.percossi@citrix.com>
Merge fixes for CA-140596 (plus unit test improvements) into xs64bit

Signed-off-by: Germano Percossi <germano.percossi@citrix.com>

GitHub: closes #197 on xapi-project/sm