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.

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