Heroku instance missing stable version tar

adamonduty commented 10 years ago

When trying to install on a fresh ubuntu precise vm, I get this:

vagrant@precise32:~$ bash < <( curl http://rvm-fw.herokuapp.com/releases/rvm-install-latest )
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   910  100   910    0     0   2891      0 --:--:-- --:--:-- --:--:--  7844
Installing RVM Version: 1.18.14
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2126  100  2126    0     0   5523      0 --:--:-- --:--:-- --:--:-- 12730

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
bash: ./scripts/install: No such file or directory

Investigating a bit, it seems that this line fails because 1.18.14.tar.gz doesn't exist on the server:

vagrant@precise32:~$ curl "http://rvm-fw.herokuapp.com/rubies/packages/rvm/1.18.14.tar.gz"                              
<html>
  <head>
    <title>RVM::FW - Hidden Rubies for RVM</title>
    <meta content='text/html; charset=utf-8' http-equiv='Content-Type'>
    <meta viewport='width=device-width, initial-scale=1.0'>
    <link href='/stylesheets/styles.css' media='screen, projection' rel='stylesheet' type='text/css'>
    <!--[if lt IE 9]>
      <script src='/javascripts/html5shiv.js'></script>
    <![endif]-->
    <link href='images/favicon.png' rel='shortcut icon'>
  </head>
  <body>
    <div id='wrap'>
      <div class='navbar navbar-fixed-top'>
        <div class='navbar-inner'>
          <div class='container'>
            <button class='btn btn-navbar' data_target='.nav-collapse' data_toggle='collapse' type='button'>
              <span class='icon-bar'></span>
              <span class='icon-bar'></span>
              <span class='icon-bar'></span>
            </button>
            <a class='brand' href='/'>RVM::FW</a>
            <div class='nav-collapse collapse'>
              <ul class='nav'>
                <li>
                  <a href='/files'>Rubies</a>
                </li>
                <li>
                  <a href='/db'>DB</a>
                </li>
                <li>
                  <a href='/known'>Known</a>
                </li>
              </ul>
            </div>
          </div>
        </div>
      </div>
      <div class='container'>
        <header>
          <h1 class='title'>RVM::FW</h1>
          <h2 class='description'>Exposing hidden Rubies for firewalled RVMs</h2>
        </header>
        <article>
          <h2>You've dug in the wrong spot - there are no rubies here</h2>
          <p>
            Keep digging though! The treasure has to be somewhere!
          </p>
        </article>
      </div>
      <div id='push'></div>
    </div>
    <footer id='footer'>
      <div class='container'>
        <p>
          <a href='https://github.com/stevenhaddox/rvm_fw'>Fork RVM::FW on GitHub</a>
        </p>
      </div>
    </footer>
    <script src='/javascripts/jquery-1.9.1.min.js'></script>
    <script src='/javascripts/bootstrap-collapse.js'></script>
  </body>
</html>

Should http://rvm-fw.herokuapp.com/releases/stable-version.txt return rvm-1.18.14 instead of 1.18.14?

stevenhaddox commented 10 years ago

@adamonduty thanks for the detailed error, unfortunately RVM::FW can't run on Heroku due to files having to be part of the code repository. Adding Ruby binaries to the git repository makes the git repo insanely huge, especially with frequent changes between all the versions of Ruby and the various Ruby variants.

You can see more details about this at: https://github.com/stevenhaddox/rvm_fw/issues/21

In order to support Rubies, RVM, packages, etc. within Heroku I'd have to modify RVM::FW to support an external data source beyond the server it's hosted on (like S3). This goes against any practical application of RVM::FW that I've seen thus far and just feels like wasted cycles. If you do want to test RVM::FW I have a non-official, unsupported instance of it running from a box at home that I'm using for my Ansible provisioning scripts to run against at:

http://rvm-fw.slkdemos.com

adamonduty commented 10 years ago

Ah, right. I suppose I should read the setup instructions in more detail. At least I'm not the only one that was confused that the heroku instance doesn't work.

Makes me wonder though: have you considered serving rvm::fw entirely through static files? That would be easier to setup for admins (no need for a ruby app server), and a quick glance through the code doesn't make me think major features rely on dynamic evaluation. It would be awesome to simply untar the rvm::fw release including all the latest packaged rubies, dependencies, etc and throw it up on a corporate web server (or s3 or whatever).

Of course the static site generation would still require ruby.

stevenhaddox commented 10 years ago

@adamonduty I haven't considered it, I actually want to make it more dynamic (see issues: https://github.com/stevenhaddox/rvm_fw/issues/20, https://github.com/stevenhaddox/rvm_fw/issues/15, and already dynamically in use in the db view: https://github.com/stevenhaddox/rvm_fw/blob/master/views/db.erb).

I'm fairly opposed to this idea. I think it's important that the host, port, and protocol are all properly rendered and those are hard to ensure without it getting it from the server. Sure I can set it up as a Jekyll site and have a var for the domain and then statically create all the files, but what about when the files move to a new server (as mine will do within a month or two)? Someone has to be able to install Jekyll somewhere manually and they also have to have Ruby installed in order to do that. If they can do that they can run this as a simple sinatra app (1.8.7+ all work with it).

Meanwhile, making it more dynamic reduces issues in ensuring that the latest ruby available on the file-system is actually used as the default in the db and known views and will allow things like rvm install 1.9.3 to automatically grab the highest patch available on the server.

Just my thoughts on it thus far. If people are wanting to manually manage an HTML site with links to rubies they can just package up a bunch of rubies and run an Apache index listing on it really. No Ruby required whatsoever and it works fine with chruby, rbenv, etc. RVM::FW is looking to allow one capable Rubyist that can either get a package ruby installed via root / ticket or can install any version of Ruby from source to be able to setup a tool that will self-correct and self-update long-term to enable many more Rubyists to skip the hassle of what the first person had to go through. That's the intent and I'd like to try to continue down the path of getting it closer and closer to that in the future.

Sorry if this seems harsh, just one of the things I hold as a strong opinion about it's purpose ;)

stevenhaddox commented 10 years ago

@adamonduty Oh, and a huge part of the reason I'm creating the SUPPORT project and ansible_rails_enterprise provisioner is to allow people with minimal to no experience as sysadmins to be able to stand up a server with tons of open source tools that work properly out of the box with only a few config files. Ansible Rails Enterprise is already 100% functional (although it needs a DB section to be fully safe) and there's lots of low-hanging fruit for improvement. But most anyone could download the src files needed for it, deploy those to an ansible control machine (python 2.6+ w/ four modules), customzie the config files, and literally have a rack capable server w/ Passenger & Apache from source to host RVM::FW within an hour.

stevenhaddox commented 10 years ago

@adamonduty PS - Please don't take these the wrong way. I sincerely appreciate the suggestions and welcome all ideas.

adamonduty commented 10 years ago

Oh no worries. I'm just suggesting stuff, its okay if you don't agree with it 100%. Not offended at all.

important that the host, port, and protocol are all properly rendered

Relative links should work on the browser-facing portions, and server-side includes on the db files. Or specifying the host/port/protocol in the config prior to static-site generation. I just don't see that as a dealbreaker, even if servers are moved.

latest ruby available on the file-system

I agree this would be difficult without some sort of server-side rendering.

host RVM::FW within an hour

But using a static file strategy would allow hosting in under 1 minute on a pre-existing apache or nginx infrastructure. :) And would allow more flexible hosting. I agree your SUPPORT package is valuable, I just don't see it as a requirement for a functioning rvm::fw.

