Could not find platform linux-x64 for Calamari.AzureWebApp

ben.hodges · 13 January 2023 15:42

We’re setting the pool using a project variable. When changing steps which use a pool called windows worker pool to use default worker pool it just fails with error Could not find platform linux-x64 for Calamari.AzureWebApp

What’s strange is the step it fails on ( DEPLOY AN AZURE WEB APP (WEB DEPLOY)) ) isn’t using the project variable to set the pool and instead has the default pool selected in the step. So why would a step which isn’t changing fail?

when the windows worker pool is selected we can see the name of a windows agent in the logs but when we change the variable to default pool instead of showing the default pool agent (the octopus server tentacle) it shows a linux agent even though we haven’t selected it and it’s set to default pool in the step.

patrick.smergut · 13 January 2023 18:52

Hi Ben,

Thanks for reaching out, and I’m sorry to hear you’re hitting that unexpected behavior with workers in your deployment.

First, could you provide me with your raw deployment task log so I can review this behavior in the log? You can use the following link to upload this to me securely, just let me know once you’ve done that as unfortunately I don’t get any sort of notification on my end when a file comes through:

Ben Hodges | Octopus Support

One question I also have is if you see a Linux worker under your Default Worker Pool (under Infrastructure > Worker Pools > Default Worker Pool)? For example:

I’m looking forward to hearing back from you!

Best,
Patrick

ben.hodges · 16 January 2023 09:24

Hey Patrick,

I’ve just shared those files with you.

Nope there isn’t a linux agent under that pool, it just uses the octo server.

adam.hollow · 16 January 2023 11:15

Hi @ben.hodges,

Thanks for sending over those log files.

I’ve taken a look and it appears that Octopus believes the target octol-se-54ccd65d6f-w8c2z is a Linux machine. If this is actually the case and that machine is a linux machine, then it appears that Octopus has incorrectly selected this worker as it’s target for this step.

Would you mind enabling variable logging, testing another deployment, and then sending over the new task log for that deployment, please?
The variable logging should assist us in identifying what Octopus believes the worker pool is upon starting that step.

Please let me know if you have any questions or concerns.

Kind Regards,
Adam

ben.hodges · 16 January 2023 13:16

Hey Adam,

This was exactly my findings. I’ve uploading new file for you with the two new variables.

adam.hollow · 16 January 2023 15:09

Hi @ben.hodges,

Thanks for sending those over but it doesn’t look like variable logging is enabled on those deployments.

May I ask if you created a new release or updated the variable snapshot? Without doing that the new variable wouldn’t make it into the deployment.

Kind Regards,
Adam

ben.hodges · 16 January 2023 15:27

Hey,

I created a new release, i can see it in the log?

adam.hollow · 16 January 2023 15:36

My apologies, @ben.hodges I couldn’t see it at first!

I’ll take a look over these now and be in touch once I’ve done so, thanks again.

Kind Regards,
Adam

adam.hollow · 16 January 2023 17:03

Hi @ben.hodges,

Strangely, it looks as though in the non-working example, Octopus believes the worker pool is set as following:

[env:TargetWorkerPool] = ‘kubernetes Worker Pool (Linux)’

This is identical to in the working task log, as if you search for “kubernetes Worker Pool (Linux)” in the log you can see the worker being leased from that pool.

Have you noticed this deployment failing on certain machines repeatedly and succeeding on others? Is there a pattern?

Kind Regards,
Adam

ben.hodges · 17 January 2023 14:30

Hey Adam,

No it literally only happens when i change the variable from windows pool to the default pool.

The step it fails on doesn’t use the variable though.

adam.hollow · 17 January 2023 15:22

Hi @ben.hodges,

When it comes to default worker pool, these worker pools can be set and the name “Default worker pool” isn’t always the default worker pool.

Inside Infrastructure → Worker Pools, you can select a worker pool and view if it’s set to default.
Would you be able to check the pool kubernetes Worker Pool (Linux) to see if this is set to default in the UI, please?

Kind Regards,
Adam

ben.hodges · 17 January 2023 15:49

Hey Adam,

That what one of the first things i checked sadly. By any chance would it have something to do with it being in another space that isn’t the default?
I.E the default worker pool has the octopus server on it even though it shows no workers, maybe that only works for the default pool?

patrick.smergut · 17 January 2023 22:59

Hi Ben,

Thanks for getting back to us with that additional information.

We’re still not sure what’s causing this behavior, but I was wondering if you’d be willing to test the following:

