Don't use file_cache_path for rsyncing provision

[skyeagle]

The rsync command use --delete option which deletes all files which are not in local machine. It is wrong behaviour because file_cache_path contains data created by chef under sudo and it maybe used by him later. It looks similar to this log output at the moment:

...
rsync: delete_file: rmdir(nginx-1.2.3/objs/src/os/win32) failed: Permission denied (13)
rsync: delete_file: unlink(nginx-1.2.3/objs/src/os/unix/ngx_writev_chain.o) failed: Permission denied (13)
rsync: delete_file: unlink(nginx-1.2.3/objs/src/os/unix/ngx_user.o) failed: Permission denied (13)
rsync: delete_file: unlink(nginx-1.2.3/objs/src/os/unix/ngx_udp_recv.o) failed: Permission denied (13)
...

It would be better use strict paths(cookbooks, data_bags, nodes, roles, encrypted_data_bag_secret) defined in Chef config.

[matschaffer]

Agreed. This is a behavior I wasn't aware of until recently. I'm inclined to say that using the file_cache_path for storage of the repo is the wrong move and we should just separate the concerns.

[matschaffer]

I wonder if we could use or create a new var in solo.rb to dictate where the kitchen should be transfered to without upsetting the chef-solo run itself.

[skyeagle]

Wouldn't be the knife.rb better for this var?

[skyeagle]

Sorry for that mistaken opinion.

[matschaffer]

The knife.rb param isn't bad I don't think. We'd just want to make this obvious for people just coming into the project. If we go that route it might also make sense to generate solo.rb when you run knife cook.

[matschaffer]

Should be fixed with #145

[tmatilai]

Fixed by #199