
Sessenta contêineres em um servidor
Uma caixa bare-metal executa dezenas a centenas de contêineres Hoody. KSM e BTRFS dedup fazem o custo marginal próximo a zero.
A exportação horária de métricas vem falhando há três dias. Você está de plantão hoje à noite. Faça PATCH na entrada gerenciada do cron com enabled:false — o agendamento, o comando e o comentário ficam todos. O job está em um estado definido: presente e silenciado, esperando que alguém o conserte.
{ "enabled": false, "comment": "reindex flaking — see thread" }
o toggle é só um PATCH · a entrada nunca sai da lista
As entradas gerenciadas do Hoody Cron são um recurso JSON: cada linha tem um id, um agendamento, um comando, um comentário e uma flag enabled. Mudar enabled para false é um PATCH. A entrada permanece no crontab para que a próxima pessoa possa lê-la e decidir o que fazer.
# mute the flaky entry — entry stays in the crontab curl -X PATCH \ https://cron.containers.hoody.com/users/me/entries/e7d3 \ -H "Content-Type: application/json" \ -d '["enabled": false, "comment": "flaking on monday with prod-db — see #pager"]' # response HTTP/1.1 200 OK { "id":"e7d3", "enabled":false, "schedule":"0 * * * *", "command":"/srv/cron/metrics-export.sh", ... }
# the entry is still on the list — just not running curl GET https://cron.containers.hoody.com/users/me/entries HTTP/1.1 200 OK [ { "id":"a1f2", "enabled":true, ... }, { "id":"e7d3", "enabled":false, "comment":"flaking — see #pager" }, { "id":"9b21", "enabled":true, ... } ] # present and muted — the on-call hand-off has somewhere to point
O PATCH não deleta, não reescreve nem move a entrada — ele inverte um booleano. A passagem é uma linha: 'a entrada metrics-export e7d3 está silenciada, veja o hoody-cron, dá uma olhada por favor.'
Uma entrada num crontab Hoody está sempre em exatamente um de três estados. Cada estado tem consequências diferentes para quem sabe o quê amanhã de manhã.
A entrada está no crontab e o daemon do kernel cron a executa toda hora. Falhas acordam o plantão. Esse é o padrão para jobs saudáveis.
enabled:false. A entrada continua no crontab para que o time possa ler seu agendamento, comando e comentário. O daemon do cron a ignora. Sem alerta às 2h da manhã, e ninguém esquece que ela existe.
Quando você faz DELETE, o agendamento, o comando, o comentário, o motivo — tudo isso sai do crontab. O próximo plantão não tem nada para grepar. Silenciar é a escolha que mantém a memória.
Silenciado é o estado intermediário para o qual a maioria dos schedulers não tem nome. O Hoody Cron tem, porque enabled é um campo de primeira classe na entrada gerenciada.
Quando você não consegue consertar um job hoje à noite, a pergunta é que forma a ausência dele assume até amanhã. O silenciamento torna essa forma legível.
Em vez de colar uma thread do Slack ou um PR com a linha deletada, a mensagem é o id da entrada. O plantão de amanhã abre a URL do cron, lê o comentário e sabe por onde começar.
GET /entries retorna enabled:false junto com o comentário. Construa um painel de auditoria filtrando. Quem silenciou, por quê e há quanto tempo está no JSON, não nos DMs de alguém.
Quando o problema raiz é resolvido, mais um PATCH com enabled:true devolve a entrada ao agendamento. Sem reescrever a expressão cron, sem risco de erro de digitação, sem ciclo de commit-and-deploy.
Os números vêm da superfície de managed-entries do Hoody Cron, não de benchmarks inventados.
PATCH /users/[user]/entries/[id] aceita um corpo parcial. Envie ["enabled":false] sozinho — agendamento, comando e comentário ficam intocados.
Agendamento de cinco campos, comando, comentário, expires_at e id, todos persistem ao silenciar. O crontab do kernel ainda reflete a entrada — apenas comentada pelo serviço do cron.
Sem edição de arquivo, sem PR, sem deploy. O round-trip do silenciamento é uma chamada HTTP a partir de qualquer terminal, inclusive o do seu celular.
Conforme a API de Managed Entries do Hoody Cron: cada entrada carrega um booleano enabled junto com agendamento, comando, comentário e expires_at opcional. PATCH aceita corpos parciais.
Desabilitado não é deletado — a entrada espera alguém consertá-la.
As formas usuais de os times 'temporariamente' estacionarem uma linha de cron instável. Cada uma é destrutiva, com perda ou a dois PRs da produção.
Pare de deletar jobs instáveis às 2h da manhã. Silencie-os, deixe uma nota e deixe o plantão de amanhã ler o JSON.