Out of host capacity na OCI durante resize: como automatizar retries sem criar um loop cego

Out of host capacity na OCI é um erro meio ingrato.

A configuração que você pediu pode ser válida, a instância pode estar saudável e a região pode simplesmente não ter capacidade disponível naquele momento para executar o resize.

Se a operação é importante, duas respostas ruins aparecem rápido:

ficar repetindo o comando manualmente;
criar um while true agressivo e torcer para uma tentativa passar.

Em uma automação real de resize, o caminho foi tratar capacity como uma condição operacional retryable, mas com limites claros.

A operação continuava sendo resize, não criação de VM #

Este artigo é deliberadamente separado da pauta sobre falta de capacidade ao criar uma VM ARM.

A fonte recuperada aqui é de atualização de shape/configuração de uma instância existente.

O comando central era equivalente a:

1
2
3
4
5
oci compute instance update \
  --instance-id "$INSTANCE_ID" \
  --shape "$CURRENT_SHAPE" \
  --shape-config "{\"ocpus\": ${OCPUS}, \"memoryInGBs\": ${MEMORY_GB}}" \
  --force

Se a OCI devolvia capacity, a automação podia tentar novamente depois.

Isso não autoriza dizer que o mesmo fluxo foi usado para provisionar uma instância nova.

Nem todo erro entra em retry #

Um dos pontos mais importantes do script era classificar o erro.

Entre as mensagens tratadas como temporárias/retryable estavam padrões como:

1
2
3
4
5
6
7
Out of host capacity
OutOfCapacity
timed out
connection timeout
RequestException
ServiceUnavailable
InternalError

A ideia é simples:

1
2
erro possivelmente transitório → pode tentar de novo
erro fatal/configuração         → parar e mostrar o problema

Sem essa separação, uma credencial inválida ou um parâmetro errado pode ficar sendo repetido por horas sem qualquer chance de sucesso.

Retry precisa ter contador #

Na rotina recuperada, esgotar as tentativas gerava um estado explícito de falta de capacidade.

Algo próximo de:

1
2
3
Sem Capacity
Tentativas: 3/3
A instância permanece INALTERADA

Esse último trecho é importante.

A automação não deveria deixar dúvida sobre o estado final quando nenhuma tentativa conseguiu aplicar o resize.

O operador precisa saber:

1
2
3
4
5
mudou?
não mudou?
quantas tentativas foram feitas?
por que parou?
quando tenta novamente?

A fila automática não era um loop apertado #

Outra camada da solução agendava novas tentativas com intervalo operacional.

A política recuperada usava 20 minutos entre tentativas, com fila serializada e locks para evitar concorrência.

Também havia uma janela de operação:

1
2
até 04:00 BRT → continuar dentro da janela
após a janela → retomar no próximo ciclo às 00:00 BRT

O objetivo é bem diferente de:

1
2
3
4
while true; do
  resize
  sleep 5
done

Uma automação de capacity precisa respeitar o provedor e a própria operação.

Lock evita dois processos tentando o mesmo resize #

Retry agendado tem um risco que aparece rápido: uma execução demora, outra começa e as duas passam a operar sobre a mesma instância.

Por isso o fluxo usava serialização/locks.

Conceitualmente:

1
2
3
4
5
6
7
8
9
adquirir lock
  ↓
confirmar estado atual
  ↓
tentar resize
  ↓
validar resultado
  ↓
liberar lock

Sem lock, o scheduler pode transformar tolerância a erro em concorrência acidental.

Capacity não deveria ser tratada como falha fatal imediata #

No playbook/orquestração, Out of host capacity era classificado como aviso operacional.

Isso permitia distinguir:

1
2
3
CAPACITY → não conseguiu agora; pode repetir
FATAL    → interromper fluxo
SUCCESS  → resize aplicado e validado

Essa taxonomia melhora bastante relatório e automação.

Se todo erro vira vermelho fatal, o operador precisa reler log para descobrir que, na verdade, só faltou capacidade no host físico da OCI naquele momento.

Mas sucesso também precisava ser validado #

A automação não parava no retorno do comando.

Depois de a instância voltar ao estado esperado, o sizing deveria ser comparado com o solicitado.

Se houvesse divergência entre:

1
2
OCPUs solicitadas
memória solicitada

versus o shape config efetivamente observado depois, o play deveria falhar.

Isso protege contra falso positivo do tipo:

comando terminou, então deve ter aplicado.

Em infraestrutura, resultado precisa ser lido de volta.

O que a fonte não prova #

A implementação tem um caminho de sucesso com mensagem de resize concluído e validado.

Mas o material recuperado não comprova que aquela ocorrência específica de falta de capacity terminou em sucesso depois de alguma tentativa futura.

O que ele comprova é:

como a operação de resize era feita;
quais erros eram considerados retryable;
como o limite de tentativas era tratado;
que, ao esgotar o lote observado, a instância permanecia inalterada;
que existia uma política de reexecução agendada e serializada;
que um sucesso precisava ser validado pelo sizing final.

Então não tem “final feliz” inventado aqui.

Um desenho simples para esse tipo de retry #

Eu modelaria algo assim:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
LER ESTADO ATUAL
      ↓
VALIDAR PEDIDO
      ↓
TENTAR RESIZE
   ↙       ↘
SUCESSO   ERRO
  ↓         ↓
VALIDAR   CLASSIFICAR
  ↓       ↙        ↘
OK    RETRYABLE   FATAL
        ↓           ↓
  CONTADOR/JANELA   PARAR
        ↓
   AGENDAR NOVA

Isso é mais verboso que um loop.

E justamente por isso é mais operável.

Checklist para retry de capacity #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
[ ] ler shape atual antes da mudança
[ ] validar OCPUs/memória desejadas
[ ] adquirir lock da instância/fila
[ ] executar uma tentativa
[ ] capturar stderr/status completo
[ ] classificar capacity/transitório x fatal
[ ] limitar tentativas do lote
[ ] esperar intervalo razoável
[ ] respeitar janela operacional
[ ] registrar que nada mudou se esgotar capacity
[ ] após sucesso, reler estado da instância
[ ] validar sizing final
[ ] registrar duração e número da tentativa

O principal aprendizado #

Automatizar retry não é repetir comando.

É transformar uma condição transitória do provedor em um estado conhecido da operação.

No caso de Out of host capacity, isso significa saber quando repetir, quando parar e — principalmente — conseguir provar se a instância foi alterada ou permaneceu exatamente como estava.

Se o script não responde essas perguntas, ele só automatizou a ansiedade.