Azure FrondDoor: Spec incorrect or Service API misbehaving

[lawrencegripper]

Hi,

I'm using the Go SDK for Azure here https://github.com/lawrencegripper/azurefrontdoor-ingress to talk to Azure Frontdoor.

I see errors when using any of the individual resource clients. An InvalidResourceType response is returned when attempting to update/get or list the following:

• /Microsoft.Network/Frontdoors/lgtestfrontdoor/LoadBalancingSettings
• /Microsoft.Network/Frontdoors/lgtestfrontdoor/backendPools
• /Microsoft.Network/Frontdoors/lgtestfrontdoor/healthProbeSettings

Here is a quick example, the behavior isn't limited to the Go SDK as attempting to browse these resources using resources.microsoft.com also returns the same errors.

curl 'https://resources.azure.com/api/operations' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: en-GB,en;q=0.5' --compressed -H 'Referer: https://resources.azure.com/subscriptions/your-sub-id-here/resourceGroups/temp-frontdoortest/providers/Microsoft.Network/frontDoors/lgtestfrontdoor/frontendEndpoints' -H 'Content-Type: application/json;charset=utf-8' -H 'Cookie: [object Object]' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Pragma: no-cache' -H 'Cache-Control: no-cache' --data '{"Url":"https://management.azure.com/subscriptions/your-sub-id-here/resourceGroups/temp-frontdoortest/providers/Microsoft.Network/frontDoors/lgtestfrontdoor/routingRules","HttpMethod":"GET","ApiVersion":"2018-08-01"}'

Response

HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Length: 107
Content-Type: application/json; charset=utf-8
Content-Language: en-US
Server: Microsoft-IIS/8.5
Strict-Transport-Security: max-age=31536000; includeSubDomains
x-ms-ratelimit-remaining-subscription-reads: 11998
x-ms-request-id: 2ae5e8a7-b232-474a-bb52-3720abbb570b
x-ms-correlation-request-id: 2ae5e8a7-b232-474a-bb52-3720abbb570b
x-ms-routing-request-id: WESTUS:20181011T212358Z:2ae5e8a7-b232-474a-bb52-3720abbb570b
X-Content-Type-Options: nosniff
X-AspNet-Version: 4.0.30319
X-MS-Ellapsed: 392ms
Request-Context: appId=cid-v1:a7a0aa45-52ad-43f4-a8c4-8896f1392829
instance-name: explorer-bay
X-Powered-By: ASP.NET, ASP.NET
Date: Thu, 11 Oct 2018 21:23:58 GMT

{
  "error": {
    "code": "InvalidResourceType",
    "message": "The resource type is invalid."
  }
}

Sample from GOSDK with HTTP Traces on

INFO[0001] PUT /subscriptions/your-sub-here/resourceGroups/temp-frontdoortest/providers/Microsoft.Network/Frontdoors/lgtestfrontdoor/LoadBalancingSettings/loadBalancingSettings-1539281898722?api-version=2018-08-01 HTTP/1.1
Host: management.azure.com
User-Agent: Go/go1.10.1 (amd64-linux) go-autorest/v10.15.5 Azure-SDK-For-Go/v21.1.0 frontdoor/2018-08-01-preview
Content-Length: 95
Authorization: Bearer *removed*
Content-Type: application/json; charset=utf-8
Accept-Encoding: gzip

{"properties":{"sampleSize":4,"successfulSamplesRequired":2,"additionalLatencyMilliseconds":0}} 

INFO[0001] HTTP/1.1 400 Bad Request
Content-Length: 107
Cache-Control: private
Content-Language: en-US
Content-Type: application/json; charset=utf-8
Date: Thu, 11 Oct 2018 20:28:41 GMT
Server: Microsoft-IIS/8.5
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Aspnet-Version: 4.0.30319
X-Content-Type-Options: nosniff
X-Ms-Correlation-Request-Id: 054cedff-75ed-4d27-a954-76f58ed1743b
X-Ms-Ratelimit-Remaining-Subscription-Writes: 1199
X-Ms-Request-Id: 054cedff-75ed-4d27-a954-76f58ed1743b
X-Ms-Routing-Request-Id: WESTUS:20181011T202842Z:054cedff-75ed-4d27-a954-76f58ed1743b
X-Powered-By: ASP.NET

{
  "error": {
    "code": "InvalidResourceType",
    "message": "The resource type is invalid."
  }
} 

[sabbour]

I can confirm the same behavior.

GET /subscriptions/<sub id>/resourcegroups/<rg>/providers/Microsoft.Network/frontdoors/<frontdoor name>/backendPools?api-version=2018-08-01 HTTP/1.1
Host: management.azure.com
Authorization: Bearer eyJ0eXA..POGwA
Cache-Control: no-cache

{
    "error": {
        "code": "InvalidResourceType",
        "message": "The resource type is invalid."
    }
}

[sabbour]

According to https://github.com/Azure/azure-rest-api-specs/blob/5682ce2525b7fa4b3115938a948af3bc46d6387f/specification/frontdoor/resource-manager/Microsoft.Network/preview/2018-08-01-preview/frontdoor.json#L947 it should work

[lawrencegripper]

Thanks @sabbour glad to know its not just me missing something. @marstr Are they're anymore details you need on this one or is it case of waiting for a response from the frontdoor team now?

[marstr]

Waiting on the frontdoor team. They should get looped in automatically with the labels I just added.

[marstr]

Removing my assignment because this issue is triaged

[lawrencegripper]

@sabbour I found a workaround but it doesn't seem to behave quite right for my scenario. However, it may be useful to you, in this PR I move to using the FrontDoorsClient not FrontDoorClient this allows you to GET and PUT the entire Frontdoor state in one call rather than talking to the subresources. I talk about the issue I see with stale reads in the PR details.

[lawrencegripper]

Hi, Any update on this issue?

[timja]

@marstr has this been seen by the frontdoor team?

[marstr]

I'm not sure of the current status. Looks like the current assignees are Network team members. I've been transitioned onto a different team, so I'm not in the day-to-day loop here.

[timja]

Ah sorry missed the assignees, @gmainar / @jmelvinwork do you have any update on this Azure Front Door API issue?

[jmelvinwork]

I have moved to another team. Please follow up with @johncrane .

[rhummelmose]

Is the Front Door team not using Github? Could we please get some attention to this issue, it's blocking a welcomed implementation of an Ingress controller for Kubernetes.

[jessicl-ms]

Hello, this issue has been recently brought to the attention of the Front Door team.

Front Door recently corrected their SDK and documentation to remove CRUD on these sub-resources. Updates to Front Door must be invoked on the entire Front Door object.

Unfortunately, the old SDK generated with these API will continue to have these sub-fields, causing confusion among customers.

[lawrencegripper]

How can this API support writing from multiple user? Say you have two machines which are updating the same frontdoor instance, as they have to put the whole object it's likely they'll overwrite each other's changes.

Do you support an etag or updateif or patch?

[jessicl-ms]

You are correct. If you have two machines updating the same front door instance, the update operations will happen in series and the last writer will win.

We currently do not support etag or updateif or patch.

[lawrencegripper]

I had a bit of a play and this is likely to effect users who make updates in the portal too.

When I do an update in the portal PUT's the whole frontdoor resource. If I've edited routes and another admin edits backend rules we'd trample on each others changes rather than see an error. Feels like that is going to hurt someone.

[Evilweebl]

Are there any plans to bring back CRUD functionality to these subresources? We currently have several microsites each owning their own IAC. In the current scenario they cannot independently add their own backend pools/routes/front ends so instead we are forced to have a central IAC repo for front door that must be kept up to date with knowledge of all products which is quite counter productive.

[brion-fuller]

This is a huge blocker for my team when thinking of using this product. Is there any plan to have machines register independently to frontdoor?