bootstrapping/deploying metrics db

John Sanda jsanda at redhat.com
Wed Sep 26 15:04:18 UTC 2012


On Sep 26, 2012, at 10:26 AM, Lukas Krejci <lkrejci at redhat.com> wrote:

> 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.

I do want to use our provisioning in the general case even if we need to do something differently for the bootstrapping use case(s). Any machine that is going to run a cassandra node on it will have to have an agent on it as well. We already have all the infrastructure in place with our provisioning system, and that infrastructure has been out in production and has been tested.

> 
>> 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list