bootstrapping/deploying metrics db

Simeon Pinder spinder at redhat.com
Wed Sep 26 14:15:12 UTC 2012



----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: rhq-devel at 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 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
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list