-
Notifications
You must be signed in to change notification settings - Fork 71
[improvement] : allow passing vpcids and subnetids to ccm #423
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #423 +/- ##
==========================================
+ Coverage 75.42% 75.83% +0.40%
==========================================
Files 16 16
Lines 2987 3054 +67
==========================================
+ Hits 2253 2316 +63
- Misses 545 547 +2
- Partials 189 191 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ebdb773 to
f640b63
Compare
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.
Pull Request Overview
This PR adds new command-line flags (--vpc-ids and --subnet-ids) to the CCM, allowing users to specify IDs instead of names when configuring VPC routing. The changes maintain backward compatibility with existing name-based flags while adding validation to ensure only one approach is used at a time.
Key changes:
- Added
--vpc-idsand--subnet-idsflags as IntSlice types alongside existing name-based flags - Converted existing string flags to StringSlice types for consistency
- Added comprehensive validation logic to prevent conflicting flag combinations
- Updated Helm chart templates and documentation to reflect the new options
Reviewed Changes
Copilot reviewed 17 out of 17 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| main.go | Updated flag definitions to support both ID and name-based VPC/subnet specification |
| cloud/linode/vpc.go | Added validation functions and ID-to-name resolution logic |
| cloud/linode/vpc_test.go | Added comprehensive tests for new validation and resolution functions |
| docs/configuration/environment.md | Updated documentation to include new flag options |
| deploy/chart/values.yaml | Added configuration examples for new ID-based flags |
| deploy/chart/templates/daemonset.yaml | Added Helm template validation and flag passing logic |
| Multiple test files | Updated test data to use new StringSlice format |
| func resolveSubnetNames(client client.Client, vpcID int) ([]string, error) { | ||
| subnetNames := []string{} | ||
| for _, subnetID := range Options.SubnetIDs { | ||
| subnet, err := client.GetVPCSubnet(context.TODO(), vpcID, subnetID) | ||
| if err != nil { | ||
| return nil, fmt.Errorf("failed to get subnet %d for VPC %d: %w", subnetID, vpcID, err) | ||
| } | ||
|
|
||
| subnetIDs[subnet.Label] = subnet.ID | ||
| subnetNames = append(subnetNames, subnet.Label) | ||
| } |
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.
won't this still lead to the same problem if the subnet name is changed? Since we are just grabbing the label at one point in time?
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.
Nope. We store everything in the cache and then it always looks into the cache.
vpcIDs and subnetIDs are the two caches it builds at startup and then uses going forward.
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.
A ccm restart will cause that cache to be purged. Would that be an issue?
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.
Nope. If someone updates vpcname/subnetname and CCM is restarted, it will again try to get the label for the passed vpcid/subnetid and store the updated name in its cache and continue working. When logging, it will log the vpc/subnet names instead of ids which are more readable/human friendly than the ids.
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.
ahh ok I missed the vpcID logic since that was already there. Makes a lot more sense to me now.
Only other comment would be why can't you use ids and names?
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.
You mean flipping the logic and using vpcids/subnetids instead of vpcnames/subnetnames? Or you meant combination of vpcname+subnetid?
I didn't flip the logic as that would mean all existing tests would start failing and that would be a much bigger change and touch most of the functionality of CCM.
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.
the combination, but it really isn't that important. One or the other is fine with me.
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 increases complexity and would be more error prone. I would prefer just using either names or ids but not both.
General:
This PR adds two new flags to CCM (
--vpc-idsand--subnet-ids). This will allow someone to specify ids instead of names when starting CCM.Key changes:
Added --vpc-ids and --subnet-ids command-line flags as IntSlice types
Changed existing --vpc-names and --subnet-names flags from string to StringSlice types
Added validation logic to ensure only one approach (names or IDs) is used at a time
Pull Request Guidelines: