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

Re: Code for discussion: broker plugin loading




----- Original Message -----
> From: "Jordan Liggitt" <jliggitt redhat com>
> To: "Luke Meyer" <lmeyer redhat com>
> Cc: "Openshift Dev" <dev lists openshift redhat com>
> Sent: Tuesday, July 30, 2013 10:38:41 AM
> Subject: Re: Code for discussion: broker plugin loading
> 
> On 07/29/2013 04:39 PM, Luke Meyer 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.
> Is this really what we want to do? Running production from dev files
> could do really weird things, especially with integration with other
> systems. Case in point, PROD got pointed to a test Aria instance for a
> little while a few months before launch... long enough for production
> accounts on our end to get tied to accounts in a test environment in
> Aria.

Ooh, good point. It would be better to exclude the -dev files if not in development mode. Thanks!

> > 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!"
> >
> > _______________________________________________
> > 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]