-
Notifications
You must be signed in to change notification settings - Fork 626
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
Adds new resource cloudflare_byo_ip_prefix #671
Adds new resource cloudflare_byo_ip_prefix #671
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for raising this PR!
The overall feel of this PR seems OK but there are more notes inline regarding things like naming and using the lifecycle methods appropriately to ensure we're not introducing more issues.
I'm not using a boolean for the advertisement status, as there's no reliable alternative for GetOK to check if an optional boolean has been set and GetOKExists is marked as deprecated.
Have you seen cloudflare_record
proxied status? Looks like a similar use case to what you're after here that works.
Writing a test for updating the advertisement status is going to be complicated since there's a conservative rate-limit on the API
Let's give it a go and see what we need to do. I don't really want functionality without tests to make it into the provider as we've been there and it makes maintainer life especially hard. If we hit rate limits, we can chat to Cloudflare about some next steps.
Looking at
Fully agree. Acceptance-Testing the prefix description is completely fine. The only concern here is testing the advertisement status. I'll check internally if there might be a way. |
@cehrig unfortunately there isn't a way we can relax that rate limit without essentially performing a noop if the call is within a certain time frame (15 minutes, for example). Route changes take time to converge and are disruptive to the internet, so we have to be quite conservative about how frequently we allow external parties to change bgp status. (Note: Yes, we certainly could batch the changes and debounce on our end, but then the user feedback loop and delays may cause confusion. We decided it better to 429) One recommendation would be to check the latest advertised modified timestamp, and only perform the PATCH request if it is beyond the 15 minute time window. I'm sorry I can't make this any easier for your testing. If it makes you feel better, we have the same issue internally. It's important to test frequently, but we can't disrupt the internet for the sake of our tests... and if you're testing the API but not actually changing BGP -- then it's not really a good test. Can you mark the test case as Skipped somehow when you reach this condition? Perhaps you can at least highlight this event with |
Your testing comments make total sense, thanks @tarnfeld. Given the difficulty in testing this, I think we may just need to rely on manual use for the Terraform side of things and unit tests within |
I have at least added a test for the prefix description. It requires
|
return fmt.Sprintf(` | ||
resource "cloudflare_byo_ip_prefix" "%[3]s" { | ||
prefix_id = "%[1]s" | ||
description = "%[2]s" | ||
}`, prefixID, description, name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we format this JSON to not have really big indents?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated. I blame it on my formatter's settings :-)
Co-authored-by: Jacob Bednarz <jacob.bednarz@gmail.com>
Should the `CLOUDFLARE_BYO_IP_PREFIX_ID` not be set (such as the case with the integration suite) don't attempt to run the BYO IP prefix tests. Instead, let the runner know it is being skipped.
Thanks a bunch for persisting to get this one over the line @cehrig! You've done a great job here ⭐ |
@jacobbednarz I have to Thank You. I'll keep in mind to run the full test suite in the future ... You rock, Thanks a lot! :-) |
Respect context cancellation and deadlines.
This PR introduces a new resource
cloudflare_ip_prefix
for managingdescription
attributeadvertisement
attributeThe resource needs
account_id
to be set in the provider configuration.It uses
GetPrefix
andGetAdvertisementStatus
for reading IP prefix information +UpdatePrefixDescription
andUpdateAdvertisementStatus
for writing updates fromcloudflare-go
.@jacobbednarz I'd appreciate if you could take a look if that's going into the right direction before I proceed. Some remarks:
GetOK
to check if an optional boolean has been set andGetOKExists
is marked as deprecated.TODO