Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safely shut down ganga to prevent bad things #794

Merged
merged 5 commits into from
Sep 19, 2016
Merged

Safely shut down ganga to prevent bad things #794

merged 5 commits into from
Sep 19, 2016

Conversation

rob-c
Copy link
Member

@rob-c rob-c commented Sep 16, 2016

Fixes #793

This replaces the erroneous template error and raises a new GangaException when a plugin fails to launch.

This correctly triggers a stop to the Ganga startup process which hopefully should allow the user a chance to fix whatever in their system/configuration is causing the problems. (or to report a bug).

@rob-c rob-c added this to the 6.2.1 milestone Sep 16, 2016
@rob-c rob-c self-assigned this Sep 16, 2016
@@ -257,12 +257,14 @@ def loadPlugins(environment):
logger.error('problems with loading Named Templates for %s', n)
logger.error('Reason: %s' % str(err))

for r in allRuntimes.values():
for n, r in zip(allRuntimes.keys(), allRuntimes.values()):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not:

for n, r in allRuntimes.items():

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Following coding style above so I'd rather stick to what's already used for sake of readability.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now defunct since latest commit but github is no longer showing this.

logger.error('Reason: %s' % str(err))
raise GangaException("Failed to load plugin: %s. Ganga will now shutdown to prevent job corruption." % n)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably avoid raising bare GangaExceptions. Instead a new exception type (GangaPluginError or similar) should be used so that when it's caught you know what happened.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GangaPluginError it is then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which doesn't exist and pulling in Core code here is against the point of splitting Core and Utlity... I'll create a new Exception type for the sake of this then.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just makes a mess of things frankly. I don't want to global import a file from Core here as that is clearly bad and I can't create a class deriving from GangaException here which we want to avoid throwing an un-caught exception to the user. (Which will arrive from some plugins!) I'm opting to keep the import here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused - I think @milliams was just saying it would be good to have a new exception class for this type of exception and import that from the exceptions in Core instead of GangaException, i.e. just create a new Exception class in Core.exceptions and import+raise that instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't we 'global import a file from Core here'? This file should be able to depend on any Core module just fine.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I'm reluctant to start going around making new exceptions for all the different situations, we just end up with a dictionary of possible classes in the exception which doesn't really shed much light imho.
  2. Fine, I'll try a global import again, but once again I strongly feel this is the wrong thing to be doing here as we shouldn't really have Core classes being imported into Utility imo as well as the amount of extra stuff pulled in out of a sane order or safe way when we do this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I would personally argue that this is a big enough collection of errors (i.e. any failure to load a plugin) that it's worth it's own exception. However I agree that in general we would want to avoid a proliferation of these.
  2. But we need to do the Core import at some point to use the exception at all and therefore it's just a question of where it goes. The import itself won't pull anything in outside of the exceptions looking at the code and we (or at least me) have been trying to make these imports as safe as possible so there is an absolute minimum of stuff done at import time for just this reason.

Copy link
Member Author

@rob-c rob-c Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've fixed this to what is requested as per the latest commit (Edit: now uploaded) but this whole file (in fact a lot of files) need to have the import situation sorted out.
Fixing 1 or 2 methods ad-hoc just makes the files messy imo and instead of each method importing what it needs where it needs it (yes a bad thing) we now have a horrible mix of global and local imports which should probably be 90%+ global imports due to a handful of circular dependencies.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I totally agree with this sentiment and I believe this should be achievable outside the Logger and the Config systems. In fact I have a (very old) branch that was doing exactly this (converting all local imports to global and making sure everything was OK) but I didn't get particularly far with it as it was low priority. I'll try to revisit this in the future.

try:
r.loadPlugins()
except Exception as err:
logger.error('problems with loading Named Templates for %s', n)
from Ganga.Core.exceptions import GangaException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This import should be at the top of the file if possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, you pull in too much accidental stuff by going near Ganga.Core

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may be missing something but looking at the code you don't pull in anything from the __init__ of Ganga.Core and in most other places in the code base I've seen the exception imports are at the top of the code. Is there a circular import problem?

@rob-c
Copy link
Member Author

rob-c commented Sep 19, 2016

What is the status of this? I'm looking to merge as we need this for #755 to raise correctly.

logger.error('Reason: %s' % str(err))
raise GangaException("Failed to load plugin: %s. Ganga will now shutdown to prevent job corruption." % n)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused - I think @milliams was just saying it would be good to have a new exception class for this type of exception and import that from the exceptions in Core instead of GangaException, i.e. just create a new Exception class in Core.exceptions and import+raise that instead.

try:
r.loadPlugins()
except Exception as err:
logger.error('problems with loading Named Templates for %s', n)
from Ganga.Core.exceptions import GangaException
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may be missing something but looking at the code you don't pull in anything from the __init__ of Ganga.Core and in most other places in the code base I've seen the exception imports are at the top of the code. Is there a circular import problem?

@rob-c
Copy link
Member Author

rob-c commented Sep 19, 2016

Changes made, this should be ready for merging I think

def __str__(self):
""" Return a string explainng our message, just like GangaException """
return "PluginError: %s" % self.msg

Copy link
Contributor

@milliams milliams Sep 19, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This whole class could be as simple as:

class PluginError(GangaException):
    pass

and inheritance will take care of the rest.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would also make it fit in nicely with #752 actually. I should really look in to getting that merged...

@rob-c
Copy link
Member Author

rob-c commented Sep 19, 2016

And now?

@rob-c rob-c merged commit 08a339a into develop Sep 19, 2016
@rob-c rob-c deleted the exitOnCrash branch September 19, 2016 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ganga should exit if it can't load a plugin
3 participants