Powershell command for adding dynamic kube target ignores worker pool argument

Using version 2020.1.10

We are trying to register a Kubernetes target in one of our projects deployment steps. using New-OctopusKubernetesTarget The Kubernetes target is registered, however it is always registered using the default worker pool for communications. We can’t use the default worker pool for this purpose due to organization specific “reasons”. Instead we need to use a specific worker pool, and because it uses the default worker pool, the initial health check fails after calling New-OctopusKubernetesTarget and this causes the overall deployment to fail.

Running Get-Help New-OctopusKubernetsTarget lead to the discovery of the argument -octopusDefaultWorkerPoolIdOrName. However this argument does not appear to have any effect. I tried using the worker pool id, and the worker pool name. The target is always registered using the default worker pool.

The code in calamari is here on line 301: https://github.com/OctopusDeploy/Calamari/blob/release/2020.1/source/Calamari.Shared/Integration/Scripting/WindowsPowerShell/Bootstrap.ps1#L301 and everything appears fine on the powershell end. It looks to me like octopus server doesn’t pay attention to that paramater when it receives it in the service message sent from calamari.

Here is the exact script we are using in our deployment step. If it matters the deployment step is of type “run an inline script on a worker (windows worker, non-default pool)”. This is running as part of a deployment project, not a runbook.

$clusterArn = $OctopusParameters["Octopus.Action[Cloudformation].Output.AwsOutputs[ClusterArn]"]
$clusterUrl = $OctopusParameters["Octopus.Action[Cloudformation].Output.AwsOutputs[Endpoint]"]
$accountId = $OctopusParameters["aws_account"]
$clusterName = $OctopusParameters["Octopus.Action[Cloudformation].Output.AwsOutputs[Cluster]"]
$certId = $OctopusParameters["Octopus.Action[Bootstrap].Output.OctopusEKSCertId"]
$envName = $OctopusParameters["Octopus.Environment.Name"]
$workerPoolName = "$envName-linux"

New-OctopusKubernetesTarget `
    -name $clusterArn `
    -octopusRoles "some-rolename-here" `
    -clusterUrl $clusterUrl `
    -octopusAccountIdOrName $accountId `
    -clusterName $clusterName `
    -octopusServerCertificateIdOrName $certId `
    -updateIfExisting `
    -octopusDefaultWorkerPoolIdOrName "WorkerPools-241" `
    -skipTlsVerification $false

Hi @estubbs,

Thanks for getting in touch! I’m very sorry to hear you’re hitting this unexpected bug and for the inconvenience it has caused you. I’ve raised this at the following link to get investigated and fixed.

Thanks for bringing this to our attention, and please don’t hesitate to reach out if you have any questions or concerns moving forward!

Best regards,