CLI scripts on the server

John Mazzitelli mazz at redhat.com
Thu Jan 6 17:34:34 UTC 2011


> Are you speaking about storing the script, or a pointer to the script?

the former

> Storing a complex / non-atomic data structure in an rdbms column abuses
> the relational paradigm,  dramatically limits the system transparency
> and adds more overall complexity to management and tooling than
> necessary.

Yes, adding LOB columns does introduce some "interesting" things to 
consider. This is why we rarely introduce them unless there is a good 
reason to (for example, years ago when we rewrote a lot of this code 
base we removed almost all (probably all, I can't remember) of the LOB 
columns that had previously existed).

> Perhaps there are specific implementation constraints

There are. Specifically, HA.  Consider:

1) I have an HA environment - suppose I have two RHQ Servers - A and B
2) Suppose I add a new alert notification that, when triggered, runs 
script S.  I add this new alert notification and upload the content of 
script S via RHQ Server A's user interface.
3) Now suppose an agent sends up data that requires that alert 
notification to trigger. But suppose that agent is talking to RHQ Server 
B. RHQ Server B needs the script so it can invoke it as part of the 
alert triggering.

How does RHQ Server A notify RHQ Server B what this script's content is? 
There are three ways to do it:
a) server A directly talks to server B (and for that matter ALL other 
servers in the HA cloud) and passes the content to them all
b) store the content in a common, distributed file system that all RHQ 
Servers have access to
c) store in the DB that all servers have access to.

a) is out - as per design, our RHQ servers do not have a direct comm 
channel to each other.

That leaves b) or c).

I mention putting the script in the DB because:

a) scripts are typically small - rarely more than several K of text. 
Thus we wouldn't be putting any additional space requirements on the 
data store (we wouldn't need to add additional capacity just to support 
storing scripts). Anything over 100K would be unusually large and very 
rare. I would think an average would be something like 100 lines of 100 
characters each (10K). Just a guess but it seems like a good estimate.

b) script text itself would not usually need to be queryable - so having 
it in a CLOB vs. VARCHAR shouldn't be an issue. No other table would 
need to have a relational constraint on this LOB column.

and the more pressing reason:

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.

Note that this is the SAME problem we have in the bundle world. We store 
bundles in the DB today for this very reason - our RHQ Servers do not 
have to have access to any common file system. If they did, yes, we 
could store all content in this common file system and just put a 
"pointer" to the file in the database (similar to how we do it with the 
"content subsystem") I really wish we integrated the content subsystem 
better, such that it is more reuseable for things like bundles (and now 
script) content. We probably could, but it would require a bit of work.


More information about the rhq-devel mailing list