Cache directory should be structured

[cheeseplus]

The caching feature pulls down installers to ~/.kitchen/cache/ and if they are named the same, as chef_12.19.36-1_amd64.deb for all Debian/Ubuntu builds, there doesn't appear to be any validation that it's the correct build for the platform.

1. Converge a ubuntu-16.04 suite
2. Ensure installer is cached to ~/.kitchen/cache
3. Converge a debian-7 suite

       Installing chef
       installing with dpkg...
       Selecting previously unselected package chef.
(Reading database ... 27468 files and directories currently installed.)
       Unpacking chef (from .../chef_12.19.36-1_amd64.deb) ...
       Setting up chef (12.19.36-1) ...
       Thank you for installing Chef!
       Transferring files to <default-debian-711>
       /opt/chef/embedded/bin/ruby: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /opt/chef/embedded/lib/libruby.so.2.3)

[tduffield]

Pinging @afiune

[afiune]

🤔 I might not be remembering correctly, but it should verify the SHA of the package. If not, then totally a bug.

I will try to look into this tomorrow morning.

[cheeseplus]

The logging says it's checking the SHA but it's definitely broken or lying.

[cheeseplus]

Edited the title for this one to track re-working the cache to be structured a la:

├── debian-7
│   └── chef_12.19.36-1_amd64.deb
├── el-6
│   └── chef-12.19.36-1.el6.x86_64.rpm
└── ubuntu-16.04
    ├── chef_12.18.31-1_amd64.deb
    └── chef_12.19.36-1_amd64.deb 

We also need to ensure we are checking checksums as that isn't happening (though it appears to from the output)

[afiune]

I think it is not possible to control the directory structure from within the driver since itself (the driver) just controls the state of the "kitchen" (so to speak). That means we do not know anything about the internals of the VM, the only things you can access are stored in the instance.platform object, but that just gives you so little information that may or may not be accurate for this implementation.

[5] pry(#<Kitchen::Driver::Vagrant>)> cd instance.platform
[6] pry(#<Kitchen::Platform>):1> ls
Kitchen::Platform#methods: diagnose  name  os_type  shell_type  windows?
self.methods: __pry__
instance variables: @name  @os_type  @shell_type
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_

I think we should continue sharing the base cache directory: .kitchen/cache but inside core test-kitchen when we download the package we could have a directory structure function (PS & SH) that runs inside the kitchen. At that time we could create the desired structure that will be persistent since the directory has been shared.

IMHO this is getting a bit heary 😅 because we are kinda making a hard dependency between the driver(sharing mechanism) and the core of test-kitchen. But I have no other idea, so I am open to suggestions.

Thoughts? @cheeseplus @schisamo @tas50 @tduffield

[cheeseplus]

I've been thinking on this one and am struggling to come up with better options. Right now this only bites us in edge cases but also is super unexpected in the case of Debian 7.