Migrar do RootPilot

A partir da versão 1.29.0, o Agent e o Profiler usam o nome WhyStack em tudo o que definem, não só no texto: imagem, nomes do Kubernetes, variáveis, hostnames, comando de saúde. Uma instalação feita com uma versão anterior segue funcionando ao passar para a imagem nova, graças aos fallbacks de O que segue funcionando por enquanto. Eles são temporários: reinstale com os nomes novos.

O que muda

O quê	Antes	A partir da 1.29.0
Imagem do Agent	`<address>/rootpilot-agent`	`<address>/whystack-agent`
Imagem do Profiler	`<address>/rootpilot-profiler`	`<address>/whystack-profiler`
Caminho no Artifact Registry	`<project>/rootpilot/rootpilot-agent`	`<project>/whystack/whystack-agent`
Identidade da assinatura (cosign)	`github.com/sunnysystems/rootpilot-edge/...`	`github.com/sunnysystems/whystack-edge/...`
Control-plane (enrollment)	`https://app.rootpilot.sh`	`https://app.whystack.ai`
Túnel	`wss://tunnel.rootpilot.sh:8443`	`wss://tunnel.whystack.ai:8443`
Documentação	`docs.rootpilot.sh`	`docs.whystack.ai`
Arquivo da policy IAM	`rootpilot-edge-readonly.json`	`whystack-edge-readonly.json`
Comando de saúde	`rootpilot-health`	`whystack-health`
Default do `RUNNER_HEALTH_DIR`	`/tmp/rootpilot-health`	`/tmp/whystack-health`
Variáveis	`ROOTPILOT_OTEL_ENABLED`, `ROOTPILOT_OTEL_EXPORTER`, `ROOTPILOT_PII_REDACTION`	`WHYSTACK_OTEL_ENABLED`, `WHYSTACK_OTEL_EXPORTER`, `WHYSTACK_PII_REDACTION`
Namespace, StatefulSet, Service e NetworkPolicy do Kubernetes	`rootpilot-agent`	`whystack-agent`
ConfigMap e Secret do Kubernetes	`rootpilot-agent-config`, `rootpilot-agent-env`	`whystack-agent-config`, `whystack-agent-env`
Label `part-of` do Kubernetes	`rootpilot`	`whystack`
Audiência do token OIDC (`gke-oidc`)	`rootpilot-enroll`	`whystack-enroll`
Serviço e volume de identidade no Compose	`rootpilot-agent`, `rootpilot-identity`	`whystack-agent`, `whystack-identity`
Perfil AppArmor do Profiler	`rootpilot-profiler`	`whystack-profiler`
Telemetria, se você a exporta	spans, métricas e atributos `rootpilot.*`; serviços `rootpilot-runner`, `rootpilot-profiler`	`whystack.*`; serviços `whystack-runner`, `whystack-profiler`

Reinstalar

Os nomes novos não atualizam a instalação anterior no lugar: criam uma nova ao lado. É isso que você quer. Suba o Agent novo, confirme, e só então remova o anterior. Dois Agents da mesma organização lado a lado por alguns minutos não é problema, porque cada um tem a própria identidade.

Primeiro o egress. Libere tunnel.whystack.ai:8443, e app.whystack.ai:443 se o Agent faz o enrollment automático, antes de o Agent novo subir. Ver Requisitos.
Imagem. Puxe whystack-agent (e whystack-profiler) por digest, e confira a assinatura com a identidade nova, como em Imagem do container. O repositório anterior não recebe versões novas.
Variáveis. Renomeie as três variáveis da tabela no seu ambiente, Secret ou secret manager, e aponte RUNNER_TUNNEL_URL e RUNNER_ENROLL_URL para os hostnames novos.
Kubernetes. Baixe a base da versão nova e aplique o seu overlay sobre ela (Kubernetes). Crie o Secret whystack-agent-env no namespace whystack-agent com um bootstrap token novo. Com gke-oidc, troque a audience do token projetado para whystack-enroll no seu patch. Quando o pod novo mostrar hello accepted, apague o namespace anterior, que leva junto o PVC e a identidade anteriores:
Janela do terminal
```
kubectl delete namespace rootpilot-agent
```
Docker Compose. Renomeie o serviço e o volume no seu arquivo. O volume novo começa vazio, então o Agent faz o enrollment de novo: dê a ele um bootstrap token novo em RUNNER_BOOTSTRAP_TOKEN para o primeiro boot (Docker Compose). O docker compose up -d --remove-orphans para o container anterior. Remova o volume anterior quando o Agent novo estiver na Frota.
Profiler. Carregue o perfil AppArmor com o nome novo (AppArmor) e troque o security_opt para apparmor=whystack-profiler. Depois descarregue o anterior:
Janela do terminal
```
sudo apparmor_parser -R /etc/apparmor.d/rootpilot-profiler
sudo rm /etc/apparmor.d/rootpilot-profiler
```
As suas próprias verificações. Probes, healthchecks ou scripts que chamam o comando de saúde pelo nome passam para whystack-health. Dashboards e alertas sobre a telemetria do Agent passam para whystack.*; o histórico de antes da 1.29.0 fica com os nomes anteriores.

O que segue funcionando por enquanto

A imagem mantém alguns fallbacks para que uma instalação que passa para a 1.29.0 antes de ser reinstalada não quebre. Eles saem numa versão posterior, anunciada nas notas da release:

rootpilot-health é um link para whystack-health, então os probes e healthchecks anteriores continuam passando.
ROOTPILOT_OTEL_ENABLED, ROOTPILOT_OTEL_EXPORTER e ROOTPILOT_PII_REDACTION continuam sendo lidas quando o nome WHYSTACK_* não está definido. Se as duas existirem, a nova vence.
Os hostnames anteriores e a audiência rootpilot-enroll seguem funcionando durante a transição.
O Agent aceita um certificado em qualquer um dos dois trust domains do SPIFFE. O control-plane ainda emite spiffe://rootpilot/tenant/<slug>/runner, que é o que a linha enrolled do log mostra, e passa a spiffe://whystack/tenant/<slug>/runner mais adiante. Os dois nomeiam a mesma organização.