-
Notifications
You must be signed in to change notification settings - Fork 99
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
Conversation
@@ -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()): |
There was a problem hiding this comment.
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():
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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 GangaException
s. Instead a new exception type (GangaPluginError
or similar) should be used so that when it's caught you know what happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GangaPluginError
it is then.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
- 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
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) |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
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 | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
And now? |
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).