Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Simplify deployment: unify dstack and meta-dstack workflows

Ouverte
  • Quelque chose ne va pas ?
#422 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
À l'abandon
Stack technique
github, shell
Domaine
devops, infrastructure

Piste de recherche

Commencez par lire kms/dstack-app/deploy-simple.sh et deploy-to-vmm.sh, puis comparez leurs entrées avec les workflows hostcfg et dl de meta-dstack's build.sh. C’est terminé lorsque le point d’entrée du déploiement, la disposition des répertoires, l’acquisition de l’image invitée et les chemins de développement et de production sont unifiés comme décrit, tandis que la construction de l’image OS à partir des sources reste facultative.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

Setting up dstack currently requires understanding two repositories with different workflows:

1. Two repos required for basic deployment
  • meta-dstack: Config generation (build.sh hostcfg) and image download (build.sh dl)
  • dstack: Components and deploy scripts (kms/dstack-app/deploy-*.sh)

New users must clone both repos and understand their relationship.

2. Inconsistent paths between dev and production
Task Dev Deployment Production Deployment
Get guest image ../build.sh dl 0.5.5 Direct GitHub release download
Generate configs ../build.sh hostcfg Manual or embedded in compose
Deploy KMS Run binary on host kms/dstack-app/deploy-*.sh

Same artifacts, different acquisition paths.

3. Deploy scripts in unexpected location
  • kms/dstack-app/deploy-simple.sh and deploy-to-vmm.sh deploy to VMM
  • These aren't KMS-specific—they're general CVM deployment scripts
  • Expected location would be top-level deploy/ or similar
4. Guest image acquisition differs
  • Dev: Requires meta-dstack checkout, then ../build.sh dl
  • Prod: Direct download from https://github.com/Dstack-TEE/meta-dstack/releases

Both get the same tarball via different paths.

Impact

  • Steeper learning curve for new operators
  • Documentation must explain two different workflows
  • Easy to get confused about which repo/script to use
  • Friction when switching between dev and production setups

Suggested Direction

  • Single entry point for deployment (no meta-dstack required for normal use)
  • Unified deploy/ directory structure in dstack repo
  • meta-dstack becomes optional (only needed for building OS image from source)
  • Config templates with sensible defaults

This is a tracking issue for discussion. Implementation would be a larger effort.

Langage dominant
Rust
Étoiles
555
Forks
99
Merge moyen
1 j 3 h
PR mergées (30 j)
195

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Dstack-TEE/dstack

Toutes les issues de Dstack-TEE/dstack

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.