FAQ
I have a hand-crafted V2 installation to which I am trying to push a ruby
app. It is correctly identified as a ruby app as it reports that it is
"Installing ruby." but then the following in thrown:

Installing ruby.

/usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or directory
- ruby_versions.yml (Errno::ENOENT)

from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
`block (2 levels) in ruby_versions'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
`chdir'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
`block in ruby_versions'

from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
`ruby_versions'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
`install_ruby'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
`compile'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
`block in <main>'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
`log'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
`<main>'

/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
`compile': Buildpack compilation step failed: (RuntimeError)

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
`block in stage_application'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
`chdir'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
`stage_application'

from
/home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


A bit deeper in the debugging and I find that after looking in the
buildpack cache and in the blobstore it tries to
curl https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
think the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
at that URL seem to have been successful.


Any ideas?


Thanks,

Cornelia

Search Discussions

  • James Bayer at Mar 25, 2013 at 1:54 pm
    I missed this post last week, I'll have the team working on buildpacks take
    a look.

    It looks like we require a ruby_versions.yml file to be in the blob store
    and perhaps your blob store does not have one?
    https://github.com/cloudfoundry/heroku-buildpack-ruby/blob/master/lib/language_pack/ruby.rb#L192

    Until we get an answer, one thing you could do to troubleshoot is fork this
    buildpack, make some mods for additional debugging, logging, or hardcode
    the ruby binaries s3 url you want to use.
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Matthew Boedicker at Mar 26, 2013 at 12:08 am
    In lib/language_pack/package_fetcher.rb it tries the buildpack cache, the
    blobstore and then S3 in that order. If you could put some debug in those
    methods and figure out where it fails, it might be a bug or an error that
    could be handled better.
    On Monday, March 25, 2013 6:54:35 AM UTC-7, James Bayer wrote:

    I missed this post last week, I'll have the team working on buildpacks
    take a look.

    It looks like we require a ruby_versions.yml file to be in the blob store
    and perhaps your blob store does not have one?

    https://github.com/cloudfoundry/heroku-buildpack-ruby/blob/master/lib/language_pack/ruby.rb#L192

    Until we get an answer, one thing you could do to troubleshoot is fork
    this buildpack, make some mods for additional debugging, logging, or
    hardcode the ruby binaries s3 url you want to use.
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Cornelia Davis at Apr 16, 2013 at 4:43 am
    And here I am few weeks later, after a bit of vaca and then this challenge
    (https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/8GoLbq90xeY),
    I am still struggling with this. I was able to find the code where it
    looks in the cache, blobstore and then on s3 and doesn't find it in any of
    those locations. And yes, I'm thinking about putting it into the blobstore
    or my own S3 location I believe the issue is that I don't seem to be able
    to get out of my warden container over the network. I don't have any dns
    resolution and I cannot even access a machine via IP address.

    Is there some configuration that I need to set to allow outbound networking
    from the warden container?

    Thanks,
    Cornelia

    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Cornelia Davis at Apr 16, 2013 at 4:49 am
    And here I am few weeks later, after a bit of vaca and then this challenge (
    https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/8GoLbq90xeY),
    I am still struggling with this. I was able to find the code where it
    looks in the cache, blobstore and then on s3 and doesn't find it in any of
    those locations. And yes, I'm thinking about putting it into the blobstore
    or my own S3 location I believe the real issue is that I don't seem to be
    getting any dns resolution from within the warden container.

    Is there some configuration that I need to set to allow the warden
    container access to dns resolution?

    Thanks,
    Cornelia
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Matthew Boedicker at Apr 16, 2013 at 3:47 pm
    What does /etc/resolv.conf inside the container look like? The
    container should get the same resolv.conf as the host is it running
    on. Does DNS resolution work from the host?

    On Mon, Apr 15, 2013 at 9:49 PM, Cornelia Davis
    wrote:
    And here I am few weeks later, after a bit of vaca and then this challenge
    (https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/8GoLbq90xeY),
    I am still struggling with this. I was able to find the code where it looks
    in the cache, blobstore and then on s3 and doesn't find it in any of those
    locations. And yes, I'm thinking about putting it into the blobstore or my
    own S3 location I believe the real issue is that I don't seem to be getting
    any dns resolution from within the warden container.

    Is there some configuration that I need to set to allow the warden container
    access to dns resolution?


    Thanks,
    Cornelia
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in `block
    in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I think
    the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz at
    that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Cornelia Davis at Apr 16, 2013 at 5:54 pm
    I think the issue is in the way my VM is configured.

    So yes, the resolv.conf in the container exactly matched that of the host
    (the host being a VMWare workstation guest) as follows:

    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
    resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.0.1
    search localdomain

    And then I found this post<https://github.com/cloudfoundry/warden/commit/8461f4758f9899f7aa58a13b22be7afabf19ee55>which indicates that if the host has the nameserver set to localhost that
    the warden container resolv.conf nameserver should be set to the
    $network_host_ip. What I now don't understand is, this network host ip,
    does that server need to be set up to proxy to a DNS server? Cloudfoundry
    doesn't stand up a nameserver does it?

    And, finally, I suspect that the configuration of my virtual machine on
    which I am running all of this is having an impact. As you can see above,
    my VM guest, which is my warden host, is set up with a nameserver 127.0.0.1
    which I'm betting means it lets the VM guest proxy to an actual DNS server
    via VMWorkstation. Is there something I need to configure a particular way
    in my VMWare Workstation/VM Guest? I'm trying different settings now -
    bridged/nats with different settings but no joy yet.

    Thanks, Cornelia
    On Tuesday, April 16, 2013 8:47:04 AM UTC-7, Matthew Boedicker wrote:

    What does /etc/resolv.conf inside the container look like? The
    container should get the same resolv.conf as the host is it running
    on. Does DNS resolution work from the host?

    On Mon, Apr 15, 2013 at 9:49 PM, Cornelia Davis
    <corneli...@gmail.com <javascript:>> wrote:
    And here I am few weeks later, after a bit of vaca and then this challenge
    (
    https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/8GoLbq90xeY),
    I am still struggling with this. I was able to find the code where it looks
    in the cache, blobstore and then on s3 and doesn't find it in any of those
    locations. And yes, I'm thinking about putting it into the blobstore or my
    own S3 location I believe the real issue is that I don't seem to be getting
    any dns resolution from within the warden container.

    Is there some configuration that I need to set to allow the warden container
    access to dns resolution?


    Thanks,
    Cornelia
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a
    ruby
    app. It is correctly identified as a ruby app as it reports that it is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block
    in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think
    the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at
    that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia
  • Cornelia Davis at Apr 22, 2013 at 9:10 pm
    In a hallway conversation I had with Jesse Zhang, he suggested the reason
    for the DNS behavior I describe here was that I was running Ubuntu DESKTOP,
    instead of server and that the Network Manager of desktop is responsible
    for proxying the DNS requests... well he was absolutely right! I just
    redid my minimal V2 cloud foundry install on Ubuntu 12.04 SERVER and the
    resolv.conf does not have 127.0.0.1 as the nameserver, instead it has a
    non-local IP address. The warden containers, which inherit the
    resolve.conf from the machine running the dea can then do name resolution
    as needed during the staging process and I'm all set.

    Thanks Jesse!
    On Tuesday, April 16, 2013 10:54:37 AM UTC-7, Cornelia Davis wrote:

    I think the issue is in the way my VM is configured.

    So yes, the resolv.conf in the container exactly matched that of the host
    (the host being a VMWare workstation guest) as follows:

    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
    resolvconf(8)
    # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 127.0.0.1
    search localdomain

    And then I found this post<https://github.com/cloudfoundry/warden/commit/8461f4758f9899f7aa58a13b22be7afabf19ee55>which indicates that if the host has the nameserver set to localhost that
    the warden container resolv.conf nameserver should be set to the
    $network_host_ip. What I now don't understand is, this network host ip,
    does that server need to be set up to proxy to a DNS server? Cloudfoundry
    doesn't stand up a nameserver does it?

    And, finally, I suspect that the configuration of my virtual machine on
    which I am running all of this is having an impact. As you can see above,
    my VM guest, which is my warden host, is set up with a nameserver 127.0.0.1
    which I'm betting means it lets the VM guest proxy to an actual DNS server
    via VMWorkstation. Is there something I need to configure a particular way
    in my VMWare Workstation/VM Guest? I'm trying different settings now -
    bridged/nats with different settings but no joy yet.

    Thanks, Cornelia
    On Tuesday, April 16, 2013 8:47:04 AM UTC-7, Matthew Boedicker wrote:

    What does /etc/resolv.conf inside the container look like? The
    container should get the same resolv.conf as the host is it running
    on. Does DNS resolution work from the host?

    On Mon, Apr 15, 2013 at 9:49 PM, Cornelia Davis
    wrote:
    And here I am few weeks later, after a bit of vaca and then this challenge
    (
    https://groups.google.com/a/cloudfoundry.org/forum/#!topic/vcap-dev/8GoLbq90xeY),
    I am still struggling with this. I was able to find the code where it looks
    in the cache, blobstore and then on s3 and doesn't find it in any of those
    locations. And yes, I'm thinking about putting it into the blobstore or my
    own S3 location I believe the real issue is that I don't seem to be getting
    any dns resolution from within the warden container.

    Is there some configuration that I need to set to allow the warden container
    access to dns resolution?


    Thanks,
    Cornelia
    On Wednesday, March 20, 2013 12:21:02 PM UTC-7, Cornelia Davis wrote:

    I have a hand-crafted V2 installation to which I am trying to push a
    ruby
    app. It is correctly identified as a ruby app as it reports that it
    is
    "Installing ruby." but then the following in thrown:

    Installing ruby.

    /usr/lib/ruby/1.9.1/psych.rb:297:in `initialize': No such file or
    directory - ruby_versions.yml (Errno::ENOENT)

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `open'

    from /usr/lib/ruby/1.9.1/psych.rb:297:in `load_file'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:192:in
    `block (2 levels) in ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:190:in
    `block in ruby_versions'

    from /usr/lib/ruby/1.9.1/tmpdir.rb:83:in `mktmpdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:189:in
    `ruby_versions'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:235:in
    `install_ruby'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/ruby.rb:77:in
    `compile'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:11:in
    `block in <main>'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/lib/language_pack/base.rb:84:in
    `log'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/vendor/ruby/bin/compile:10:in
    `<main>'

    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/installer.rb:17:in
    `compile': Buildpack compilation step failed: (RuntimeError)

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:15:in
    `block
    in stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `chdir'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/lib/buildpack.rb:11:in
    `stage_application'

    from
    /home/cdavisafc/cloud-fabric/dea_ng/buildpacks/bin/run:10:in `<main>'


    A bit deeper in the debugging and I find that after looking in the
    buildpack cache and in the blobstore it tries to curl
    https://s3.amazonaws.com/heroku-buildpack-ruby/ruby_versions.yml. I
    think
    the S3 bucket is accessible as prior attents to get bundler-1.3.2.tgz
    at
    that URL seem to have been successful.


    Any ideas?


    Thanks,

    Cornelia

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupvcap-dev @
postedMar 20, '13 at 7:21p
activeApr 22, '13 at 9:10p
posts8
users3

People

Translate

site design / logo © 2021 Grokbase