Feature Request: Option to Specify Platform/Architecture in DevPod Settings/CLI

[anshuman852]

Devpod Version : 0.6.7 Provider: Kubernetes Flavour: Azure Kubernetes Service

Is your feature request related to a problem? Thank you for the amazing product and all the hard work that goes into it! I’ve encountered an issue related to resource scheduling when using devpod up. Currently, the workflow starts with an architecture detection pod to determine the node’s platform/architecture (e.g., x86, arm64). This pod then creates the actual devpod, which must be scheduled on the same node to avoid architecture mismatches.

The issue arises because the architecture detection pod requires minimal resources and can be scheduled on smaller nodes (e.g., 2 cores, 8GB RAM). However, if the devpod requests larger resources (e.g., 16GB RAM), it cannot be scheduled on the same node, leading to scheduling failures.

Which solution do you suggest? I propose adding an option to specify the desired platform/architecture directly via DevPod settings or the CLI. This would eliminate the need to run the architecture detection pod entirely, simplifying the process and avoiding scheduling conflicts.

Which alternative solutions exist? An alternative could involve aligning the resource requests/limits of the architecture detection pod with those of the devpod, ensuring they are scheduled on compatible nodes. However, this approach increases resource requirements temporarily and might not be ideal.

Additional context Allowing users to pass the platform/architecture directly would streamline workflows and provide more control over the scheduling process, reducing unnecessary pod creation and resource usage.

Thank you again for the fantastic product and for considering this request! Looking forward to your thoughts on implementing this feature.

[anshuman852]

I have created a copy on https://github.com/loft-sh/devpod-provider-kubernetes/issues/65

[pascalbreuninger]

Hey @anshuman852, thanks for this suggestion. It makes a lot of sense to me, specially for smaller node pools. Specifying the architecture in the kubernetes provider options seems to be the most straight forward way to implement and easiest to use

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[charlysotelo]

Hey @anshuman852, thanks for this suggestion. It makes a lot of sense to me, specially for smaller node pools. Specifying the architecture in the kubernetes provider options seems to be the most straight forward way to implement and easiest to use

Specifying it in the Docker provider too is of interest to me. I have x84 images I'd like to run on my amd64 machine, which should work if I have Rosetta installed, but currently devpod insists on trying to use the native arch

[charlysotelo]

For posterity, I was able to get a Docker provider to use my target architecture by defining a copy of the standard Docker provider yaml with the DOCKER_DEFAULT_PLATFORM env var defined, adding it as a new provider, and leveraging it to create a new workspace:

name: docker-amd64
version: v0.0.1
icon: https://devpod.sh/assets/docker.svg
home: https://github.com/loft-sh/devpod
description: |-
  DevPod on Docker
optionGroups:
  - options:
      - DOCKER_PATH
      - DOCKER_HOST
      - INACTIVITY_TIMEOUT
      - DOCKER_BUILDER
    name: "Advanced Options"
options:
  INACTIVITY_TIMEOUT:
    description: "If defined, will automatically stop the container after the inactivity period. Examples: 10m, 1h"
  DOCKER_PATH:
    description: The path where to find the docker binary.
    default: docker
  DOCKER_HOST:
    global: true
    description: The docker host to use.
  DOCKER_BUILDER:
    global: true
    description: The docker builder to use.
agent:
  containerInactivityTimeout: ${INACTIVITY_TIMEOUT}
  local: true
  docker:
    path: ${DOCKER_PATH}
    builder: ${DOCKER_BUILDER}
    install: false
    env:
      DOCKER_HOST: ${DOCKER_HOST}
      DOCKER_DEFAULT_PLATFORM: linux/amd64
exec:
  command: |-
    "${DEVPOD}" helper sh -c "${COMMAND}"

Which raises the obvious question, can we add this as an option to the default Docker provider?

[github-actions[bot]]

This issue is stale because it has been open for 60 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 30 days since being marked as stale.