Continued issue with backend docker deployment

[atockar]

Hi, I am still getting this issue. I have tried to deploy using the one click deployment and it fails in the same place,

I can see the bicep file has been updated in the code, and I added the storage blob data contributor role for the storage account to the function app:

add the storage blob data contributor and storage data reader roles to the managed identity of the function app and ensure that when deploying solution you have in bicep file @Allowed(['Enabled', 'Disabled']) param publicNetworkAccess string = 'Enabled'

However when I redeploy this section it asks for the clientKey, which I thought was generated. Any ideas?

Originally posted by @atockar in #1195 (comment)

[Roopan-Microsoft]

Thanks @atockar for raising the issue, we are looking into this and will keep you posted.

[Roopan-Microsoft]

Hey @atockar,

Could you please provide us with more details about the exception you’re encountering?

We’ve been able to deploy the accelerator successfully on our end, so we’d like to investigate further if you could share more information about the error you're experiencing.

[atockar]

I believe I found the source of the issue - it fails when I use a B1 hosting plan. See if you're able to replicate, thanks

[Roopan-Microsoft]

Hey @atockar,
Thanks for finding out! I'll try replicating the issue with a B1 hosting plan and let you know what I find. I'll get back to you soon.

[Roopan-Microsoft]

Yes @atockar, You are right! choosing this Sku plan throwing an error. We are looking into it. Thanks.

Meanwhile you can proceed with default Sku plans for now. We will update you on the root cause.

[TBunkley]

I'm having issues with this. What are the default settings? Basic pops up first for me

[Roopan-Microsoft]

Hey @TBunkley, Thanks for reaching out to us.

As you may know, the B1 plan includes one core, whereas the B3 plan offers four cores. Additionally, as shown in the screenshot below, we have less RAM, which is contributing to slower function app deployment. The default timeout is set to 300 seconds, resulting in failures.

We are currently looking into potential solutions for this issue.