Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add check for functionApp kind and dynamic sku tier - "azurerm_app_service_plan" #7971

Closed
wants to merge 3 commits into from

Conversation

njuCZ
Copy link
Contributor

@njuCZ njuCZ commented Jul 31, 2020

fix #4396
fix #5971

  1. the backend service will always change the kind to functionapp if sku tier is dynamic. will change kind to elastic if sku tier is ElasticPremium. add check to avoid such config.
  2. update doc about reserved

Copy link
Contributor

@tombuildsstuff tombuildsstuff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @njuCZ

Thanks for this PR - apologies for the delayed review here!

I've taken a look through and left some comments inline - if we can fix those up then we should be able to take another look

Thanks!

@@ -117,7 +117,7 @@ The following arguments are supported:

~> **NOTE:** Attaching to an App Service Environment requires the App Service Plan use a `Premium` SKU (when using an ASEv1) and the `Isolated` SKU (for an ASEv2).

* `reserved` - (Optional) Is this App Service Plan `Reserved`. Defaults to `false`.
* `reserved` - (Optional) Specifies whether it's Linux Platform. Should be `true` If Linux app service plan, false otherwise. Defaults to `false`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isn't just for Linux - this specifies if the App Service Plan should be always running or start/stopped on demand

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This field name is very misleading. According to https://docs.microsoft.com/en-us/rest/api/appservice/appserviceplans/createorupdate#request-body, it says If Linux app service plan true, false otherwise..

According to the implementation of azure.cli: https://github.com/Azure/azure-cli/blob/dev/src/azure-cli/azure/cli/command_modules/appservice/custom.py#L1648
users could specify the flag "--is-linux", and azure.cli will convert it to reserved field.

I have also emailed the service team, they says "reserved" means the OS type, "kind" is just a ARM level field, it's only used to drive the UX. It's not needed when creating. Azure.cli doesn't have the argument "kind".

Currently I think it's a little messy for resource "azurerm_app_service_plan" to have both field "reserved" and "kind", though it's the fault of service api definition. There seems a issue fired by a member of the service team: #5584

what's more, the OS type of app_service and function_app is defined by the app service plan, but for now both resource have "os_type" field, it should be "computed: true".

I wonder could we fix these in version 3 ?

@@ -197,6 +197,14 @@ func resourceArmAppServicePlanCreateUpdate(d *schema.ResourceData, meta interfac
return fmt.Errorf("`reserved` has to be set to false when kind is set to `Windows`")
}

if strings.EqualFold(*sku.Tier, "Dynamic") && !strings.EqualFold(kind, "FunctionApp") {
return fmt.Errorf("`kind` has to be set to `FunctionApp` when `sku.tier` is `Dynamic`")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't Dynamic available for Consumption Plan Web Apps too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this PR is just a workaround. kind should not be input by user, the backend service will calculate the value for kind. But to avoid breaking change, and to make user use it correctly, I added this constraints.

the backend service will always change the kind to functionapp if sku tier is dynamic. will change kind to elastic if sku tier is ElasticPremium.

@@ -197,6 +197,14 @@ func resourceArmAppServicePlanCreateUpdate(d *schema.ResourceData, meta interfac
return fmt.Errorf("`reserved` has to be set to false when kind is set to `Windows`")
}

if strings.EqualFold(*sku.Tier, "Dynamic") && !strings.EqualFold(kind, "FunctionApp") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's a crash here if sku.Tier is nil

return fmt.Errorf("`kind` has to be set to `FunctionApp` when `sku.tier` is `Dynamic`")
}

if strings.EqualFold(*sku.Tier, "ElasticPremium") && !strings.EqualFold(kind, "elastic") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there's a crash here if sku.Tier is nil

}

if strings.EqualFold(*sku.Tier, "ElasticPremium") && !strings.EqualFold(kind, "elastic") {
return fmt.Errorf("`kind` has to be set to `elastic` when `sku.tier` is `ElasticPremium`")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a test to check this?

@@ -197,6 +197,14 @@ func resourceArmAppServicePlanCreateUpdate(d *schema.ResourceData, meta interfac
return fmt.Errorf("`reserved` has to be set to false when kind is set to `Windows`")
}

if strings.EqualFold(*sku.Tier, "Dynamic") && !strings.EqualFold(kind, "FunctionApp") {
return fmt.Errorf("`kind` has to be set to `FunctionApp` when `sku.tier` is `Dynamic`")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we add a test to check this?

@njuCZ
Copy link
Contributor Author

njuCZ commented Aug 26, 2020

@tombuildsstuff I have replied some of your questions. After we have draw the conclusion, I would fix the rest suggestions.

@ghost ghost removed the waiting-response label Aug 26, 2020
@njuCZ njuCZ closed this Mar 26, 2021
@ghost
Copy link

ghost commented Apr 25, 2021

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked as resolved and limited conversation to collaborators Apr 25, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants