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