I'll preface this as very likely not a bug in the k8s agent helm charts themselves, but rather a possible existing limitation of the Octopus Deploy Tentacle executable?
For our deployments of the k8s agent, we've opted to pre-provision all our Deployment Target and Worker agents via the Terraform octopusdeploy_kubernetes_agent_deployment_target and octopusdeploy_kubernetes_agent_worker resources - this is mostly because we have used the legacy Kubernetes API targets for years via Terraform, and we continue to maintain constantly-varying tenant/environment/role bindings on our deployment targets within our Terraform codebase.
It seems either .agent.worker.initial.* or .agent.deploymentTarget.initial.* MUST be at least populated with something non-null and non-empty in order for the Tentacle to boot up - this is problematic for us as we don't want to maintain our tenant/environment/role bindings in two places (Terraform + our k8s agent values files).
With some experimentation I did find that populating these .agent.*.initial fields with dummy values does give the desired effect, where the Tentacle still registers against our pre-provisioned targets (matched up by target/machine name being equal on the server side and in the Tentacle configuration), and does not modify or purge the existing tenant/environment/role bindings already set by Terraform:
agent:
deploymentTarget:
enabled: True
initial:
tags: ["invalid"] # Managed by Terraform, though a dummy initial value is required for Tentacle to boot.
environments: ["invalid"] # Managed by Terraform, though a dummy initial value is required for Tentacle to boot.
tenantedDeploymentParticipation: TenantedOrUntenanted # Managed by Terraform, though a dummy initial value is required for Tentacle to boot.
Not a show-stopper at all given our workaround above, but it would be nice to have a chart-native "toggle" of sorts where you can declaratively state that an agent should register against an existing target and not have to supply any *.initial.* scope values that will be discarded anyway.
I'll preface this as very likely not a bug in the k8s agent helm charts themselves, but rather a possible existing limitation of the Octopus Deploy Tentacle executable?
For our deployments of the k8s agent, we've opted to pre-provision all our Deployment Target and Worker agents via the Terraform
octopusdeploy_kubernetes_agent_deployment_targetandoctopusdeploy_kubernetes_agent_workerresources - this is mostly because we have used the legacy Kubernetes API targets for years via Terraform, and we continue to maintain constantly-varying tenant/environment/role bindings on our deployment targets within our Terraform codebase.It seems either
.agent.worker.initial.*or.agent.deploymentTarget.initial.*MUST be at least populated with something non-null and non-empty in order for the Tentacle to boot up - this is problematic for us as we don't want to maintain our tenant/environment/role bindings in two places (Terraform + our k8s agent values files).With some experimentation I did find that populating these
.agent.*.initialfields with dummy values does give the desired effect, where the Tentacle still registers against our pre-provisioned targets (matched up by target/machine name being equal on the server side and in the Tentacle configuration), and does not modify or purge the existing tenant/environment/role bindings already set by Terraform:Not a show-stopper at all given our workaround above, but it would be nice to have a chart-native "toggle" of sorts where you can declaratively state that an agent should register against an existing target and not have to supply any
*.initial.*scope values that will be discarded anyway.