Saltar al contenido principal

Configuración

Archivo​

octopus lee ~/.octopus/config.yaml (directorio 0700, archivo 0600). Si no existe pero hay un ~/.octopus/octopus.json viejo, lo migra solo y avisa por stderr. Sin ninguno de los dos, falla con run 'octopus config init' first. Se crea con config init y se edita con config set.

version: '2'
active_profile: default
profiles:
  default:
    host: localhost:9090 # gRPC del kernel
    http_host: http://localhost:8000 # opcional, para server health
    tls: false
    default_tenant: acme-bank
    auth:
      open_id:
        url: http://localhost:8080/realms/octopus
        client_id: octopus

Perfiles​

En el código lo que llamamos "contexto" es un perfil: un entorno con nombre. No hay use-context; el verbo es config profile use <nombre>. Para un solo comando, --profile (-p) pisa el perfil activo sin tocar el archivo (los subcomandos de config lo ignoran, porque ahí significa otra cosa). Gestión: add, delete, list, show.

Secretos y variables de entorno​

El client secret de OpenID nunca va en el YAML. Se busca primero en el keychain del sistema (servicio octopus, clave <perfil>/openid_client_secret) y, si no está, en la variable OCTOPUS_OPENID_CLIENT_SECRET. Es la única variable de entorno que lee el CLI; no hay otras que pisen el archivo. El token se pide por client credentials a <url>/protocol/openid-connect/token.

Cómo se resuelve --tenant​

  1. --tenant / -t (código del tenant); --global / -g equivale a --tenant global.
  2. Si falta, el default_tenant del perfil activo.
  3. Si tampoco está, queda vacío.

Los comandos con alcance de tenant convierten el código en UUID consultando al kernel (RetrieveTenant por código) y lo adjuntan al contexto de la llamada. Si la consulta falla, el comando sigue sin tenant en vez de abortar. apply resuelve por recurso (metadata.tenant primero, después el tenant del CLI) y ahí un error sí aborta ese recurso.