[vcap-dev] Pushing ruby app to V2 cloud - Error, no such file ruby_versions.yml

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

reply | permalink

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

reply | permalink

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

reply | permalink

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

reply | permalink

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

reply | permalink

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

reply | permalink

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

reply | permalink

group	vcap-dev @
posted	Mar 20, '13 at 7:21p
active	Apr 22, '13 at 9:10p
posts	8
users	3

responses	expanded	Hotkey: s
font	variable	Hotkey: f
user style	avatars	Hotkey: a

[vcap-dev] Pushing ruby app to V2 cloud - Error, no such file ruby_versions.yml

Search Discussions

Related Discussions

3 users in discussion