incubator-blur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Rohr <>
Subject Blur Console communications
Date Thu, 23 May 2013 02:09:28 GMT
Hi all,

I wanted to get your thoughts on how the console is currently architected and how we might
make it a little more drop in friendly.  Currently the console is made up of two parts, the
GUI (a Ruby on Rails app) and the Agent (a java app).

The agent is responsible for collecting information on the zookeeper instances, controllers,
shards, tables and queries.  It also has a bit of code to get some metrics from HDFS.  The
agent basically sits on a timer asking zookeeper (java api), blur (thrift) and HDFS (java
api) for its current information and writes it to a database (currently set up for mysql but
I don't believe the sql is mysql specific).

The gui is responsible for displaying the information from the database into status pages
and metrics pages.  It does have a thrift interface so that it can run searches and talk to
HDFS.  Again I don't believe that there is mysql specific sql going on here, but I can check.
 The Rails application does not talk to the agent directly, all information sharing is done
through the database currently.  

As for "installing" the console it requires unpacking the distribution and going through a
series of steps to configure the database for both sides and to configure the agent for how
to talk to blur.  Other than the admin creating symlinks to the configuration files, this
currently has to be done for each update of the code.  We have also had the issue of not being
able to package mysql with the application, so this becomes the responsibility of the person
setting up the install to go get it and configure it.

I have always wanted this app to have very simple setup or maybe even a full install process,
but I just didn't get it fully there and wanted to get the community's thoughts on how to
best do this for the future.

View raw message