v0.44.0 — VMfile, e um diagnóstico de cgroup que estava a mandar editar o /etc por nada

v0.44.0 — VMfile, e um diagnóstico de cgroup que estava a mandar editar o /etc por nada

Duas metades. A primeira é funcionalidade nova: construir a imagem qcow2 de uma
microVM a partir de um ficheiro declarativo, ao estilo do Delonixfile. A
segunda começou por ser uma pergunta do utilizador — o que faz sudo delonix system setup --delegate? — e acabou a corrigir o comando, o instalador e a
documentação, porque a resposta que eu tinha dado estava errada.

VMfile — vm init e vm build

O caminho para uma imagem VM própria era image --vm build com uma lista de
flags (--extra-package, --extra-run) por cima de uma receita fixa em Rust.
Serve para a golden do k8s, que é nossa; não serve para alguém que queira a
SUA imagem, com o seu cloud-init, publicada no seu repositório.

VMfile é essa forma, com a gramática que toda a gente já sabe ler:

FROM ubuntu:24.04
SIZE 20G
HOSTNAME app
VCPUS 2
MEMORY 4G

RUN apt-get update && apt-get install -y nginx
COPY ./site /var/www/html
ENV APP_ENV=production
USER delonix
SSHKEY @~/.ssh/id_ed25519.pub
CLOUDINIT ./cloud-init/user-data

• FROM é uma cloud image, não uma imagem OCI — ubuntu:24.04,
  debian:12, rocky:9, ou um URL absoluto para o qcow2 que quiseres. É a
  distinção que dá sentido ao resto: uma cloud image traz cloud-init, e é o
  cloud-init que faz o primeiro boot aplicar hostname, chaves e utilizadores.
• Multi-stage com COPY --from=<estágio>, como no Delonixfile.
• delonix vm init escreve o esqueleto completo (VMfile + cloud-init/
  com user-data/meta-data comentados), para não se começar de uma página
  em branco.
• delonix vm create --url-img https://… cria a microVM directamente de um
  qcow2 publicado — o caminho de quem já construiu a imagem e a pôs no seu
  repositório.

O --delegate que eu recomendei não era a correcção

Ao explicar o comando, afirmei que ele resolvia o cpu em falta neste host.
Medi antes de publicar e a afirmação estava errada nos três pontos:

1. O Ubuntu 24.04 já traz Delegate=pids memory cpu no user@.service. O
   drop-in que o --delegate escreve pedia exactamente o que já lá estava.
2. O subtree_control do user@1000.service já era propriedade do utilizador.
   A delegação não estava em falta — estava feita.
3. O que faltava o cpu era o slice de onde o comando corria (app.slice, o
   scope do editor), que não o passa para baixo. Um drop-in no /etc não lhe
   toca.

E cpuset/io nunca podiam aparecer: o user.slice, que é da root, só
passa cpu memory pids para os descendentes. Pedi-los num drop-in seria pedir
uma coisa que o antepassado não tem para dar.

O que mudou por causa disso

O cpu e o cpuset/io deixaram de ser o mesmo facto. Faltar o cpu é
um nó Kubernetes que não arranca; faltar cpuset/io é o estado normal de um
Ubuntu de fábrica, onde tudo funciona. A lista única tratava os dois como o
mesmo problema e mandava para o /etc por causa do segundo:

controllers: memory pids
missing:  cpu  ← a Kubernetes node CANNOT boot without this
absent:   cpuset io  ← optional; nothing here needs them

A ordem dos remédios inverteu-se. O scope delegado — sem root, sem
reiniciar sessão, efeito imediato — é agora a correcção 1, e o drop-in no
/etc é a 2, apresentada como o que fazer se a primeira ainda disser que
falta o cpu. A ordem anterior mandava alterar a configuração global da
máquina antes de tentar a coisa gratuita que resolve o caso comum.

O preflight do cluster create diz o mesmo. Recusa antes de descarregar
425 MB, como na v0.43.1, mas o comando que oferece é o scope, não o sudo.

O install.sh não escreve o drop-in num host que já delega o cpu. Lê o
Delegate= efectivo do user@.service e salta quando o cpu já lá está.
Escrever no /etc de toda a máquina para repetir o que a distro já faz não é
inofensivo: dá a impressão de ter resolvido um problema que o utilizador
continua a ter.

Documentação

O README e o site descreviam a ordem antiga. Passaram a explicar as duas
correcções pela ordem certa, e a dizer porque é que cpuset/io aparecem como
absent sem que isso seja um problema a resolver. O laboratório 2 (limites de
recursos) foi reescrito no mesmo sentido — era o sítio onde um leitor novo
aprendia a começar pelo sudo.

Validação

Testes verdes, clippy e fmt limpos. Os dois caminhos do system setup
verificados ao vivo (dentro do scope do editor e dentro de um scope delegado),
e o cluster create confirmado a passar o preflight e a avançar para o pull
dentro do scope delegado. Teste novo a fixar a distinção fatal/opcional, que
falha se a lista voltar a ser uma só.