`bosh create-release --tarball` on CPI compiles on workstation but results in `Cannot open: No such file or directory` on director about bosh-cli HOT 9 CLOSED

@cppforlife If you are interested in closing this issue, you can update bosh-utils with this PR cloudfoundry/bosh-utils#22

from bosh-cli.

Hi.

Thank you for submitting this issue. The new BOSH CLI fixes the problem by providing the reset-release command. Here is a sample output:

ubuntu@ip-10-0-0-43:~/workspace/zookeeper-release$ gobosh create-release --force
Bailing because symlinks found in blobs directory. If switching from CLI v1, please use the `reset-release` command.

Exit code 1

Please let us know if you have additional concerns. I will close the issue for now.

from bosh-cli.

mind doing a little bit of digging to find out why this is the case?

Sent from my iPhone

On Oct 10, 2016, at 1:32 PM, Lyle Franklin [email protected] wrote:

Steps to replicate

Compile a dev release of CPI: cd bosh-vsphere-cpi && bosh create-release --tarball
Attempt to deploy director with CPI
See that CPI compiles fine on workstation, but fails to compile on director as the blobs are missing from the package directory
We've seen this with both the vSphere CPI and GCP CPI. The deployment succeeds when we use the Ruby CLI to create the CPI release tarball.

Example output:

○ → bosh create-env director.yml
Deployment manifest: '/Users/pivotal/scratch/vsphere/director.yml'
Deployment state: '/Users/pivotal/scratch/vsphere/director-state.json'

Started validating
Downloading release 'bosh'... Finished (00:01:14)
Validating release 'bosh'... Finished (00:00:00)
Validating release 'bosh-vsphere-cpi'... Finished (00:00:00)
Validating cpi release... Finished (00:00:00)
Validating deployment manifest... Finished (00:00:00)
Validating stemcell... Finished (00:00:00)
Finished validating (00:01:15)

Started installing CPI
Compiling package 'vsphere_cpi_ruby/c39b855dc291d73e81e5a1f5056d04cf8cce14d3'... Finished (00:01:28)
Compiling package 'vsphere_cpi_mkisofs/3d6f6e0f450164637b2cd5b8aa1daf0ecde2f261'... Finished (00:02:38)
Compiling package 'vsphere_cpi/31f7c234a64e0e5c7bd8577829bc887c0e8dc70b'... Finished (00:00:42)
Installing packages... Finished (00:00:00)
Rendering job templates... Finished (00:00:00)
Installing job 'vsphere_cpi'... Finished (00:00:00)
Finished installing CPI (00:04:49)

Starting registry... Finished (00:00:00)
Uploading stemcell 'bosh-vsphere-esxi-ubuntu-trusty-go_agent/3263.5'... Finished (00:00:34)

Started deploying
Creating VM for instance 'bosh/0' from stemcell 'sc-13ba804b-0b95-4e2e-a22f-0efe82055e95'... Finished (00:00:13)
Waiting for the agent on VM 'vm-c2b1bdfe-6e35-4999-b3b6-823914ab7b96' to be ready... Finished (00:00:43)
Creating disk... Finished (00:00:03)
Attaching disk 'disk-5ac782be-43c4-4ae0-b83e-ec3bad70e454' to VM 'vm-c2b1bdfe-6e35-4999-b3b6-823914ab7b96'... Finished (00:00:16)
Rendering job templates... Finished (00:00:02)
Compiling package 'ruby/589d4b05b422ac6c92ee7094fc2a402db1f2d731'... Skipped Package already compiled
Compiling package 's3cli/b4e17d94eedc5c08978be29d1142b84f6d7bd0c2'... Skipped Package already compiled
Compiling package 'mysql/b7e73acc0bfe05f1c6cbfd97bf92d39b0d3155d5'... Skipped Package already compiled
Compiling package 'libpq/09c8f60b87c9bd41b37b0f62159c9d77163f52b8'... Skipped Package already compiled
Compiling package 'vsphere_cpi_ruby/c39b855dc291d73e81e5a1f5056d04cf8cce14d3'... Failed (00:00:11)
Failed deploying (00:01:30)

Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Deploying:
Building state for instance 'bosh/0':
Compiling job package dependencies for instance 'bosh/0':
Compiling job package dependencies:
Remotely compiling package 'vsphere_cpi_ruby' with the agent:
Sending 'compile_package' to the agent:
Sending 'get_task' to the agent:
Agent responded with error: Action Failed get_task: Task fb56487b-739a-473d-44f7-8cf475a82bea result: Compiling package vsphere_cpi_ruby: Running packaging script: Running packaging script: Command exited with 2; Stdout: , Stderr: ++ PATH=/usr/local/opt/openssl/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
++ openssl version

• openssl_version='OpenSSL 1.0.1f 6 Jan 2014'
  ++ echo OpenSSL 1.0.1f 6 Jan 2014
  ++ cut -f2 '-d '
  ++ cut -f1 -d.
• openssl_major_version=1
• '[' 1 == 0 ']'
• echo 'Installing yaml'
• tar xzf vsphere_cpi_ruby/yaml-0.1.5.tar.gz
  tar (child): vsphere_cpi_ruby/yaml-0.1.5.tar.gz: Cannot open: No such file or directory
  tar (child): Error is not recoverable: exiting now
  tar: Child returned status 2
  tar: Error is not recoverable: exiting now

Exit code 1
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from bosh-cli.

@cppforlife It would be our pleasure to do additional digging to find out why this is the case.

It appears the release tarball contains package tarballs. The package tarballs, in the broken Golang CLI case, consist of symbolic links (which work fine on the local workstation, but not on the compilation vm):

mkdir /tmp/1
cd /tmp/1
 # untar broken release
tar xvf ~/workspace/bosh-vsphere-cpi-release/dev_releases/bosh-vsphere-cpi/bosh-vsphere-cpi-28+dev.2.tgz
cd packages/
mkdir ruby
cd ruby
 # untar package blobs
tar xzvf ../vsphere_cpi_ruby.tgz
ls -al vsphere_cpi_ruby/
ls -l vsphere_cpi_ruby/
total 32
lrwxr-xr-x  1 pivotal  wheel  97 Sep  9 14:33 bundler-1.11.2.gem -> /Users/pivotal/workspace/bosh-vsphere-cpi-release/.blobs/8eb956dec72da753d3d2a2126c78508b17af434e
lrwxr-xr-x  1 pivotal  wheel  97 Sep  9 14:33 ruby-2.2.4.tar.gz -> /Users/pivotal/workspace/bosh-vsphere-cpi-release/.blobs/818e5e157f76d4912ba3a7c7b4fc5156105e83c3
lrwxr-xr-x  1 pivotal  wheel  97 Sep  9 14:33 rubygems-2.6.2.tgz -> /Users/pivotal/workspace/bosh-vsphere-cpi-release/.blobs/5960628b1f90f4a05ed69c0ad59c59cb10b79e5f
lrwxr-xr-x  1 pivotal  wheel  97 Sep  9 14:33 yaml-0.1.5.tar.gz -> /Users/pivotal/workspace/bosh-vsphere-cpi-release/.blobs/8b78cb9f759c7d80db8a7328c0ebecfe34fde737

from bosh-cli.

Sounds like @zaksoup and @DennisDenuto will take it from here

from bosh-cli.

@ljfranklin based on your output i have a feeling you ran into the case of old cli vs new cli. if you rm -rf .blobs and blobs directory in your release directory and run bosh create-release again it should work.

from bosh-cli.

@cppforlife removing the .blobs directory did fix it. Can you add a story for the CLI to automatically scrub that directory if it's in the old symlink format? This is going to be a pretty common migration path once people switch to the new CLI. @cunnie also hit this problem twice.

from bosh-cli.

@ljfranklin any good ideas how to detect the problem? check directory for symlinks?

from bosh-cli.

@cppforlife apparently the tar cli support a --dereference option that automatically follows symlinks: http://www.gnu.org/software/tar/manual/html_node/dereference.html. That sounds ideal if whatever tar library the CLI uses supports it. If not, maybe clear out the .blobs dir if it contains symlinks.

from bosh-cli.