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