missing paramiko makes Configuration.make_resources return {}

[GoogleCodeExporter]

While playing around with GC3Pie without having all required dependencies 
available, I ran into this:

NoResources: No resources given to initialize `gc3libs.core.Core` object!

After some debug printing, it turned out that the paramiko dependency was not 
available due to me fiddlng with $PYTHONPATH.

This was very hard to spot though, since it only resulted in 
Configuration.make_resources return {} .

Original issue reported on code.google.com by kenneth....@gmail.com on 8 Jun 2015 at 3:32

[GoogleCodeExporter]

Looking at the code, it seems that the real error should have been logged.  Did 
you see anything in the application logs?

Original comment by riccardo.murri@gmail.com on 8 Jun 2015 at 3:34

• Changed state: Accepted

[GoogleCodeExporter]

Can you please test with SVN r4283 ?

Original comment by riccardo.murri@gmail.com on 3 Jul 2015 at 10:20

[GoogleCodeExporter]

I'm still seeing this...

  File "easybuild/tools/job/gc3pie.py", line 235, in complete
    raise EasyBuildError("Failed to create GC3Pie engine: %s", err)
EasyBuildError: 'Failed to create GC3Pie engine: No resources given to 
initialize `gc3libs.core.Core` object!'

I broke my GC3Pie setup by removing the paramiko egg:

$ python -c "import gc3libs; import paramiko"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named paramiko

Original comment by kenneth....@gmail.com on 3 Jul 2015 at 2:09

[GoogleCodeExporter]

I think that the root question is this: what should the Engine do,
when there are multiple resources configured and some of them error
out?

The approach GC3Pie takes ATM is to try to initialize all resources, and
continue if at least one was correctly built.  Therefore you only get an
error at the *end* of the process, if no resource could be init'ed
correctly.  That error can only be a "generic" error ("No resources"):
what error would you otherwise report if there are two resources and
each of them fails but in a different way?

Of course, one can argue that GC3Pie should instead "fail fast and
hard": i.e., if *any* resource fails initialization, the whole
configuration process should abort immediately.  This is however a big
change from the current policy, so it should for now be optional and
*not the default*.

I have implemented this "fail fast" policy: it is selectable by
setting the environment variable
`GC3PIE_RESOURCE_INIT_ERRORS_ARE_FATAL=yes` or via an additional
argument `resource_errors_are_fatal=True` to `create_engine()`, e.g.::

    self._engine = create_engine(*self.config_files,
                                 resource_errors_are_fatal=True)

This is available from SVN r4287 onwards.

Original comment by riccardo.murri@gmail.com on 3 Jul 2015 at 10:07