CLI scripts on the server

John Mazzitelli mazz at redhat.com
Thu Jan 6 20:38:59 UTC 2011


> A shared file system isn't terribly onerous, isn't uncommon and it's
> only required if you need to share scripts amongst highly available RHQ
> servers.

We recently added this capability to allow URL references to bundle 
files (as opposed to uploading them directly to the server into the DB). 
It is nice to have content stored in a customer's own filesystem but it 
is optional - if you want to use it, specify your bundle using a file: 
URL to point to your NFS mounted location where your bundle is located 
(i.e. file:/my-nfs-mount/bundles/foo.zip).

However, note the difference - in the new bundle stuff - you aren't 
REQUIRED to use a distributed filesystem for the feature to work. If you 
don't (or can't) setup a filesystem shared across RHQ Servers, you are 
free to use the bundle subsystem anyway - just upload the content and 
we'll take care of distributing the content for you (via the DB).

In the script case, if we ONLY support this feature by REQUIRING a 
shared file system - that introduces a requirement we never had and 
might cause some users not to be able to use it at all. It means you 
can't use this feature if you are using HA (multiple servers) but have 
no distributed filesystem common across all of them. That is limiting to 
me. I much prefer a more configurable option - use it if you want, don't 
use it if you don't or can't.

I say we split the difference and do what we do for the bundle subsystem 
- support the ability to store scripts in the DB --or-- use URL based 
script locations (thus I can use file: URLs to specify where the script 
is located - or for that matter http:). This has the added benefit of 
allowing customers to host their scripts on a web server or some content 
control system (perhaps a git repo or a svn repo) - which was an actual 
enhancement request that came from the community for the bundle stuff 
and precipitated that new optional feature of allowing the URL-based 
bundle locations.


More information about the rhq-devel mailing list