Convert to pure clojure app?

[chillitom]

I was wondering if anyone had considered converting riemann-dash to a pure clojure application to remove the ruby dependency, seems like ruby/rails is barely required as it is only serving files and allowing simple config load/save.

If you thought it'd be useful/desirable then I could have a stab at it.

[aphyr]

It's really only ruby for historical reasons, and to simplify installation and updating--gem update riemann-dash is a heck of a lot easier than mucking around with tarballs. If you want to take a stab at a Clojure variant and can get the memory profile in the same ballpark, and figure out a good technique for packaging it on various *nix flavors, be my guest.

chillitom notifications@github.com wrote:

I was wondering if anyone had considered converting riemann-dash to a pure clojure application to remove the ruby dependency, seems like ruby/rails is barely required as it is only serving files and allowing simple config load/save.

If you thought it'd be useful/desirable then I could have a stab at it.

— Reply to this email directly or view it on GitHub.

[jpfuentes2]

I think you would be hard-pressed to get the memory profile for a Clojure variant close to the Ruby version.

What about a version in Go? Go has fantastic HTTP and WebSocket support, can be compiled and distributed to multiple nix environments, has a low memory footprint, and is fast.

[ghost]

To clarify--riemann-dash does no websockets handling; its whole purpose in life is to serve up some static files and store a chunk of JSON config in the filesystem. No real constraints on performance or library support there, so I suggest only taking the time to rewrite it if it makes installing, upgrading, or maintaining riemann-dash significantly simpler for users.

[jpfuentes2]

@kingsbury, I went through the dash source a few days ago and thought that was the case as I saw no WS-related code.

Perhaps the README should be changed to reflect the fact that ws* (I presumse) originates from the riemann server and not the dash server?

[jeroenvandijk]

@aphyr Regarding the ruby argument, for someone who doesn't use Ruby (anymore) in production it is not as trivial as gem update. I actually had to install extra gcc packages for Nokogiri dependencies and I had to upgrade the default ruby version from 1.8 to 1.9 as well. And then I had another problem with eventmachine dependencies of Thin that I "solved" by removing it from the gemspec.

For what the dashboard code is, static html plus js, and a config update API endpoint the above is pretty complex. I think I would prefer the config endpoint to be removed or optional, and just have a bundle of static assets that can be served by any webserver from any language. Ruby could be used to generate those bundles (like with Middleman), but wouldn't be a requirement on the server. These static assets could be bundled as a release on Github. And why not serve this static html with the normal Riemann server?

What do you guys think?

[ghost]

Huh. I honestly don't hear many complaints about the installation process, (pretty painless on a stock Debian or Ubuntu box, in my experience) but if you'd like to take over riemann-dash's server and packaging responsibilities you'd be more than welcome to do so. That might take the form of a total rewrite, or of just tuning the dependencies somewhat.

I strongly advocate against embedding it in Riemann proper; Riemann's server is already a very large and complex project, and I'm fighting hard to keep its role simple and well-defined.

[ghost]

I should also mention that 1.8 has been scheduled for EOL for some time now; haven't run anything less than 1.9.1 on a server in 3 years. apt-get install ruby1.9 build-essentials should basically handle the deps on debian, and IIRC it was pretty similar on centos.

[jeroenvandijk]

Yeah having worked with Ruby for many years I know 1.8 is a long time no go. The point though is that I had to deal with this upgrade issue anyway since it is still the default (on my Centos). Luckily I did have Ruby experience while other people might feel it is too much effort. Should we really care about Ruby specifics whereas this app is (currently) just static html?

[ghost]

I think we should do the simplest thing possible for the most people. That might just mean writing 4 lines of docs showing how to install it on centos, instead of re-writing the app from scratch.

[jeroenvandijk]

(Missed your previous comment)

I understand the complexities of the server and of maintaining these package. And to be clear, I really appreciated Riemann even though I've only used small parts of it. I just wanted to point out a different light on the matter than e.g. rewriting it to a Clojure or Go app.

When I become more familiar with Riemann I maybe have better thoughts on this.

Regarding the simplest thing possible, I couldn't agree more :-)

[jeroenvandijk]

For what it is worth, here are my notes on what I did to get things working https://gist.github.com/jeroenvandijk/283791297a56aa43a66c

[kul]

+1

[petr-tik]

Wanted to revive this discussion, as cljs has been growing and many companies are now using it. This would allow code reuse, as well as low memory footprint after clj has been compiled to js.

Ideally, you then write a .clj config file, which generates the necessary pages

Thoughts?

[jeroenvandijk]

Another 2 years later... :) I'm looking at Riemann again. I'll consider doing something with a dashboard at some point I think. In the meanwhile I found these links of other people trying:

• https://github.com/ray1729/riemann-dashboard
• https://github.com/AeroNotix/borsuk

There are some useful pieces in there I believe.