Yep. I completely missed that. Standalone provisioning/installation of Cassandra by a separate installer seemed a foregone conclusion to me since we require that the other RDBMs are already installed before even beginning the JON install. I was thinking more scaling ... I'll promptly exit this thread now.
----- Original Message -----
From: "Lukas Krejci" lkrejci@redhat.com To: rhq-devel@lists.fedorahosted.org Sent: Wednesday, September 26, 2012 10:26:32 AM Subject: Re: bootstrapping/deploying metrics db
On Wednesday, September 26, 2012 10:15:12 Simeon Pinder wrote: <... snip ... >
Any reason why we can't do both? For production installations, we add an optional installation step that provisions a Cassandra node on a remote box.
I think this is exactly the problem that John describes. It's a chicken-and- egg problem (if you want to have Cassandra provisioned by our provisioning subsystem).
If we have to implement a way of provisioning cassandra at installation time (i.e. WITHOUT an actual RHQ server running and offering its services) then we might just use that always and not bother with bundles for cassandra provisioning.
For dev mode and non-production installs we prepare to embed a Cassandra server but have the startup code check for an existing Cassandra node indicated by some server property, before defaulting to the embedded Cassandra node. Probably want to disable the startup check after you've chosen local or remote so you don't have the primary metric store node flip-flopping locations after install. Either way before startup you have your Cassandra node.
<... snip ...>
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel