Files
obsidian-vault/personal/projects/virfield.md
T

15 KiB
Executable File
Raw Blame History

title, namespace, updated, status, tags
title namespace updated status tags
Virfield personal 2026-10-07 virfield-3-stage-1-in-progress
virfield
macos
vm
go
infrastructure

Virfield 3.0 — handoff checkpoint — 2026-10-07 15:35 Bishkek

Текущий статус: Stage 1 (Tart/Orchard migration) в работе; продолжать в /Users/admin/Developer/virfield-v3, branch codex/virfield-v3-stage1. Это актуальная запись состояния; ниже сохранена история v2 от 2026-10-03.

Обновление 2026-10-07 17:00 — dirty-дерево развернуто на 7780

  • Исправлен логин: api() в internal/web/app.js сообщал «Cannot reach Virfield API» на любой TypeError, а fetch() бросает TypeError ещё до запроса, если токен содержит не-Latin-1/управляющие символы (кириллица, emoji, перевод строки). Теперь Request строится отдельно → invalid_token / «Invalid token format…»; «Cannot reach» только при реальном сбое сети. Неверный ASCII-токен → серверный 401 «a valid bearer token is required». Проверено вживую в UI.
  • Разобраны незакоммиченные Go-правки (registry credentials только для matching Tart remote, APFS free-space fallback, тесты) — оставлены. Ограничение: registry host с портом (localhost:5000) отклоняется валидацией.
  • Открытый вопрос: CSP в internal/httpapi/server.go ослаблен (style-src 'unsafe-inline', img-src data:), но UI не использует inline styles/data: URI (meters на <progress>). Кандидат на откат к строгому CSP — решение за владельцем.
  • make check exit 0, git diff --check чисто, make build прошёл. Деплой: исходники = HEAD 8830ad9 + dirty-дерево (не закоммичено); virfieldd sha256 b6dbc77d4e1b05122aca9b5ad146ae609abbe226d71ec28da818bfad12758f97. Rollback: ~/.virfield-v2/bin/virfieldd.pre-v3-20261007-165759 (это бинарник, лежавший на диске с 15:18; работавший до этого процесс PID 54497 был запущен в 13:50 из более старого, уже заменённого файла).
  • Перезапуск без sudo подтверждён: kill -TERM единственного PID → launchd (KeepAlive) поднял PID 65669 за 2 с, last exit code 0. 7780 отдаёт app.js, идентичный worktree. Статус после рестарта: lease lease-c30327cb… (macos27, samsung, 192.168.64.211) остался ready, VM running, SSH доступен; job job-3adb9d9d… (13.6/Xcode 15.2) по-прежнему needs_attention (image_command_failed на Setup Assistant) — требует отдельного разбора по recovery-процедуре.

Что проверено сейчас

  • Worktree: HEAD 8830ad9 (Add Tart and Orchard runtime providers), родительский план 6013310. Восемь файлов modified и не закоммичены: cmd/virfieldd/main.go, internal/config/config.go, internal/httpapi/server.go, internal/tart/client.go, internal/tart/client_test.go, internal/web/app.js, internal/web/index.html, internal/web/style.css. Не откатывать и не считать эти изменения заведомо своими без проверки.
  • http://127.0.0.1:7780 отвечает HTTP 200 и отдаёт v3 UI (Fleet / Images / Activity, Hosts & storage). Факт подтверждён запросом к live-сервису.
  • Live virfieldd: launchd label system/ai.virfield.virfieldd, PID 54497 на момент проверки, пользователь admin; plist /Library/LaunchDaemons/ai.virfield.virfieldd.plist запускает ~/.virfield-v2/bin/virfieldd -config ~/.virfield-v2/config.json. Имя virfield-v2 — legacy путь развертывания, не доказательство версии исходников.
  • Точная ревизия уже работающего процесса не установлена. Не заявлять, что бинарник на 7780 собран из HEAD 8830ad9.
  • Текущий dirty source успешно компилируется (go build -trimpath -o /private/tmp/virfieldd-v3-check ./cmd/virfieldd) и полный make check прошёл на этом состоянии 2026-10-07: docs links, Python tests, gofmt, go vet ./..., go test -race ./... (включая internal/tart и internal/orchard). Реальный Tart VM lifecycle и live Orchard acceptance не прогонялись.

Следующее действие

Шаги 1–5 ниже выполнены 2026-10-07 (см. обновление выше). Дальше: закоммитить проверенное дерево на codex/virfield-v3-stage1; решить по CSP; разобрать needs_attention job 13.6/Xcode 15.2; затем Phase 1 — digest-pinned Cirrus Tart adoption и две disposable Tart clone/boot/SSH/release проверки.

  1. Разобрать каждое из восьми незакоммиченных изменений и сохранить нужное; проверить владельца/намерение, не затирать.

  2. Прогнать make check в этом worktree и устранить регрессии.

  3. Собрать make build; сохранить копию текущего deployment binary для отката, заменить ~/.virfield-v2/bin/virfieldd собранным бинарником.

  4. Перезапуск текущего launchd job пока не проверен. Для контролируемой проверки после сборки:

    pgrep -x virfieldd
    # Убедиться, что найден ровно один PID текущего сервиса.
    kill -TERM PID
    launchctl print system/ai.virfield.virfieldd | rg 'state =|pid =|runs ='
    curl -fsS http://127.0.0.1:7780/ | rg 'v3|Fleet|Hosts & storage'
    

    Причина ожидания автоматического старта: plist имеет KeepAlive=true, процесс работает от admin, а deployment directory принадлежит admin. Это ожидаемый способ без sudo, но пока не подтверждён живой проверкой. Если launchd не поднял новый PID, остановиться и диагностировать; не запускать второй daemon.

    Сборка/установка (после успешных проверок; перед заменой сохранить бинарник для rollback):

    cd /Users/admin/Developer/virfield-v3
    make check
    make build
    cp -p /Users/admin/.virfield-v2/bin/virfieldd /private/tmp/virfieldd-before-v3
    install -m 755 bin/virfieldd /Users/admin/.virfield-v2/bin/virfieldd
    

    До live-проверки не объявлять обновление завершённым. Общий install/runbook находится в docs/OPERATIONS.md; он описывает регистрацию system LaunchDaemon с sudo, но не dev-перезапуск существующего job без sudo.

  5. После подтверждения записать точный commit/build и результат live-проверки здесь. До этого не создавать второй listener и не менять порт.

План/код — актуальный разбор

Есть в коде: единый provider.Runtime seam; конфиг выбирает Tart либо Orchard для одного процесса; Tart inventory/clone/run/stop/delete и отдельные TART_HOME storage containers с UUID/availability/free-space; Orchard worker/VM inventory, labels, per-host CPU/RAM/VM-slot capacity, offline reasons, create/stop/delete; общий lease/controller; Hosts/storage UI; WoL magic-packet sender; registry credentials передаются только командам Tart с matching registry host. Текущие dirty правки также чинят disk free-space APFS fallback, CSP для нового UI и registry auth. make check прошёл на текущем dirty дереве.

Частично / не принято live: внешний SSD и device groups отражаются из конфига/runtime observations, но отдельная независимая durable device registry в SQLite не добавлена; WoL отправляется самим процессом на configured broadcast, а не через отдельный same-L2 node-agent relay; Tart/Orchard проверены unit tests, но ни Cirrus digest adoption, ни реальная VM lease/clone/boot/SSH/release, ни live Orchard pool не приняты. Один virfieldd выбирает ровно один runtime — смешанный local Tart + remote Orchard/Lume provider routing пока отсутствует.

Не сделано из плана: node-agent и bare-metal lease для Intel Mac/Linux; connection grants/access gateway; VNC/noVNC и единый desktop; v3 API/target capability model; VS Code extension (остаётся генератор workspace/LLDB v2); libvirt/QEMU/OpenCore Hackintosh; Broker contract migration; distributed image worker/promotion; drain, multi-host lifecycle acceptance и production rollout. image_tools pipeline остаётся Lume-only и явно отклоняется при Tart; для Tart нужен отдельный digest-pinned Cirrus adoption/qualification path.

docs/VIRFIELD-3-PLAN.md остаётся целевой архитектурой, но 2026-10-07 его этапы обновлены: Phase 1 теперь Tart/Cirrus adoption и отдельная Orchard acceptance; статус, незакрытые gates и отличие unit tests от live acceptance прописаны. Docs link check и git diff --check прошли. Изменение в worktree пока не закоммичено.

  • Источник кода — worktree virfield-v3; live deployment — ~/.virfield-v2; это разные копии. 7780 показывает v3 UI, но точная ревизия процесса не установлена.

Virfield — статус 2026-10-03

Следующее действие: проверить загрузку, работу и удаление временного клона из нового чистого образа Monterey/Xcode.

Состояние

  • Monterey 12.6 + Xcode 13.4.1: образ image_ready, временный legacy-клон прошёл загрузку, компиляцию Swift, SSH, выгрузку артефакта и очистку. Тест TestLiveLeaseSSH прошёл за 86,99 с 2026-10-03.
  • Исходный образ macos-12.6-xcode-13.4.1 остановлен и сохранён. Временный клон удалён; активных заданий и занятых слотов нет.
  • Release-ready: нет. Чистая сборка прошла; клон нового образа и полный путь Balda/Broker ещё не приняты.
  • Ветка codex/versioned-images: локальный коммит 19e01ac; push не сделан.

Установка Xcode и размер диска

  • macOS 13+ использует VirtioFS. Monterey не монтирует VirtioFS; его путь передаёт проверенный XIP по закреплённому SSH и сверяет SHA-1 в госте.
  • На существующей 80 GB VM xip отказался распаковываться при ~42 GiB свободного места. Фолбэк передал проверенный Xcode.app по SSH без macOS tar metadata; гостевая подпись Apple и точная версия прошли проверку.
  • XIP занимает ~10 GB. Кэшированный Xcode.app занимает ~17 GB на хосте; несжатый поток файлов составил ~32 GiB. Готовая 80 GB VM занимает на хосте ~49 GiB.
  • Новые macOS 11/12 VM с Xcode получают разреженный виртуальный диск 120 GB. Чистая сборка подтвердила, что XIP распаковывается на нём без фолбэка; готовый новый диск занимает 34,8 GiB на хосте. Существующая 80 GB VM не увеличивалась.

Legacy-клон и проверки

  • legacy_uuid допускает APFS encryption at rest при выключенном FileVault и только одного активного worker. Registry publish для этого образа запрещён.
  • Первый живой клон не загрузился: Lume поменял machineIdentifier и MAC-адрес. Он был удалён. Virfield теперь восстанавливает оба значения из остановленного образа до запуска копии и проверяет наличие скопированного NVRAM. Обычные клоны сохраняют новую идентичность.
  • Повторный клон подтвердил Xcode 13.4.1 / 13F100, Swift, SIP, Finder, политику диска, закреплённый SSH, отказ ключу исходного образа, туннель и SCP-артефакт. Второму одновременному legacy worker отказано. После теста исходный образ остался image_ready.
  • Чистая сборка macos-12.6-xcode-13.4.1-clean-20261003 завершилась без ручного восстановления: задача job-ca072dfb3bfee011bd7ee9fcd28d8f46 succeeded, образ image_ready и остановлен. Первый запуск через image-create был отклонён из-за APFS: эта команда не задаёт legacy_uuid; неудачная VM удалена с разрешения пользователя. Повторная сборка использовала профиль в config.json с legacy UUID.
  • make check и make build прошли; установленный менеджер обновлён. Подробные результаты — docs/VERIFICATION.md; контракт установки — docs/IMAGE-PIPELINE.md.