[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Code for discussion: broker plugin loading



Fair point - also, logging to stderr goes to the apache error log anyway, so probably no need to go somewhere else (gem issues are already there)

On Jul 29, 2013, at 6:57 PM, Krishna Raman <kraman gmail com> wrote:

> Perhaps a utility which can inspect apache/broker/console logs and tell you the problem would be even better.
> If the apache log (e.g. remote user plugin config) is broken then the broker/console might not even load to a
> point where you can log to broker log.
> 
> --kr
> 
> On Jul 29, 2013, at 5:48 PM, Clayton Coleman <ccoleman redhat com> wrote:
> 
>> More log files = more things to ask users for when they have problems.  We should know enough at that point to log to the same location as the broker rails logs
>> 
>> On Jul 29, 2013, at 2:44 PM, Krishna Raman <kraman gmail com> wrote:
>> 
>>> 
>>> On Jul 29, 2013, at 1:39 PM, Luke Meyer <lmeyer redhat com> wrote:
>>> 
>>>> This little commit does a few things I'd like feedback on:
>>>> 
>>>> https://github.com/sosiouxme/origin-server/compare/broker-plugin-loading
>>>> 
>>>> 1. the /etc/openshift base for config files can be overridden by env var OPENSHIFT_CONF_DIR. This would allow us to load huge sections of the code (say, in a console, or a test) without having to actually use /etc/openshift - i.e. without needing or disturbing an actual installation. Could be used, for instance, to test plugins. Might need to chase down stray in-code references to /etc/openshift (aside from tests, docs, etc.) but the idea is there.
>>>> 
>>>> 2. Gemfile now loads plugins even if just the -dev.conf file is present - this avoids the unintuitive result where the -dev.conf file is present but production .conf isn't and the plugin doesn't actually load at all. Got a bug on this for admin console.
>>>> 
>>>> 3. Plugins are loaded in sorted order, in case it matters. It shouldn't now, but it might if we had, say, a plugin that wrapped another...
>>>> 
>>>> 4. Plugin load failures are caught and printed to stderr instead of just crashing.
>>>> 
>>>> This is the one I most need feedback on. 
>>>> 
>>>> First, printing to stderr doesn't seem to end up anywhere, but we can't exactly print to the Rails log at this point... right? 
>>>> 
>>>> Second... what *should* happen when a gem fails to load? Couple scenarios:
>>>> a. File in /etc/openshift/plugins.d that is left by mistake, misnamed, etc.
>>>> b. One plugin initialization is broken but we don't necessarily want to halt loading entirely (e.g. if your admin console is broken, just don't load it, everything else will work).
>>>> 
>>>> It would be nice to have helpful error messages in response to these conditions, something other than "Couldn't find gem openshift-origin-foo-bar... run bundle install to fix everything!"
>>> 
>>> Perhaps we should log failures to a different log file in /var/log/openshift/broker along with possible fixes for the issue.
>>> 
>>>> 
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev lists openshift redhat com
>>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>> 
>>> 
>>> _______________________________________________
>>> dev mailing list
>>> dev lists openshift redhat com
>>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]