Don't remove azure files connection string on premium deployment

[ColbyTresness]

"If the azure files connection string is set (which is expected), it is removed by VS code as part of the deployment, and this makes the deployment fail and breaks the app unless the user adds the appsetting back manually.

Steps to repro are simple. Use the old create to make an elastic premium linux javascript app that correctly has azure files set. Then go to VS code, make a new javascript function app and deploy. It will hang and the users function app will go down."

[ejizba]

Here is our current logic:

1. Windows:
   1. On creation:
      1. Set CONTENT* settings
      2. Set WEBSITE_RUN_FROM_PACKAGE to 1
   2. On deploy: no validation of settings
2. Linux:
   1. On creation: Do not set CONTENT* settings or PACKAGE settings
   2. On deploy:
      1. Remove CONTENT* settings if they exist
      2. If using remote build:
         1. Remove 'WEBSITE_RUN_FROM_ZIP' and 'WEBSITE_RUN_FROM_PACKAGE'
         2. If Dedicated plan, add 'ENABLE_ORYX_BUILD', 'SCM_DO_BUILD_DURING_DEPLOYMENT', 'BUILD_FLAGS', and 'XDG_CACHE_HOME'
      3. If Consumption and not using remote build: Set 'WEBSITE_RUN_FROM_PACKAGE' to blob url

@paulbatum a few questions to confirm:

1. Should linux premium have the same behavior as Windows? Even including RUN_FROM_PACKAGE setting?
2. Is the Linux behavior still fine for consumption/dedicated?
3. Any other changes we need to do?

[paulbatum]

I'm having a bit of trouble answering because the logic you pasted above doesnt seem to cover all the cases (for example, whether you create the content* settings should be different between windows dedicated and windows consumption). Trying my best:

1. The create experience for linux premium should match the "old portal create" i.e it should include the content* settings. The deploy experience should not remove these settings. I'm not proposing any change regarding run-from-package.
2. This issue is specifically about the premium behavior. The content* settings should not be used for linux consumption and linux dedicated.
3. Should be captured in other issues.

[ejizba]

Can you just list out all of the cases and when we're supposed to set the CONTENT settings? I didn't split out Windows because we treat them all the same today. Also can you describe when we need to validate the settings on deploy and when we don't? For example per #625 having the CONTENT settings on linux would break deploy (so we validated), but didn't seem to make much of a difference on Windows (so we didn't validate)

[paulbatum]

The content settings determine where /home is mounted. If you don't have these settings, then the default is to use the Azure App Service built in file storage. The problem with the built-in storage is that it does not work across scale units, so once the app needs to scale to multiple scale units, content settings are needed. In Linux consumption, there is no persistent home drive.

OS	SKU	Should have CONTENT*
Windows	Consumption	✔️
Windows	Dedicated	❌
Windows	Elastic Premium	✔️
Linux	Consumption	❌
Linux	Dedicated	❌
Linux	Elastic Premium	✔️

I don't really have much context on why the "remove settings on deployment" was added. That basically sounds like VS code trying to fix up a broken app, but I'm probably missing something.

It does make sense to me that VS code explicitly sets run from package in an number of scenarios, because we are trying to aggressively default users to this mode given how much better we can optimize cold start and how much more reliable package based deployments are.

[ejizba]

Okay I can change content settings as you described.

I don't really have much context on why the "remove settings on deployment" was added. That basically sounds like VS code trying to fix up a broken app, but I'm probably missing something.

Uh I wouldn't say "broken" app. The portal used to add those settings to support in-portal editing and thus it was a pretty common situation we had to handle. Since in-portal editing is no longer supported (right?) perhaps we don't need to remove CONTENT* settings anymore?

[paulbatum]

Got it. Thats the context I was missing, though I'm still not sure that I can recommend a change regarding that behavior. The key point is that the behavior you implemented for removing these settings should have only applied to linux consumption (which I suspect we failed to communicate).

Also it would be good if you can confirm for me - the only delta between the table above and the current behavior should be how the elastic linux premium case is handled.

[ejizba]

The only other delta from the table is Windows Dedicated

[paulbatum]

huh. ok I need to think about that. Maybe my above table is wrong re: dedicated because it will make it harder for people to switch SKUs once we support that.