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

Support Application Gateway autoscaling #2603

Closed
dmaltsiniotis opened this issue Jan 4, 2019 · 5 comments · Fixed by #3353
Closed

Support Application Gateway autoscaling #2603

dmaltsiniotis opened this issue Jan 4, 2019 · 5 comments · Fixed by #3353

Comments

@dmaltsiniotis
Copy link

dmaltsiniotis commented Jan 4, 2019

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.11.11

  • provider.azurerm v1.20.0

Affected Resource(s)

  • azurerm_application_gateway

Terraform Configuration Files

variable "tenant_id" { }
variable "subscription_id" { }
variable "client_id" {}
variable "client_secret" {}
variable "location" {
    default = "centralus"
}

locals {
    ipAddressSku = "Standard"
    ipAddressAllocationType = "Static"
    resource_group_name = "terraform_appgw_test"
}

provider "azurerm" {
  tenant_id       = "${var.tenant_id}"
  subscription_id = "${var.subscription_id}"
  client_id       = "${var.client_id}"
  client_secret   = "${var.client_secret}"
}

resource "azurerm_resource_group" "test" {
  name     = "${local.resource_group_name}"
  location = "${var.location}"
}

resource "azurerm_virtual_network" "test" {
  name                = "virtualNetwork1"
  location            = "${azurerm_resource_group.test.location}"
  resource_group_name = "${azurerm_resource_group.test.name}"
  address_space       = ["10.0.0.0/16"]
}

resource "azurerm_subnet" "subnet1" {
  name                 = "subnet1"
  resource_group_name  = "${azurerm_resource_group.test.name}"
  virtual_network_name = "${azurerm_virtual_network.test.name}"
  address_prefix       = "10.0.1.0/24"
}

resource "azurerm_public_ip" "APPGW_01" {
  name = "APPGW-01"
  sku = "${local.ipAddressSku}"
  location = "${azurerm_resource_group.test.location}"
  resource_group_name = "${azurerm_resource_group.test.name}"
  public_ip_address_allocation = "${local.ipAddressAllocationType}"
}

locals {
  frontend_port_name_http = "http_frontend_port"
  frontend_port_name_https = "https_frontend_port"
  frontend_ip_configuration_name = "PublicFrontendIPConfig"
  appgw_backend_pool_name = "Untrusted"
}

resource "azurerm_application_gateway" "APPGW_01" {
  name = "APPGW-01"
  resource_group_name = "${azurerm_resource_group.test.name}"
  location = "${azurerm_resource_group.test.location}"

  sku {
    name = "Standard_v2"
    tier = "Standard_v2"
    capacity = "0" # I would expect 0 to work with the Standard_v2 sku, since 0 indicates auto-scaling.
  }

  gateway_ip_configuration {
    name = "gateway-ip-configuration"
    subnet_id = "${azurerm_subnet.subnet1.id}"
  }

  frontend_port {
    name = "${local.frontend_port_name_http}"
    port = 80
  }

  frontend_port {
    name = "${local.frontend_port_name_https}"
    port = 443
  }

  frontend_ip_configuration {
    name = "${local.frontend_ip_configuration_name}"
    public_ip_address_id = "${azurerm_public_ip.APPGW_01.id}"
  }

  backend_address_pool {
    name = "${local.appgw_backend_pool_name}"
  }

  backend_http_settings {
    name = "settings-http"
    cookie_based_affinity = "Disabled"
    port = 80
    protocol = "Http"
    request_timeout = 30
  }

  http_listener {
    name = "listener-http"
    frontend_ip_configuration_name = "${local.frontend_ip_configuration_name}"
    frontend_port_name = "${local.frontend_port_name_http}"
    protocol = "Http"
  }

  request_routing_rule {
    name = "rule-http"
    rule_type = "Basic"
    http_listener_name = "listener-http"
    backend_address_pool_name = "${local.appgw_backend_pool_name}"
    backend_http_settings_name = "settings-http"
  }
}

Debug Output

https://gist.github.com/dmaltsiniotis/9d2259808586c081ea46c790999ba481

Panic Output

N/A

Expected Behavior

The application gateway validation should pass, and provision normally.

Actual Behavior

The following error is observed when trying to run a plan:

Error: azurerm_application_gateway.APPGW_01: expected sku.0.capacity to be in the range (1 - 10), got 0

Steps to Reproduce

  1. `terraform plan'

Important Factoids

Azure application gateway v2's are very new and behave differently from standard gateways. Even the azure web portal does not yet have all the configuration options for the v2 gateways. This may necessitate a significant change to the validation logic for application gateways.

When setting the scaling to "automatic" in azure for a v2 application gateway, it's pulled back as having capacity zero by the azurerm provider for exiting resources.

References

Here is the PR originally adding the SKU's, but not adjusting the capacity validation:

@dmaltsiniotis
Copy link
Author

dmaltsiniotis commented Jan 4, 2019

I was able to modify the provider to check for 0-10 and it seemed to solve the error, if this is an acceptable solution, I can submit the pull request. This does, however, break validation for non-v2 sku's since they must be greater than zero. Perhaps some kind of custom validation based on the sku is needed?

Upon further debugging, this seems to be a deeper issue of not being able to select auto-scaling, not just a capacity of 0. I tried to apply a "0" capacity after updating the plugin, and received a azure validation error:

* azurerm_application_gateway.APPGW_01: Error Creating/Updating Application Gateway "APPGW-01" (Resource Group "terraform_appgw_test"): network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code="ApplicationGatewaySkuCapacityNotValid" Message="Sku Capacity 0 specified for Sku Tier Standard_v2 is not valid. Valid value is in the range of [1-200]" Details=[]

@dmaltsiniotis
Copy link
Author

I think this bug report may need to be closed in favor of a feature request to support auto-scaling feature of application gateway v2.

@katbyte katbyte changed the title Application gateway v2 "capacity" validation error Support Application Gateway autoscaling Jan 5, 2019
@katbyte
Copy link
Collaborator

katbyte commented Jan 6, 2019

Hi @dmaltsiniotis,

Thanks for opening this issue, it does appear that some changes will be required. Looking at the documentation it seems that when you configure auto scaling you don't set that capacity on the sku, but add a new min capacity parameter:

$autoscaleConfig = New-AzureRmApplicationGatewayAutoscaleConfiguration -MinCapacity 2
$sku = New-AzureRmApplicationGatewaySku -Name Standard_v2 -Tier Standard_v2

So to use autoscaling capacity becomes min capacity and is placed elsewhere. Ideally a new property autoscale.0.min_capacity should be created and sku.0.capacity changed to optional. Additional validation will be required to ensure all required values are present and nothing conflicts.

We can keep this issue and i've renamed it to reflect as such 🙂

@timja
Copy link
Contributor

timja commented May 1, 2019

PR up: #3353

@ghost
Copy link

ghost commented Jun 7, 2019

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 and limited conversation to collaborators Jun 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants