Allow a user to specify a specific platform/architecture to use

[nrocco]

Description

This is a draft/work-in-process proof of concept to address the idea mentioned in #268

It allows users to specify either the following in a global config file.

---
driver:
  platform: linux/amd64

or the following under a specific platform

platforms:
  - name: ubuntu-20.04
    driver:
      image: dokken/ubuntu-20.04
      platform: linux/amd64

Issues Resolved

#268

Type of Change

Our release process assumes you are using Conventional Commit messages.

The most important prefixes you should have in mind are:

• _fix_: which represents bug fixes, and correlates to a SemVer patch.
• _feat_: which represents a new feature, and correlates to a SemVer minor.
• _feat!_:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a major version change.

If you have not included a conventional commit message this can be fixed on merge.

Check List

• [ ] New functionality includes tests
• [ ] All tests pass
• [ ] Commit message includes a Conventional Commit Message

[koldrid]

This would be great. We have this same problem. Right now we are making our own versions of the dokken images for RHEL and Chef to make sure only X86 is available.

[eheydrick]

Just tested this out and it works though I did run into an issue with the chef image having the wrong arch. If there's an existing chef image for the chef_version it'll use that instead of the amd64 one, causing the test-kitchen run to fail.

My kitchen.yml has:

driver:
  name: dokken
  chef_version: 17
  privileged: true
  platform: linux/amd64

It's correctly creating an amd64 container but chef is still arm64:

root@dokken:/# arch 
x86_64
root@dokken:# file /opt/chef/embedded/bin/ruby
/opt/chef/embedded/bin/ruby: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=89f928045bfb54ec141612a3d30897471c9a86ef, with debug_info, not stripped

And the test-kitchen run fails:

       Preparing validation.pem
       Preparing client.rb
       sh: 3: /opt/chef/bin/chef-client: not found
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: 1 actions failed.
>>>>>>     Converge failed on instance <web-debian-10>.  Please see .kitchen/logs/web-debian-10.log for more details
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Seems like it's caching the arm64 image somewhere?

If I set chef_version to a version that I haven't pulled before it works.

driver:
  name: dokken
  chef_version: 17.10.12
  privileged: true
  platform: linux/amd64

$ kitchen converge
...
Removing non-cookbook files before transfer
       Preparing validation.pem
       Preparing client.rb
       +---------------------------------------------+
       ✔ 2 product licenses accepted.
       +---------------------------------------------+
       Chef Infra Client, version 17.10.12
...

[nrocco]

@eheydrick Nice find. I'll try to reproduce this and see if I can fix it

[nrocco]

I reproduced the issue. And I see the following happening.

1. start with 0 images and 0 containers.

2. run kitchen create amd64 and the following happens

• ADDED: image chef/chef@amd64
• ADDED: image dokken/ubuntu-22.04@amd64
• ADDED: image faad922701-test-amd64@amd64
• ADDED: volume de02fa1a68fe5eb26be49651fa0052045512de0c66651a945d1c374f6201c60e
• ADDED: container faad922701-test-amd64@amd64 with volume de02fa1a68fe5eb26be49651fa0052045512de0c66651a945d1c374f6201c60e @ /opt/chef
• ADDED: container chef-latest@amd64 with volume de02fa1a68fe5eb26be49651fa0052045512de0c66651a945d1c374f6201c60e @ /opt/chef

3. Run kitchen destroy amd64

• REMOVED: image faad922701-test-amd64@amd64
• REMOVED: container faad922701-test-amd64@amd64

So the volume and the amd64 based chef/chef container remain!

4. run kitchen create arm64

• ADDED: image dokken/ubuntu-22.04@arm64
• ADDED: image chef/chef@arm64
• ADDED: image faad922701-test-arm64@arm64
• ADDED: container faad922701-test-arm64@arm64 with volume de02fa1a68fe5eb26be49651fa0052045512de0c66651a945d1c374f6201c60e @ /opt/chef

The arm64 based container now has the amd64 based version of chef. So we pulled the chef/chef docker image from the docker hub for the correct architecture. But it is not used.

My knowledge of the kitchen (and kitchen-dokken) architecture is quite minimal but I will try to figure out why the 2nd container does not get a new chef-latest container with the correct architecture, and why a 2nd volume is not being created.

[eheydrick]

Anything else needed for this to be merged and released?

[nrocco]

@eheydrick I don't think so.

I am not aware of the release process, I did not update a changelog or anything. Is that something that happens after merge?

[acesaro]

Looking forward to seeing this merged and available in a Chef Workstation release! The solution works well for my use case of amd64 container images (using x86_64 yum packages, as no aarch64 packages are available in our project). Thanks for your contribution!

[adknox]

This is exactly the issue I have been trying to solve for the last couple of days. I hope this is reviewed and merged soon.

[nrocco]

@jonhermansen and @eheydrick can you help me with the "next steps" to get this pull request accepted and into a mergeable state?

[eheydrick]

@nrocco I will try to get some movement on this.

[franklouwers]

Any updates on this?