Azure-cli: `webapp create`: stack trace when plan not found

Created on 20 Mar 2018 · 6Comments · Source: Azure/azure-cli

When I run

az webapp create -n <project-name> -g <resource-group> -p <plan>

If <plan> has the same resource group as the webapp I am creating (<resource-group>) then it works fine, but I want to be able to create a webapp inside a different resource group from the plan.

When I run it and they resource group does not match up then I get this ouptut

'NoneType' object has no attribute 'reserved'
Traceback (most recent call last):
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/knack/cli.py", line 194, in invoke
    cmd_result = self.invocation.execute(args)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 344, in execute
    cmd.exception_handler(ex)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/command_modules/appservice/commands.py", line 51, in _polish_bad_errors
    raise ex
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 319, in execute
    result = cmd(params)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 180, in __call__
    return super(AzCliCommand, self).__call__(*args, **kwargs)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/knack/commands.py", line 109, in __call__
    return self.handler(*args, **kwargs)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/core/__init__.py", line 418, in default_command_handler
    result = op(**command_args)
  File "/usr/local/Cellar/azure-cli/2.0.29/libexec/lib/python3.6/site-packages/azure/cli/command_modules/appservice/custom.py", line 59, in create_webapp
    is_linux = plan_info.reserved
AttributeError: 'NoneType' object has no attribute 'reserved'

Environment summary

Install Method (e.g. pip, interactive script, apt-get, Docker, MSI, edge build) / CLI version (az --version) / OS version / Shell Type (e.g. bash, cmd.exe, Bash on Windows)

azure-cli (2.0.29)

acr (2.0.22)
acs (2.0.28)
advisor (0.5.0)
appservice (0.1.29)
backup (1.0.7)
batch (3.1.11)
batchai (0.1.6)
billing (0.1.7)
cdn (0.0.13)
cloud (2.0.12)
cognitiveservices (0.1.11)
command-modules-nspkg (2.0.1)
configure (2.0.14)
consumption (0.2.2)
container (0.1.19)
core (2.0.29)
cosmosdb (0.1.19)
dla (0.0.18)
dls (0.0.19)
eventgrid (0.1.11)
eventhubs (0.1.0)
extension (0.0.10)
feedback (2.1.0)
find (0.2.8)
interactive (0.3.17)
iot (0.1.18)
keyvault (2.0.20)
lab (0.0.17)
monitor (0.1.3)
network (2.0.25)
nspkg (3.0.2)
profile (2.0.20)
rdbms (0.1.0)
redis (0.2.11)
reservations (0.1.1)
resource (2.0.25)
role (2.0.20)
servicebus (0.1.0)
servicefabric (0.0.11)
sql (2.0.23)
storage (2.0.27)
vm (2.0.28)

Extensions:
webapp (0.1.2)

Python location '/usr/local/opt/python/bin/python3.6'
Extensions directory '/Users/johnmathews/.azure/cliextensions'

Python (Darwin) 3.6.4 (default, Mar  9 2018, 23:15:03)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]

Legal docs and information: aka.ms/AzureCliLegal

Web Apps bug

Source

john-mathews

👍1

Most helpful comment

You need to path the plan as a resource id, not just the name
you can get the resource id using the
az appservice plan show -n plan-name -g plan-rg

the resource id, then can be passed to the az webapps create command as the plan name.

ahmedelnably on 20 Mar 2018

👍4

All 6 comments

You need to path the plan as a resource id, not just the name
you can get the resource id using the
az appservice plan show -n plan-name -g plan-rg

the resource id, then can be passed to the az webapps create command as the plan name.

ahmedelnably on 20 Mar 2018

👍4

@ahmedelnably is correct as this is the standard pattern across the CLI.

However, since the custom logic results in a stack trace, that piece would be considered a bug.

tjprescott on 20 Mar 2018

👍1

Agree with @tjprescott, anytime there is a stack trace, this should be handled by the command

ahmedelnably on 20 Mar 2018

@john-mathews, can you please cross check the plan exists or not? CLI does handle plans coming from other resource groups, but there has been a breaking change in appservice's sdk that it started to accept HTTP 404 as a valid return code on GET. Were not allowed, users should see a clear error telling them that the plan doesn't exist