----- Original Message -----
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.
Ok, then lets make sure we are testing with the *least* optimized JRE, so we've got a bottom range for performance.
On Sep 26, 2012, at 12:47 PM, Charles Crouch ccrouch@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:
- install rhq server
- install agent
- 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@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
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel mailing list rhq-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel