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