Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Convert to pure clojure app? #32

Open
chillitom opened this issue Jul 15, 2013 · 14 comments
Open

Convert to pure clojure app? #32

chillitom opened this issue Jul 15, 2013 · 14 comments

Comments

@chillitom
Copy link
Contributor

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
Copy link
Collaborator

aphyr commented Jul 15, 2013

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 [email protected] 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
Copy link

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
Copy link

ghost commented Jul 28, 2013

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
Copy link

@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
Copy link

@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
Copy link

ghost commented Jul 29, 2013

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
Copy link

ghost commented Jul 29, 2013

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
Copy link

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
Copy link

ghost commented Jul 29, 2013

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
Copy link

(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
Copy link

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

@kul
Copy link

kul commented Nov 21, 2014

+1

@petr-tik
Copy link

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
Copy link

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:

There are some useful pieces in there I believe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants