Skip to content
This repository has been archived by the owner on Dec 26, 2017. It is now read-only.

Cooboks not updated on VM after Berksfile changed #284

Open
chris-orchard opened this issue May 29, 2015 · 2 comments
Open

Cooboks not updated on VM after Berksfile changed #284

chris-orchard opened this issue May 29, 2015 · 2 comments

Comments

@chris-orchard
Copy link

I'm having a possibly related problem with rsync to the issue in #281

The first time I run vagrant provision the cookbooks are synced across:

==> default: Loading Berkshelf datafile...
==> default: Sharing cookbooks with VM
==> default: Updating Vagrant's Berkshelf...
==> default: Resolving cookbook dependencies...
# list of fetched dependencies
==> default: Rsyncing folder: /home/myuser/.berkshelf/vagrant-berkshelf/shelves/berkshelf20150529-21352-tc8cd9-default/ => /vagrant-berkshelf/b1225f2b7fd27dadf
26203ebfc6de168/cookbooks

Then if I change the ./Berksfile to include extra cookbooks then run vagrant provision again the new dependencies are fetched on my local machine, but rsync does not run so they are missing on the remote machine.

==> default: Loading Berkshelf datafile...
==> default: Sharing cookbooks with VM
==> default: Updating Vagrant's Berkshelf...
==> default: Resolving cookbook dependencies...
# list of fetched dependencies

Looks like something makes the plugin not re-sync the cookbooks after the first time.

If I vagrant destroy and vagrant up again it copies them across.

Interestingly if I change the chef.provisioning_path = "/vagrant-berkshelf" line in the chef-solo block of the Vagrantfile to a different path, say chef.provisioning_path = "/vagrant-berkshelf-2" then it does sync new cookbook dependencies across. So it looks like it might be checking for something on the vm which makes it think it's up to date even if there are new cookbok dependencies in the local shelf that should be synced.

==> default: Loading Berkshelf datafile...
==> default: Sharing cookbooks with VM
==> default: Updating Vagrant's Berkshelf...
==> default: Resolving cookbook dependencies...
# list of fetched dependencies
==> default: Rsyncing folder: /home/myuser/.berkshelf/vagrant-berkshelf/shelves/berkshelf20150529-21352-tc8cd9-default/ => /vagrant-berkshelf2/b1225f2b7fd27dad
f26203ebfc6de168/cookbooks
@yoshiwaan
Copy link

I think this is the same problem as #281

What I've found is that when running vagrant provision on an instance that rsyncs folders instead of mounting them only the /vagrant data folder is rsynced. This isn't particularly helpful for chef/berkshelf as the cookbooks are stored in /tmp/vagrant-chef//cookbooks.

Looking at the synced_folders file for the machine in .vagrant/machines/default//synced_folders you'll see that there is a link from the local shelf for the box to the directory on the box, so running vagrant rsync will actually sync the cookbooks correctly if the local shelf is up to date.

The hack I worked out to get it working was to run vagrant provision up until the cookbook dependencies are finished updating then CTRL+C it to cancel, then run vagrant rsync && vagrant provision

You may need to run a berks install or berks update before running the first vagrant provision as the cookbooks are sourced from your berkshelf.

This was enough of a problem to make me switch to test kitchen, which works perfectly.

The way I see it there are 3 ways to fix the problems, none of which are perfect:

  • vagrant-berkshelf calls a vagrant rsync when vagrant provision is run
  • The providers themselves have to work out how to play nicely with vagrant-berkshelf so that the directory gets synced when running provision
  • vagrant adds a --rsync flag to the provision operation that syncs all directories in the synced_folders file just after the /vagrant directory is synced

@yoshiwaan
Copy link

I just added the above ticket to base vagrant. Maybe one way of fixing the problem will get put in.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants