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

Adding the Match parameter to the Probes to check on the response code #1446

Merged
merged 5 commits into from
Jun 28, 2018

Conversation

VaijanathB
Copy link
Contributor

This is blocking a current customer. I have added the change to existing test case probe. Ran the tests private but failed on deleting subnet which is a known issue.

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.

Hey @VaijanathB

Thanks for this PR. As you've mentioned - the Application Gateway tests are unreliable due to the broken API, as such we need to be careful with this (we've been intentionally not changing Application Gateway's until the API is fixed as the broken tests leaves resources lingering in our subscription, which causes us to have other test failures due to hitting our limits).

I've left some comments inline - if you can fix them up (and the tests pass) we should be able to merge this particular instance; that said, I don't expect us to merge any additional fixes/changes to Application Gateway's until the API issue outlined here is fixed: Azure/azure-rest-api-specs#2187

Thanks!

Type: schema.TypeList,
Optional: true,
Elem: &schema.Schema{
Type: schema.TypeString,
Copy link
Contributor

Choose a reason for hiding this comment

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

given this is a status code, can we make this a TypeInt?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

People can specify status codes as ranges also like 200-300.

if match := props.Match; match != nil {

matchConfig := map[string]interface{}{
"body": *match.Body,
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 potential crash here if body is nil - can we make this:

matchConfig := map[string]interface{}{}
if body := match.Body; body != nil {
  matchConfig["body"] = *body
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. Fixed it.

}

statusCodes := make([]interface{}, 0)
for _, status := range *match.StatusCodes {
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 potential crash here if the API returns a bad response, can we make this:

if match.StatusCodes != nil {
  for _, status := ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed.

@@ -457,6 +457,29 @@ func resourceArmApplicationGateway() *schema.Resource {
Type: schema.TypeInt,
Required: true,
},

"match": {
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 also add documentation for this block?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.

203,
202,
]
}
Copy link
Contributor

Choose a reason for hiding this comment

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

since this is an optional block, can we add a test specifically for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added a separate test that verifies the presence of Match block in the probe is being set.

@VaijanathB
Copy link
Contributor Author

VaijanathB commented Jun 27, 2018

@tombuildsstuff Thanks for your review. This is the last fix I will make in Application gateway and this was blocking the customer I was working with. Currently they are working around this using powershell and wanted to fix this ASAP. I have addressed all the review comments.

@tombuildsstuff tombuildsstuff added this to the 1.8.0 milestone Jun 28, 2018
@tombuildsstuff tombuildsstuff merged commit 55c6114 into master Jun 28, 2018
@tombuildsstuff tombuildsstuff deleted the MatchProbeAG branch June 28, 2018 09:36
tombuildsstuff added a commit that referenced this pull request Jun 28, 2018
@tombuildsstuff
Copy link
Contributor

The Application Gateway tests are intermittent - but this seems fine:

screenshot 2018-06-28 at 10 37 27

@ghost
Copy link

ghost commented Mar 30, 2020

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 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants