bootstrapping/deploying metrics db

John Sanda jsanda at redhat.com
Wed Sep 26 13:54:28 UTC 2012


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 at redhat.com> wrote:

> 
> On Sep 26, 2012, at 9:31 AM, John Sanda <jsanda at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20120926/d1aa5a8a/attachment.html>


More information about the rhq-devel mailing list