CLI scripts on the server

Alan Santos alan.santos at redhat.com
Thu Jan 6 19:33:12 UTC 2011


Fair points and I agree on everything, including the tradeoffs. I 
believe that's what it boils down to.

I don't agree, but am willing to be convinced otherwise,  that there's a 
lack of need to query content.  I'm thinking specifically about 
maintainability.  Scripts will reference resources, resources will 
change.   People will forget what scripts do, nevermind what they do it to.

How do I know what scripts are affected by changes to my topology?    
Ideally there's some form of impact analysis - we don't have that but 
until we do I can grep.   It's probably faster anyhow and doesn't 
require that I know SQL or the JON schema.  If I need to edit that 
script I can use my favorite editor, not the UI.   I don't need to 
provide an export capability for the script in the first iteration.  I 
may not even need to provide a 'view' of the script content from the 
UI.  Also, it's one less thing for a DBA to complain about - and that's 
really all they get paid for.

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.

-alan



On 1/6/11 12:34 PM, John Mazzitelli wrote:
> c) storing it on the file system would introduce a new requirement we'd
> have to place on the server installations - users would now be required
> to install RHQ Servers on machines that have access to the same
> filesystem (via NFS or some other distributed file system). We do not
> have this requirement today - RHQ Servers today do not have to have
> access to any common filesystem - RHQ Servers can be completely
> independent from one another.



More information about the rhq-devel mailing list