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

It is not possible to install Riemann from a locally hosted package (TAR,RPM) #13

Open
noroute opened this issue Nov 14, 2014 · 5 comments

Comments

@noroute
Copy link

noroute commented Nov 14, 2014

For many organizations it is not an option to download software from external sources upon host setup.

We'd like to be able to install Riemann from a locally hosted, reviewed, known-good version.

I could provide a PR to either parametrize the path to the TAR to be installed (simple) or provide an installation from proper RPMs (more intrusive).

Would anyone be interested in any of these?

@garethr
Copy link
Owner

garethr commented Nov 14, 2014

@noroute I'd certainly be more than happy to see either or both of these, I have other modules with a custom package install route.

noroute pushed a commit to noroute/garethr-riemann that referenced this issue Nov 16, 2014
Simple approach to solve garethr#13. RPM/DEB-based approach is more
difficult as paths differ between archive and packages.
@noroute
Copy link
Author

noroute commented Nov 16, 2014

I have a branch that makes the tar location configurable, as references above.

I'm a bit reluctant to open a PR as I think the solution based on packages would be much better.
Having said that, I see two problems there:

  1. The packages provided by @aphyr use distribution path (/usr/bin, etc.) while the archives are placed in /opt/*. Making the puppet module handle both would probably lead to code much more complicated than it should be. Changing the paths for the archive would be backwards-incompatible (for those updating machines, not everyone lives on immutable containers).
  2. The solution would have to work for RPM and DEB based systems. I would be able to provide much more thorough testing for RPM as our infrastructure is RPM based.

@garethr Would do you think? Especially about the path issues and backward compatibility.

@garethr
Copy link
Owner

garethr commented Dec 4, 2014

I think you could probably move most of the path issues into a param with a default value, and allow overing that in the init. That should remove the need for lots of duplication.

I'm not too bothered about the compatibility of moving from one installation mechanism to the other, I think as long as the module defaults to doing as it does now that's fine.

I'm maybe start small, by allowing overing the URL used to download Riemann.

You could then work on swapping that with a package resource. I'm happy for that to leave the setup of package repos or building packages as an exercise for the user, which should minimise the cross-platform testing requirement.

@heartpunk
Copy link

We have a branch mostly ready for this at Udacity, too. I just haven't had the bandwidth to wrap it up yet.

@gregswift
Copy link

As a side note the quickstart guide says:

You can also install Riemann via the Debian or RPM packages, through Puppet, Vagrant, or Chef.

Which at first pass made me believe that the config management modules had the information on package installs.

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

4 participants