Create a new worker pool (using a desired name)
Set the newly created worker pool to ‘Default’
Assign the worker pool in your deployment process

This new worker pool should essentially behave the same as the original ‘Default worker pool’ - since it doesn’t have any workers associated, it should use the built-in worker on the Octopus server.

I’m hoping this will help determine if using a new default worker pool works properly and points to the existing default worker pool having some strange issue associated with it.

Let me know what you find!

Best,
Patrick

ben.hodges · 18 January 2023 09:44

Hi Patrick,

No luck I’m afraid, I’ve uploaded some new files, perhaps you might spot something by seeing the steps.

adam.hollow · 18 January 2023 14:24

Hi @ben.hodges,

Thanks for uploading those files, I’ll take a look and get back to you.

Kind Regards,
Adam

adam.hollow · 18 January 2023 15:29

Hi @ben.hodges,

Looking at the screenshot of your deployment processes, it doesn’t look as though a variable is set for the worker pool. When I set a variable as a worker pool my step looks like the following:

The image of the worker pool tag displayed in your screenshot would indicate an explicitly selected worker pool.

Would you be able to send over the process JSON for the project, please? This should allow us to check to see if it’s just a UI difference or perhaps a bug in the UI when displaying the process.

Kind Regards,
Adam

ben.hodges · 20 January 2023 14:27

Hi Adam,

yes exactly, that’s what i meant on my first message “What’s strange is the step it fails on ( DEPLOY AN AZURE WEB APP (WEB DEPLOY)) ) isn’t using the project variable to set the pool and instead has the default pool selected in the step”

Sure, but the option to download json isn’t available for config as code so i’ve uploaded the doyment process ocl file instead.

thanks,
Ben

patrick.smergut · 24 January 2023 17:54

Hi Ben,

Thanks for getting back to us and for sending through that OCL file.

I think I’ve spotted the problem within your OCL, though I’m not sure how it would have ended up in its current state. Looking at the worker_pool_variable under your deploy-an-azure-web-app, I can see this is set to the following for the respective actions associated with that step:

action "start-aod-staging-slot", worker_pool_variable = "Octopus-LinuxWorkerPool"
action "deploy-an-azure-web-app-1", worker_pool_variable = "Octopus-WindowsWorkerPool"
action "restart-the-deployed-azure-web-app", worker_pool_variable = "Octopus-LinuxWorkerPool"
action "swap-aod-api-slots", worker_pool_variable = "Octopus-LinuxWorkerPool"

So likely the deployment is hitting the first action in the step and choosing a Linux worker from Octopus-LinuxWorkerPool.

It sounds like you’ve already attempted to change this in the UI and re-save, so I’m wondering if you’d be willing to test manually setting the worker_pool_variable in these actions to "", which should be the same as the Default worker pool. Hopefully, this allows those actions to align and work via the UI setting again.

Note that if you have existing branches based on this OCL process, you will need to update these from the source of truth (main), otherwise those branches won’t be updated with this change.

Let me know how it goes!

Best,
Patrick

ben.hodges · 31 January 2023 20:40

Hi,

That’s odd because deploy-an-azure-web-app-1 is currently set to worker_pool = "default-worker-pool". Not : worker_pool_variable = "Octopus-WindowsWorkerPool".

start-aod-staging-slot on the other hand is set to worker_pool_variable = "Octopus-WindowsWorkerPool"

On the other actions where they’re set to linux, it be better to keep with linux where possible.

Also unsure the issue has been identified still as like we mentioned, the step which fails isn’t changing as it doesn’t use a variable, the other linux steps you mentioned aren’t changing either as they use a lunux variable not a windows variable. The only steps which are changing are ones marked worker_pool_variable = "Octopus-WindowsWorkerPool" so we shouldn’t need to touch the linux steps.

patrick.smergut · 31 January 2023 23:51

Hi Ben,

Thanks for getting back to me and for the additional details.

My apologies, I see now that these are child steps beneath a parent step so it makes sense you have those set to different worker pools. There’s a possibility something strange is occurring as a result of these being child steps, so I’m looking further into this.

In the meantime, I was wondering if you’d be willing to provide me with your variables.ocl file for this project? You can scrub anything sensitive, I just want to make sure I have all the information to review and do further testing on my end. You can use the following link to provide these to me:

Ben Hodges | Octopus Support

Please let me know once you’ve done that as unfortunately I don’t get a notification on my end after a file has been uploaded.

Best,
Patrick