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

Re: Code for discussion: broker plugin loading



See, you would expect stderr to go to the apache log, but it seems that Bundler just totally swallows it. And on the command line it's even worse. I added a bogus conf file and under the code I gave, this is (still) the result:

# bundle exec rails console
Could not find gem 'ahfasdfasdfsdkfk (>= 0) ruby' in the gems available on this machine.
Run `bundle install` to install missing gems.
# oo-admin-ctl-district 
Could not find gem 'ahfasdfasdfsdkfk (>= 0) ruby' in the gems available on this machine.
Run `bundle install` to install missing gems.

... which is really, *really* not the advice we want to give people. I guess Bundler is mocking gem or something. Is there any way to modify what Bundler does with errors?

In apache logs, you get the output of bundle install --local, which is:

Could not find gem 'ahfasdfasdfsdkfk (>= 0) ruby' in the gems available on this machine.

But that doesn't tell you anything about *why* it's trying to load that or what you can do about it.

----- Original Message -----
From: "Clayton Coleman" <ccoleman redhat com>
To: "Krishna Raman" <kraman gmail com>
Cc: "Luke Meyer" <lmeyer redhat com>, "Openshift Dev" <dev lists openshift redhat com>
Sent: Monday, July 29, 2013 9:01:58 PM
Subject: 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]