bootstrapping/deploying metrics db

John Sanda jsanda at redhat.com
Wed Sep 26 17:10:30 UTC 2012


I'd go a step further with respect to requiring users to configure cassandra and say it is a non-starter. I believe that DataStax recommends the Oracle JRE because optimizations have been made around its garbage collector.

On Sep 26, 2012, at 12:47 PM, Charles Crouch <ccrouch at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> I'm not sure if using our provisioning subsys against using some
>> third-party
>> or handwritten provisioning solution is going to be much of a change
>> for the
>> user.
>> 
>> Either way they need to go out to the target machine and install
>> something
>> there at first.
>> 
>> If we provision cassandra using bundles, they need to go out and
>> install our
>> agent on the target machine first. Granted, that is a more understood
>> procedure
>> for us, but for a new user, that doesn't make much difference.
>> After the agent is installed and configured, standing up and
>> configuring a new
>> cassandra node on that machine can be fully automatic, I imagine.
>> Still it's a
>> 3 step process:
>> 1) install rhq server
>> 2) install agent
>> 3) provision a bundle with cassandra node
>> 
>> If we go with a custom provisioning solution (btw. are there RPMs for
>> cassandra?) 
> 
> That's a good question:
> 
> http://www.datastax.com/docs/0.8/install/install_package
> 
> But that obvioulsy won't help on non-Linux platforms
> 
> BTW Why does Datastax recommend the Oracle JRE versus OpenJDK for running Cassandra?
> Given we support OpenJDK we will need to make sure our solution works with that.
> 
>> we leave the configuration of the Cassandra node in the
>> hand of the
>> users. On the other hand they theoretically wouldn't need to install
>> an agent
>> (although we would probably later require it anyway for monitoring
>> and tuning,
>> etc). The advantage of this solution is that we circumvent the
>> chicken-and-egg
>> problem of RHQ server requiring cassandra requiring rhq server to
>> install
>> itself. Disadvantage being that the user needs to know how to
>> configure 2
>> distinct beasts - RHQ agent AND cassandra.
> 
> I would say thats a pretty bad thing, since we've let our persistent store outside of the black box we're trying to keep it in
> 
> I think a lot of customers know how to install RHQ agents and will have built that into their deployment processes
> Cassandra would be an entirely new thing
> 
>> 
>> A third solution (which occured to me right now, so the egdes are
>> exceptionally rough) might be that we provision a specialized
>> agent+cassandra
>> embedded inside it (I think something like this appeared on one of
>> your slides
>> though, John). All other agents consider the server down until this
>> one agent
>> is provisioned the same way as agents are provisioned today and
>> reports back
>> to the server. In the server UI, we'd have a big red warning in the
>> meantime
>> that a metric storage hasn't been initialized yet and no agents are
>> therefore
>> able to report to the server.
>> Not sure if this even a viable alternative, just wanted to write it
>> down
>> before the eager garbage collector in my brain makes me forget it ;)
>> 
>> 
>> Lukas
>> 
>> On Wednesday, September 26, 2012 09:54:28 John Sanda wrote:
>>> 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
>> _______________________________________________
>> 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