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.

[cheeseplus]

Linking this related mixlib-install issue as if the checksums were being checked then we'd blow up earlier at least chef/mixlib-install#238

[gravitystorm]

I've run into this issue (and not for the first time, over the years). I'd like to add support for the per-platform-version caching suggested by @cheeseplus in #293 (comment) since this would resolve the problem for me too.

I also noticed the checksum stuff isn't working, and I tried investigating why, but I couldn't figure it out after a few hours of trying.

However, fixing the checksums without fixing the cache layout would actually cause more issues. The workaround for the lack of per-platform-version caching is to run test-kitchen against the oldest OS you want to support (e.g. ubuntu-20.04), and then you will have successfully prepared your cache with a package that is reasonably likely to also work on newer versions too (e.g. ubuntu-22.04). But if the checksum issue is fixed first, you would repeatedly overwrite the package in your cache, and will forever be re-downloading the different per-platform-version packages every time you test with a different OS!