[App Service] Allow creating a service plan as part of web app creation

[lostintangent]

Being able to create a new web app as part of an existing plan makes a ton of sense, but I can't help but feel like it would simplify the getting started experience for users if the az appservice web create command would allow you to auto-create the plan for you, instead of needing to explicitly run az appservice plan create before hand. This would mirror the experience in the portal a little more closely, and optimize for single app plans.

I really like how the az acs create command chose to auto-generate a new service principal for you if you don't specify one, and I feel like this is another opportunity to streamline the experience, while still providing sufficient flexibility when/if needed.

[tjprescott]

Yugang Wang (@yugangw-msft) we should discuss how to implement this.

1. It will certainly involve shifting from SDK based creation to template based.
2. Should we expose the 4 service plan create parameters on web app create? This would result in an extra "Service Plan" group and additional validation to ensure that the extra parameters are only used when creating a new service plan.
3. Or should we expose the ability to add web app(s) when creating the service plan? This would only involve a single extra, optional parameter on appservice plan create.
4. Or we could leave it as is. :P

[lostintangent]

I would vote for #2, which keeps the focus on the web app, and abstracts away the concept of a plan (until the user wants/needs to know about it).

I'd imagine that the plan's SKU is the primary option that you'd need to set at the time of web app creation. Ideally, --is-linux will default to true once web apps on Linux GAs (since this CLI is pretty Linux-centric), and location/name/resource group could be mostly derived from the web app itself.

The following would be amazing for creating a new web app in a free tier plan:

az appservice web create -n <name> -g <group> -s free

The existing -p argument could allow suppressing the creation of the plan if it already existed (when creating a new web app that's associated with an existing plan), or it could allow customizing the plan name if it didn't already exist (similar to have vm create works with sub-resources).

Additionally, I wonder whether it would be useful if calling web create in a resource group that already had a plan, would associate it with that plan, instead of creating a new one. Unless the web create command explicitly specified a plan name that didn't already exist. That would be similar to the behavior of vm create when it comes to many sub-resources (e.g. vnet).

[yugangw-msft]

Jonathan Carter (@lostintangent)
My PR pretty much does you suggested except when an existing plan was spotted in the same RG to reuse, I will error out if users specified arguments which will not be used anymore like --sku. I could apply those values and update the existing plan, but I feel that is too much and potentially we will do things users would not like as updating a plan will impact all webapp inside.

[lostintangent]

Yugang Wang (@yugangw-msft) That behavior makes sense. Thanks so much!

[nickwalkmsft]

I went hunting for this capability today and was surprised to find #2550, but then saw it was backed out in #2671.

Obviously a lot has changed since then, particularly the introduction of webapp up, which effectively implements this feature but brings a lot of other stuff with it. Has plan autocreation as part of webapp create received any further consideration?

My use case for this feature: I write Azure tutorial content for MS Learn. Many tutorials require creating a web app, but only to showcase another Azure feature or service and not as the focus of the tutorial. In these cases, we still still typically have the reader create the web app or other needed resource directly, in a hands-on way (as opposed to fully automating the process in an opaque script), but we try to do it in a way that minimizes potential distraction. Most of the time, that means using the CLI with as few commands/arguments/etc. as possible.

webapp up is awesome, but we can't use it in Learn: the permissions model used by the Learn sandbox prevents users from creating new resource groups, which up requires. Additionally, many of our scenarios don't involve deploying from local source code.

It would be great to be able to create a web app and the needed plan in a one-liner. As Jonathan Carter (@lostintangent) said in the original comment, this would mirror the portal experience nicely.

Thanks!