Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Simplify deployment: unify dstack and meta-dstack workflows

Offen
#422 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
github, shell

Rechercherichtung

Beginnen Sie mit dem Lesen von kms/dstack-app/deploy-simple.sh und deploy-to-vmm.sh und vergleichen Sie dann deren Eingaben mit den hostcfg- und dl-Workflows von meta-dstack's build.sh. Erledigt ist die Aufgabe, wenn der Einstiegspunkt für die Bereitstellung, das Verzeichnislayout, die Beschaffung des Gast-Images sowie die Entwicklungs- und Produktionspfade wie beschrieben vereinheitlicht sind, während das Erstellen des OS-Images aus dem Quellcode optional bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
551
Forks
97
Ø Merge
1 T. 8 Std.
Gemergte PRs (30 T.)
182

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Dstack-TEE/dstack

Alle Issues in Dstack-TEE/dstack

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.