platform: linux/amd64 config is ignored. dokken image shows aarch64.

[sfdcfluong]

👻 Brief Description

platform: linux/amd64 config is ignored. dokken image shows aarch64.
https://kitchen.ci/docs/drivers/dokken/#platform

Version

• kitchen-dokken (2.17.4)
• Test Kitchen version 3.5.0
• Chef Workstation 22.12.1024

Environment

Macos ventura Darwin Kernel Version 21.6.0: Sun Nov 6 23:31:13 PST 2022; root:xnu-8020.240.14~1/RELEASE_ARM64_T6000 arm64

Scenario

My chef recipe adds a yum repo and updates a package but I get No candidate version available for <package>. Probably because of the architecture: aarch64.

# kitchen login
uname -a 
Linux dokken 5.10.124-linuxkit #1 SMP PREEMPT Thu Jun 30 08:18:26 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Steps to Reproduce

I can't really provide this in a usable fashion because my current chef recipe specifies an internal yum repo.

Expected Result

[What are you expecting to happen as the consequence of above reproduction steps?]

Actual Result

note: this works just fine with kitchen-docker but I can't get this to work with kitcken-dokken... I suspect the platform aarch64 is the problem.

         * yum_package[docker-ce] action upgrade
           * No candidate version available for docker-ce
           ================================================================================
           Error executing action `upgrade` on resource 'yum_package[docker-ce]'
           ================================================================================
           
           Chef::Exceptions::Package
           -------------------------
           No candidate version available for docker-ce

➕ Additional context

here's what my kitchen.yml looks like:

---
# https://kitchen.ci/docs/drivers/dokken/
driver:
  name: dokken
  platform: linux/amd64

provisioner:
  name: dokken

transport:
  name: dokken

verifier:
  name: inspec

platforms:
  - name: centos-7
    driver:
      platform: linux/amd64
      privileged: true
      userns_host: true
      pid_one_command: /usr/lib/systemd/systemd
      volumes:
        - /sys/fs/cgroup:/sys/fs/cgroup:ro # required by systemd

suites:
  - name: default
    run_list:
      - recipe[my_recipe::default]
    attributes: { kitchen: true }
    verifier:
      inspec_tests:
        - test/integration/default

[psacc]

I digged a bit into this one and found a possible workaround, @sfdcfluong did you try and remove the local docker image for the platform you don't want to use (i.e. arm64)? If you specify a platform dokker will pull the correct arch flavour (in your excample linux/amd64), but then it seems to run the container without passing the platform of choice, resulting in the wrong platform being used if available. Thus removing the offending image for the platform you don't want should work around the problem.

[snickell]

I'm running into the same issue as @sfdcfluong, also have platform: linux/amd64 specified.

As per @psacc 's suggestion, I've tried purging my system of all linux/arm64 images (including chef/chef and, in my case, dokken/ubuntu-18.04), but still haven't convinced kitchen create to generate a linux/amd64 container.

[snickell]

I figured out what @psacc was doing differently: they ALSO have pull_platform_image: false and pull_chef_image: false.

By purging your system of arm64dokken/$PLATFORM and chef/chef images, and also specifying not to pull, I finally get my dokken container running x86 64.

WORKAROUND:

1. Carefully remove all relevant dokken/* images (and running containers) that use linux/arm64. In my case, this is dokken/ubuntu-18.04.
2. Remove any arm64 chef/chef images.
3. Manually pull your platform image, specifying --platform=linux/amd64, in my case docker pull --platform=linux/amd64 dokken/ubuntu-18.04:latest.
4. Make sure that pull_platform_image: false is set in your kitchen.yml.

---
driver:
  name: dokken
  platform: linux/amd64
  pull_platform_image: false

[sfdcfluong]

Glad we found a workaround. I need to kick tires on this a bit more.

Ideally this should be closer to "just works" but let me know what kind of help would move this forward.

[sfdcfluong]

not a lot if info on https://github.com/test-kitchen/.github/blob/main/CONTRIBUTING.md

[damacus]

@sfdcfluong how can I help you with this one?

What I'd usually suggest is you open a draft PR with some basic code + suggestions if it's a big PR.

If it's a small PR, feel free to make the change, with some tests in a new PR.

CI should now pick up any style or unit breakages. I also have the same issues so if you want any more direct help with this, please feel free to reach out on Chef Community Slack.

[sfdcfluong]

Cool... I'll give it a try when I can circle back to this. Thanks for the tip.

…

On Tue, Nov 28, 2023 at 8:25 AM Dan Webb ***@***.***> wrote: @sfdcfluong <https://github.com/sfdcfluong> how can I help you with this one? What I'd usually suggest is you open a draft PR with some basic code + suggestions if it's a big PR. If it's a small PR, feel free to make the change, with some tests in a new PR. CI should now pick up any style or unit breakages. I also have the same issues so if you want any more direct help with this, please feel free to reach out on Chef Community Slack. — Reply to this email directly, view it on GitHub <#288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWXZWUDNZJ7EO65G5BLZPVTYGXQ2TAVCNFSM6AAAAAAUOFYAJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRZHAZTKOBTGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Franco (Francis Luong)* *Principal Engineer, Network Visibility and Telemetry (NVT)* *Salesforce.com*