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

Re: Code for discussion: broker plugin loading




----- Original Message -----

> > > Bundler's message is sent to stdout in bright glowing colors and tells the
> > > user to run bundle install. It is hard to miss.
> > > 
> > > Also, I would like to scan the output for missing openshift-origin-* and let
> > > the user know that's probably a plugin/conf issue, vs other infrastructure
> > > ruby gems just not being there (could even give the commands for installing
> > > the RPMs).
> > > 
> > > Downside is, this will really make a mess of boot.rb ...
> > > 
> > 
> > And it probably has to be copied into console as well.
> 
> Well, at least there are no plugins there (yet...). It would be
> pretty straightforward.
> 
> One more thing we could do on the broker - have the Gemfile output
> which plugins it's trying to install according to which files; it
> would be intercepted at the same block that catches bundler output,
> and shown if something goes wrong.

It turns out this is a bad idea because you would see that output even on a successful run. Seems Gemfile is read twice, once by bundler, and once by rails.

Anyway - how about something more like this?

https://github.com/sosiouxme/origin-server/compare/broker-plugin-loading

# touch /etc/openshift/plugins.d/openshift-origin-asdashkkasdfj.conf 
# oo-admin-ctl-district 
Error while loading gems for the broker:
Could not find gem 'openshift-origin-asdashkkasdfj (>= 0) ruby' in the gems available on this machine.
You may need to install the rubygem-openshift-origin-asdashkkasdfj RPM.
Or, you may need to remove/rename the openshift-origin-asdashkkasdfj conf file(s) in /etc/openshift/plugins.d


One other interesting thing. When we start the broker we nuke Gemfile.lock and regenerate it explicitly with "bundle install --local". This would take care of the case where you updated/added/removed a gem RPM so Gemfile.lock was out of date. 

If you update a gem without restarting the broker, and then run a script that loads the broker, it still fails and tells you to bundle install. We tell people to restart the broker (to regen Gemfile.lock), which is pretty unintuitive. But it looks like Bundler now will generate Gemfile.lock, fill in missing entries, or remove unused ones whenever it is run, without having to explicitly regenerate Gemfile.lock. The only time it still complains is when there is an updated version. And in that case, rather than telling people to restart the broker, we could just recommend removing Gemfile.lock:

# oo-admin-ctl-district
Error while loading gems for the broker:
Could not find openshift-origin-admin-console-0.0.1 in any of the sources
   (note, at least now I can suppress the "bundle install" suggestion)
# rm /var/www/openshift/broker/Gemfile.lock 
# oo-admin-ctl-district 
No districts created yet.  Use 'oo-admin-ctl-district -c create' to create one.

The thing I don't like about this is having to parse Bundler's human-directed output to determine which problem it is. But Bundler gives us no other feedback that I can see.

Any thoughts before I go off and do that?


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