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

Re: Code for discussion: broker plugin loading




On Jul 29, 2013, at 7:52 PM, Luke Meyer <lmeyer redhat com> wrote:

> 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?

I am shocked its not going to stdout/stderr, but remember its managed by the service script.  Possibly we're missing a redirect there?

> 
> 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]