-
Notifications
You must be signed in to change notification settings - Fork 47
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
feat: Add routing protocols resource to terraform provider #436
Conversation
thogarty
commented
Nov 2, 2023
•
edited
Loading
edited
- Add routing protocols resource to provider
- Include acceptance tests and docs
- Tested manually with all permutations of direct and bgp routing protocol data
- Data Source tested manually with both direct and bgp
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #436 +/- ##
==========================================
- Coverage 60.11% 59.72% -0.40%
==========================================
Files 99 102 +3
Lines 20045 20768 +723
==========================================
+ Hits 12051 12404 +353
- Misses 7691 8063 +372
+ Partials 303 301 -2
☔ View full report in Codecov by Sentry. |
"equinix_iface_ip": fmt.Sprintf("190.1.1.1/29"), | ||
}), | ||
), | ||
ExpectNonEmptyPlan: true, |
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.
It would be helpful to test imports to ensure we aren't drifting in state by executing a refresh using an import of the identifier.
ExpectNonEmptyPlan: true, | |
ExpectNonEmptyPlan: true, | |
ImportState: true, | |
ImportStateVerify: true, | |
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.
Assuming we include Import in the resource schema, which we should be doing for every resource.
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.
Agree, change made.
} | ||
|
||
resource "equinix_fabric_routing_protocols" "routing_protocols" { | ||
connection_uuid = "b0eb3892-6404-442b-85c0-4f8fcf53d123" |
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.
I have some questions about this resource that will be easier to answer in terms of this documentation example.
Will a single equinix_fabric_routing_protocols
explicitly and comprehensively cover all of direct and BGP routing protocols for a specific connection?
If so:
- Is it not sufficient to use the connection id as the
SetId
for this TF resource? Can't we fetch and sync all routes from connection id alone? - Will any routes for this connection not defined in this TF resource be deleted?
- should we provide a warning that only a single routing_protocol resource per connection uuid should be active (count != 0) at a time
- Multiple direct and BGP routes seem to be supported (can we show that in the example)
- Is there a universal documented hard API upper bound on the number of routes? Should this be defined as MaxItems for BGP and direct?
If not:
- I wonder if the plural resource name implies otherwise (that it should be a comprehensive resource)
- I assume we are doing so to avoid touching routes not defined in TF?
- we could surface those routes as smaller resources (one type or setting to differentiate BGP vs direct)
- ^ we wouldn't be able to use the bulk API endpoint, so perhaps that is the reason we took this path?
- or if there is a 1:1 relationship between this resource and the connection, we could make these sub-resources of the connection itself.
- there are pros and cons to laying out the resource in a different format. It would be nice to justify the design choice in the PR description.
In either case:
- How do we use SetId and ImportId in a way that reflects that there may be multiple Direct or BGP sub-resources?
I think it would be helpful to include tests steps (on the existing tests) that:
- add direct and bgp rules from a set
- remove direct and bgp rules from a set
- juggle (move) direct and BGP rules to another set in the same resource (this is what I'm most interested in)
- ^ include an import test on this step (I suspect the additional rules would be dropped today)
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.
@displague, only one of Direct and one of BGP are allowed on a connection resource at a time:
This resource is to manage the Single Direct and BGP routing protocol resources under a connection. There will not be more than a single of each. I should add MaxItems = 1 to those set types to reflect that.
This resource is to manage the synchronization between Direct and BGP. Direct cannot be deleted before BGP if both are applied to the connection; an error will be returned if attempted. Additionally, you cannot send a POST for Direct or BGP after they have been created to overwrite; it will return an error saying only one of each type is allowed.
This restriction I believe simplifies your queries. Let me know if that's not the case though.
Out of date. Closing. Open issue #484 refers to it and if that conversation ever gets going we can revisit this. |