-
Notifications
You must be signed in to change notification settings - Fork 424
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
InvalidResourceReference - urlPathMaps referenced by requestRoutingRules was not found #1685
Comments
Just confirmed that the issue starts appearing with version 1.7.5. Anything >1.7,4 produces the above issue in our setup, also checked 1.7.7 manually. With a (temporary) manual downgrade to 1.7.4, the controller is able to apply/process the configuration successfully.
|
I encountered this same issue. Oddly enough, it was present in the South Central US Region but not in East US despite both running 1.7.6. Azure support recommended that we migrate to the helm based install since the shared app gateway feature isn't supported for the add-on. |
Thanks for the addition. I assume I will be getting a similar recommendation from support (created a ticket yesterday). However from what I understand from the error I think the deployment method wont really have an impact on the issue. The only advantage would be that we could control the version to deploy and thus circumvent the issue by not upgrading. |
You are correct. I migrated our test cluster to the helm install this morning with 1.7.6 and it's failing with the same error. Downgrading to 1.7.4 resolves the issue, same behavior as the add-on. They kept our ticket open so I'll report this finding to them. |
I noticed that this only happens for a multi-path ingress deployment in cluster-b in my case. |
@halittiryaki yes, in my case there are multiple paths on both gateways in use. |
Discussion with Azure Support lead me to a solution and also a workaround for our current setup. Ideal solution is to go for a Helm deployment and use the appropriate values on deploy to configure it. Namely this at least needs This way all resources will be deployed with a prefix, which solves the issue in our environment. If however Helm is not an option just yet, the behavior can also be replicated by setting the values Hope this helps some out there. Will close this as provides a solution as well as a workaround. |
Describe the bug
We are using AGIC as an AKS addon but have it enabled to run in a shared App Gateway setup (added CRD AzureIngressProhibitedTarget and
APPGW_ENABLE_SHARED_APPGW: true
to the config map) between two clusters (DEV/TEST) which was working fine for the last ~2 years.After a recent change to an ingress we noticed nothing got updated and found the following error in the logs of the controller on the DEV environment.
E0127 14:58:16.128358 1 worker.go:72] Error processing event.network.ApplicationGatewaysClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidResourceReference" Message="Resource /subscriptions/company-subscription/resourceGroups/company-rg-1/providers/Microsoft.Network/applicationGateways/nonprod-public-agw-01/urlPathMaps/url-9cd989d2ce94d8d5b665a2c10b238fba referenced by resource /subscriptions/company-subscription/resourceGroups/company-rg-1/providers/Microsoft.Network/applicationGateways/nonprod-public-agw-01/requestRoutingRules/rr-9cd989d2ce94d8d5b665a2c10b238fba was not found. Please make sure that the referenced resource exists, and that both resources are in the same region." Details=[]
We are using a
AzureIngressProhibitedTarget
based on hostname likeWhat is interessting about the error is, that the referenced
urlPathMap
url-9cd989d2ce94d8d5b665a2c10b238fba
is from the other environment (TEST) and thus should not be ignored. Even seems as it is ignored in some parts of the logic, but not others as the path map definitely exists as evident when queried on the Azure management API.This currently blocks us in rolling out any ingress changes in the affected environments. As a test I've manually changed the version in the deployment to 1.7.4, which seems to still have been able to apply the changes. However that is not a sustainable fix as the version is managed by Azure if AGIC is deployed as an add-on.
Current controller version is 1.7.6 as managed by Azure.
Redacted internal names and IDs.
After additional search it looks like #1671 has a very similar error and might be related.
To Reproduce
Steps to reproduce the behavior:
Ingress Controller details
kubectl describe pod <ingress controller
> . The pod name can be obtained by runninghelm list
.The text was updated successfully, but these errors were encountered: