bootstrapping/deploying metrics db

Lukas Krejci lkrejci at redhat.com
Wed Sep 26 15:11:56 UTC 2012


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

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


More information about the rhq-devel mailing list