----- Original Message -----
From: "John Sanda" jsanda@redhat.com To: rhq-devel@lists.fedorahosted.org Sent: Wednesday, September 26, 2012 9:54:28 AM Subject: Re: bootstrapping/deploying metrics db
Yes, that would be a viable alternative.
There is another approach I forgot to mention. When I was working on the cassandra bundle recipe, I used the stand alone bundle deployer for development and testing. It is a lot faster than having to go through the UI while doing incremental development on a bundle recipe. The stand alone deployer uses the same code that the agent does to do deployment. I could directly use those APIs to provision a Cassandra node.
Both of these approaches would limit us to installing a cassandra node on the same machine on which the RHQ server is running. This is perfectly fine for a dev environment, but I think we would want the flexibility to install that initial node on a different machine in production environment.
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. 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.
On Sep 26, 2012, at 9:42 AM, Alan Santos < asantos@redhat.com > wrote:
On Sep 26, 2012, at 9:31 AM, John Sanda < jsanda@redhat.com > wrote:
One possibility is to not fully initialize MeasurementManager until we have Cassandra up and running. This would require either the server to send notification to all agents so the each MeasurementManager instance can start up and start collecting metrics. Or the agent/MeasurementManager could poll the server to see when it can start collecting metrics. Neither of these is particularly appealing to me.
I know you're reluctant to embed a cassandra node in the same VM as the app server - but does that help out here? Scaling cassandra out can then be done via provisioning
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel