bootstrapping/deploying metrics db

Charles Crouch ccrouch at redhat.com
Wed Sep 26 17:14:23 UTC 2012



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