manually manage an HTML site

This isn't what I mean. I'm saying to run the bootstrap on a ruby-capable machine, then provide a "release" that simply gets uploaded to the web server. Rubies included. Want to provide new rubies? Re-run the bootstrap, re-upload the release. Functionally, rvm::fw works the same.

Does standard rvm require running a ruby process?

I suppose if I really wanted to see this, I would send a pull request.

stevenhaddox commented 10 years ago

@adamonduty I get what you're saying. I just don't see having a working version of Ruby in order to run RVM::FW as an issue? Any server that RVM::FW is going to be running on would 99% chance be likely to be needing to host at least one other rack app I'd imagine. If so then they're going to need Ruby on that box anyway?

It's not that I'm necessarily opposed to this, but in my environments I'd honestly have to setup Ruby on my box either way (to either run Jekyll and generate the static HTML, or to deploy RVM::FW as a rack Sinatra app). I don't have a working version of Ruby on Windows or a box that isn't hosting at least one other Rack app and never have so I haven't seen needing rack support to be an issue that needed to be overcome I suppose.

If I can be sold that there are more problems being solved than what this prevents from being done (dynamic Ruby version detection for example based on the config) then I'm open to considering it. That said, I'm not exactly jumping at the bone to do a full rewrite of a product that seems to work in every scenario desired so far... I'd be much more inclined to accept a pull request for the ability to specify a different <%= HOST %> value for /db output to allow hosting of Rubies in an external location for example ;)

stevenhaddox commented 10 years ago

Relative links should work on the browser-facing portions, and server-side includes on the db files. Or specifying the host/port/protocol in the config prior to static-site generation. I just don't see that as a dealbreaker, even if servers are moved.

@adamonduty also, don't forget that "relative" links are great for client side, but not for the "/db" view. I really prefer those being dynamic as one of the ease of use features of RVM::FW. When I left a customer and someone else took over / moved / stood up another RVM::FW instance there were no headaches of having to regenerate / be aware of the "/db" view needing to be modified beyond setting it up to work with the rubies they supported in their instance. Just something else to keep in mind ;)

adamonduty commented 10 years ago

Yeah I think we're just trying to optimize for different use cases. I personally don't care about having to run a ruby process or not. My experience with trying to hand a ruby project over to a full-time sysadmin was that fewer moving parts was better. Fully repeatable installs are also crucial. The admin may or may not have ansible as a tool in their toolbox. Mine was tied to puppet, and my first working solution was basically thrown out because it didn't meet his criteria.

Plus, static files would reduce the disparity between your internet environment and your isolated environment.

no headaches of having to regenerate / be aware of the "/db" view

Server-side includes would do the same :)

I'm happy to drop this, was just a casual idea turned into a long discussion :)

stevenhaddox commented 10 years ago

@adamonduty not a problem. I like the idea of a statically generated version of the site, but I don't want to give up the dynamic capabilities I'm already using and plan to use more in the future... Perhaps we can make an "export" feature that just downloads the three or four views and runs a simple sed command to replace URLs?

stevenhaddox / rvm_fw

Heroku instance missing stable version tar #24