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

[FEATURE] Add rule for APIM to check capacity is set to same or more than number of zones deployed too #2788

Closed
jtracey93 opened this issue Mar 30, 2024 · 10 comments · Fixed by #2874
Assignees
Labels
pillar: reliability Aligned to the Reliability pillar. rule: api-management Rules for API Management
Milestone

Comments

@jtracey93
Copy link
Contributor

Your suggestion

Add rule for APIM to check capacity is set to same or more than number of zones deployed too as per guidance here: https://learn.microsoft.com/en-us/azure/api-management/high-availability?toc=%2Fazure%2Freliability%2Ftoc.json&bc=%2Fazure%2Freliability%2Fbreadcrumb%2Ftoc.json#:~:text=When%20you%20enable,hosts%20one%20unit.

Alternatives

N/A

Additional context

No response

@jtracey93 jtracey93 added enhancement New feature or request Needs: Triage 🔍 labels Mar 30, 2024
@BernieWhite BernieWhite added rule: api-management Rules for API Management pillar: reliability Aligned to the Reliability pillar. and removed enhancement New feature or request Needs: Triage 🔍 labels Apr 1, 2024
@BernieWhite BernieWhite added this to the v1.37.0 milestone Apr 30, 2024
@BenjaminEngeset
Copy link
Contributor

:shipit:

@BernieWhite
Copy link
Collaborator

Hi @jtracey93, on further investigation it appears that the existing rule Azure.APIM.AvailabilityZone should meet the general requirements.

This rule Azure.APIM.AvailabilityZone requires:

  • At least two zones be specified.
  • That capacity cover the number of zones specified.
  • Also supports the same approach for additional locations if the customer has chosen to deploy across region.

Noting:

  • This rule passes if at least 2 zones are specified instead of 3.
  • It does not fail if a premium SKU is not used, since this is the only SKU that supports availability zones.

Since we already have #2787

I believe this covers the case and explains the reason for the test not flagging because the SKU used in the AVM test defaulted to Developer SKU.

If you agree we'll close this issue.

@jtracey93
Copy link
Contributor Author

Thanks @BernieWhite.

Shouldn't we make it fail if the premium sku isn't used then? As that's only way to get AZ support?

@BernieWhite
Copy link
Collaborator

@jtracey93 it's a good point. I think the initial motivation was to reduce noise for customers that had no intention of using premium.

But I can see how the current approach might add confusion, and possibly make it harder to decern WAF alignment.

Let's go with your approach. It's a clearer path to WAF alignment.


@BenjaminEngeset If you still want to see this one through. The next steps here should just to update Azure.APIM.AvailabilityZone to:

  • remove the -If premium check
  • but to include the check for the SKU in the rule body so that Non-premium APIM's fail with a message that premium is not set.
  • docs might need a slight update.

@BenjaminEngeset
Copy link
Contributor

@jtracey93 it's a good point. I think the initial motivation was to reduce noise for customers that had no intention of using premium.

But I can see how the current approach might add confusion, and possibly make it harder to decern WAF alignment.

Let's go with your approach. It's a clearer path to WAF alignment.

@BenjaminEngeset If you still want to see this one through. The next steps here should just to update Azure.APIM.AvailabilityZone to:

  • remove the -If premium check
  • but to include the check for the SKU in the rule body so that Non-premium APIM's fail with a message that premium is not set.
  • docs might need a slight update.

Yes, I will do so accordingly in a new PR.

@BernieWhite
Copy link
Collaborator

@BenjaminEngeset @jtracey93 The only reservation I have here is cases for the Developer tier is common, and a fair case that customers do not want to have AZ replicated (+ cost) for a developer environment.

@BenjaminEngeset
Copy link
Contributor

@BenjaminEngeset @jtracey93 The only reservation I have here is cases for the Developer tier is common, and a fair case that customers do not want to have AZ replicated (+ cost) for a developer environment.

Can specify this so it's clear in the rule doc.

@BernieWhite
Copy link
Collaborator

Yep @BenjaminEngeset Let's make a point in the docs notes that you can suppress for developer environments.

@jtracey93
Copy link
Contributor Author

Can they not create a depression for this. PSRule is about helping to align to WAF so we should push to do the right thing

@BernieWhite
Copy link
Collaborator

Yep. I think that's the best path forword.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pillar: reliability Aligned to the Reliability pillar. rule: api-management Rules for API Management
Projects
None yet
3 participants