Split repository

[lwf]

The dependencies for riemann-tools are spiraling out of control, now requiring mysql libraries and libxslt1 to be installed on target systems. This is just going to keep getting worse as more and more stuff is added to the main riemann-tools repository.

I have discussed the idea of splitting this repository into multiple, per-tool repos with @aphyr before and would be willing to put effort into this again if there's an interest in going in this direction.

[aphyr]

Sounds like a good plan to me!

Torbjörn Norinder [email protected] wrote:

The dependencies for riemann-tools are spiraling out of control, now requiring mysql libraries and libxslt1 to be installed on target systems. This is just going to keep getting worse as more and more stuff is added to the main riemann-tools repository.

I have discussed the idea of splitting this repository into multiple, per-tool repos with @aphyr before and would be willing to put effort into this again if there's an interest in going in this direction.

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

[gsandie]

I'd be happy to help with this where I can :)

[fborgnia]

I'm also willing to help if needed 👍

[ghost]

OK, I'm gonna create a Riemann organization and invite y'all; we can spool up new repos for different tools. I suggest we name them "riemann-hbase", "riemann-mysql", etc.

[aphyr]

OK, for starters, we've got riemann-mysql and riemann-resmon; those are the two that suck in the mysql and nokogiri dependency. I suggest that we create them as gems which depend on riemann-tools; that'll allow us to use the common riemann-tools option handling and mainloop (and perhaps some unified scheduler in the future). I wish I could sketch out these repos myself right now but I'm a bit overwhelmed with some other projects. LWF, Gavin, one of you want to take the lead on creating one of these projects as an example?

[aphyr]

https://github.com/riemann

[gsandie]

@aphyr Thanks for doing that :)

I agree that splitting them into gems and sucking in riemann-tools would be a good approach. I'll grab riemann-resmon and sort it out, since I've got a bunch of resmon installs here I can test it against. I'm not going to get a chance to look at it today, but I'm travelling the next few days so I've got time on planes to get it done.

[lwf]

I was thinking of setting up a repository containing a skeleton (or possibly a generator script) for new tools. Bit busy during the next few days, but I'll have something up and running by the end of the week (given that it sounds like a good idea).

[ghost]

Would it make sense to drop the generator script in the riemann-tools repo?

[fborgnia]

@kingsbury @aphyr @gsandie https://github.com/riemann/riemann-mysql is now published as a stand alone gem. Please take a quick look, thanks.
I could take care of another one by next week, will discuss it over irc.

cheers.

[ghost]

Looks perfect, @fborgnia. I'll remove riemann-mysql from riemann-tools.

[gsandie]

Sorry for the delay here, but I've split out resmon into it's own gem - https://github.com/riemann/riemann-resmon - tested it against a resmon instance and all seems well.

@aphyr Do you want to take a look over it?

[jamtur01]

See #136 - would love feedback and eyes on this PR! Ping @gsandie @dgtized @fborgnia @lwf @aphyr

[jamtur01]

Next steps:

• Roll gems for programs and push.
• Move riemann-tools repo to this org.
• Update Riemann tools to reflect change (warning message?).
• Updated Riemann.io docs to reflect this.

Optional.

• Build a self-maintaining GH pages site for all the utilities.

[jamtur01]

Going to close this.