Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Feature: declarative host-service lifecycle for system-container workloads

オープン
  • 何か問題がありますか？
#1,033 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
docker, docker-compose, linux, rust
領域
infrastructure, operating-systems, security

調査の方向性

既存のホストメカニズムと namespace の動作を理解するために、os/common/rootfs/app-compose.service、os/common/rootfs/app-compose.sh、dstack/host-api/proto/host_api.proto、os/mkosi/mkosi.skeleton/usr/lib/tmpfiles.d/dstack-image.conf を読みます。列挙された受け入れ基準に照らして、制約付きの宣言的コントラクトを定義し、レビューします：再起動時の復元、永続リソースとブートスコープのリソースの区別、アトミックなロールバック、アプリケーションが管理する host-root へのインストールを行わないこと。

索引モデルが issue の本文から書いたものです。

説明

Summary

We run Incus/LXC system containers inside a DStack CVM. For our storage, cgroup, and reboot semantics, the Incus daemon runs as a PID 1-owned host systemd service rather than as an ordinary application container.

The integration works, but the application currently owns an imperative host-service installer and its complete reboot, readiness, update, and rollback protocol. We would like DStack to provide a constrained, declarative lifecycle contract for this class of host service.

Existing DStack mechanisms

DStack already provides host execution mechanisms; this request does not claim otherwise.

At current next commit 312dc605ebaaf93372534ffb135ea011533d28e9:

  • app-compose.service is a host systemd oneshot that runs app-compose.sh and remains active after the script exits.
  • app-compose.sh supports a pre-launch script, Docker or nerdctl Compose, and a bash runner.
  • The vsock HostApi exposes Info, Notify, and GetSealingKey.

These are useful imperative building blocks, but the current public contract does not describe a typed host-service declaration with persistent/boot-scoped resources, service ownership, readiness, or rollback semantics.

Why an ordinary Compose service is insufficient for this workload

For our required deployment model, the Incus daemon must:

  • own a delegated cgroup subtree for nested system containers;
  • use host-native ZFS state under /dstack/persistent;
  • remain a PID 1-owned service independently of the finite installer; and
  • receive explicit persistent and boot-scoped binds into a content-addressed userspace root.

Our current integration therefore uses a finite privileged Compose job with host PID/root access. One centralized nsenter --target 1 boundary verifies a pinned payload, materializes a boot-scoped root, installs runtime systemd units, binds persistent state and boot-scoped resources, starts the daemon, and checks readiness. A mismatch or partial generation fails closed.

This is workable, but every consumer of this pattern must implement and secure its own installer, convergence, reboot recovery, update, and rollback logic.

Requested capability

Please consider a constrained host-service declaration that can express:

  • a content-addressed and authenticated payload;
  • explicit persistent state and boot-scoped runtime mounts;
  • bounded systemd unit properties, capabilities, cgroup delegation, and ordering;
  • readiness and health conditions; and
  • atomic update, reboot recovery, and rollback behavior.

The declaration should be authenticated and capability-scoped. We are not requesting unrestricted host command execution, and the implementation need not extend HostApi; a parallel mechanism would be equally suitable.

Namespace-safe host resources

One concrete edge case is resolver projection. On the released image, /etc/resolv.conf was an absolute symlink chain ending under /run/systemd/resolve. Reading it through a container's /host root bind resolves the absolute target in the container mount namespace and misses the host file. Current mkosi source similarly creates /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf.

Our installer handles this inside the PID 1 mount namespace. A declarative contract should instead document or provide a namespace-safe projection for host resources consumed by the declared service. We are not requiring resolv.conf to be a regular file.

Suggested acceptance criteria

  • A declared service is restored to ready state after an unchanged CVM reboot.
  • Persistent state survives reboot and application update, while boot-scoped resources are reconstructed.
  • A failed update leaves or restores the last ready generation.
  • The application does not need a host-root bind or nsenter to install and reconcile the declared service.

Scope

This is a feature request, not a report that DStack Compose or HostApi is broken. Incus networking/kernel compatibility is tracked separately.

主要言語
Rust
スター
555
フォーク
97
平均マージ
1日 3時間
マージ済み PR（30日）
195

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Dstack-TEE/dstack のほかの issue

Dstack-TEE/dstack の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。