O nível Always Free da Oracle dá a cada tenancy 1.500 horas de OCPU e 9.000 horas de GB por mês de VM.Standard.A1.Flex, que é uma VM Arm de 2 OCPU / 12 GB ligada o mês inteiro. Também dá, em muitas regiões, a mesma resposta toda vez que você aperta Criar:
Out of host capacity. Três dias disso em sa-saopaulo-1 produziram o loop abaixo. Não tem nada de engenhoso; o valor está no que verificar antes de rodá-lo, porque dois dos motivos pelos quais as pessoas esperam semanas não são capacidade.
Verificação 1: cota não é capacidade
O erro diz que o pool de hosts não tem espaço para o seu shape. Não diz nada sobre o limite da sua tenancy, e o limite é o que pode bloquear você para sempre enquanto a culpa cai no pool. Leia-o:
T=<tenancy OCID> AD=$(oci iam availability-domain list --compartment-id "$T" --query 'data[0].name' --raw-output) oci limits resource-availability get --compartment-id "$T" \ --service-name compute --limit-name standard-a1-core-count \ --availability-domain "$AD" --query 'data.{available:available,used:used}' Se available for 0, retentar não adianta: você está no limite de cores A1 (2 OCPU em uma tenancy Always Free) e algo, talvez uma instância criada pela metade em uma tentativa anterior, está ocupando-o. Se available for 2, o loop faz sentido.
Verificação 2: a região home, não qualquer região
O compute Always Free só conta na região home da tenancy, e a região home fica fixa quando a conta é criada. A própria página da Oracle diz isso claramente: "You must create the Always Free compute instances in your home region." Então um relato de que "Mumbai tem capacidade" só ajuda se Mumbai for a sua região home. No Pay As You Go a franquia Always Free continua valendo na região home, e uma A1 em qualquer outra região é uma instância paga a preço de lista, o que para algumas pessoas é a resposta certa.
Em regiões com mais de um availability domain, a A1 pode ser criada em qualquer AD; data[0].name acima escolhe o primeiro. Alterne o AD a cada tentativa se a sua região tiver três.
O loop
A retentativa do console só vive enquanto a aba está aberta. Isto roda em qualquer máquina com um ~/.oci/config funcionando e para no primeiro sucesso. Uma chamada de launch que falha leva cerca de 100 segundos para voltar, então com um sleep de dois minutos são mais ou menos dez tentativas por hora, bem abaixo do rate limit da API; em um 429 ele espera cinco minutos.
#!/usr/bin/env bash # needs a working ~/.oci/config; fill T (tenancy or compartment OCID), SUBNET, IMAGE, PUBKEY set -u T=${T:?} SUBNET=${SUBNET:?} IMAGE=${IMAGE:?} PUBKEY=${PUBKEY:-~/.ssh/id_ed25519.pub} NAME=${NAME:-a1} SLEEP=${SLEEP:-120} AD=$(oci iam availability-domain list --compartment-id "$T" --query 'data[0].name' --raw-output) try() { local ocpus="$1" mem="$2" out out=$(oci compute instance launch \ --compartment-id "$T" --availability-domain "$AD" \ --display-name "$NAME" --shape VM.Standard.A1.Flex \ --shape-config "{\"ocpus\":$ocpus,\"memoryInGBs\":$mem}" \ --image-id "$IMAGE" --subnet-id "$SUBNET" --assign-public-ip true \ --ssh-authorized-keys-file "$PUBKEY" \ --query 'data.{id:id,st:"lifecycle-state"}' 2>&1) if grep -q '"id": "ocid1.instance' <<<"$out"; then echo "$(date -u +%FT%TZ) OK ${ocpus}/${mem}: $out" grep -o 'ocid1\.instance[^"]*' <<<"$out" > ~/a1-retry.ok return 0 fi echo "$(date -u +%FT%TZ) no ${ocpus}/${mem}: $(grep -o '"message": "[^"]*"' <<<"$out" | head -1)" grep -qi 'TooManyRequests\|429' <<<"$out" && sleep 300 return 1 } n=0 while :; do n=$((n+1)); echo "--- round $n" try 2 12 && break try 1 6 && break sleep "$SLEEP" done echo "instance: $(cat ~/a1-retry.ok)" oci compute instance list-vnics --instance-id "$(cat ~/a1-retry.ok)" \ --query 'data[0]."public-ip"' --raw-output Inicie com nohup ./a1-retry.sh > a1-retry.log 2>&1 & e esqueça. Ele tenta primeiro a 2/12 completa e depois a 1/6; a A1 é redimensionada no lugar mais tarde, então pegar a menor quando ela aparece não custa nada. O OCID da imagem é por região (oci compute image list --compartment-id "$T" --operating-system "Canonical Ubuntu" --shape VM.Standard.A1.Flex lista as Arm).
O que a thread me ensinou
Publiquei o loop no r/oraclecloud e as respostas foram mais úteis que o script. Uma pessoa esperou seis meses em Ashburn retentando a cada 30 segundos pelo console, que é a versão de um só AD e um só shape deste problema e o motivo para alternar ADs. Duas pessoas conseguiram A1 em Mumbai em questão de horas, uma delas no Pay As You Go, o que é consistente com a nota da Oracle de que o upgrade "gives you access to more types of Compute resources". E ninguém, eu incluído, tem um registro de horário de quando São Paulo libera, e é por isso que o loop registra cada tentativa: se um dia entrar, o log diz a que hora, e esse é o único dado que alguém tem.
Quando ela existir
Mantenha a instância ocupada. A Oracle recolhe instâncias Always Free ociosas depois de sete dias abaixo de 20 % de CPU, rede e memória no percentil 95. E uma instância pela qual você brigou três dias merece estar na lista do que você roda: eu construo o Control Cloud, que lê a tenancy pela API com uma credencial somente leitura e mostra a A1 ao lado de todo o resto, incluindo o boot volume que ela deixa para trás se um dia você a terminar sem marcar "permanently delete". Plano gratuito: 1 operador, 1 provedor.

