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