Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Simplify deployment: unify dstack and meta-dstack workflows

Aberta
  • Algo errado?
#422 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
25/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Estagnada
Stack de tecnologia
github, shell
Domínio
devops, infrastructure

Direção de pesquisa

Comece lendo kms/dstack-app/deploy-simple.sh e deploy-to-vmm.sh e, em seguida, compare suas entradas com os workflows hostcfg e dl de meta-dstack's build.sh. O trabalho estará concluído quando o ponto de entrada do deployment, o layout de diretórios, a aquisição da guest-image e os caminhos de desenvolvimento e produção estiverem unificados conforme descrito, enquanto a compilação da imagem do OS a partir do código-fonte continuar opcional.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
555
Forks
99
Merge médio
1d 3h
PRs com merge (30d)
195

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Dstack-TEE/dstack

Todas as issues de Dstack-TEE/dstack

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.