Conversation
2bc84b3 to
7449925
Compare
Also fix already mount error code
7449925 to
efdefae
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #322 +/- ##
==========================================
+ Coverage 74.79% 75.07% +0.28%
==========================================
Files 22 22
Lines 2396 2359 -37
==========================================
- Hits 1792 1771 -21
+ Misses 499 489 -10
+ Partials 105 99 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| switch { | ||
| case strings.Contains(apiErr.Message, "is already attached"): | ||
| return errAlreadyAttached | ||
| case strings.Contains(apiErr.Message, "Maximum number of block storage volumes are attached to this Linode"): |
There was a problem hiding this comment.
Ok, but this seems brittle when the API changes their text message. How can we check this error, but not rely on the spelling of an API text error message?
There was a problem hiding this comment.
That's an excellent question.
API doesn't document errors

And linodego report request as it
But we have to notice this logic was already done before in CSI :/
There was a problem hiding this comment.
Yeah def not the ideal way to do it. Hopefully linodego can provide better error codes in future so we don't have to build logic based on the err strings :/
| @@ -677,33 +650,6 @@ func (cs *ControllerServer) getInstance(ctx context.Context, linodeID int) (*lin | |||
| return instance, nil | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
Is there really no value in having these checks client side at all?
There was a problem hiding this comment.
I tend to prefer to rely on API internal logic and validation and for CSI to act as a simple pass-through.
The problem I see could be a rate-limiting issue on API (GET vs. POST).
But attacher already has a backoff on error
https://github.com/kubernetes-csi/external-attacher?tab=readme-ov-file#csi-error-and-timeout-handling
But that may be questionable, or we may have to wait for linodego to implement rate-limiting.
That's why this PR was in draft state at first.
|
|
||
| // errAlreadyAttached is used to indicate that a volume is already attached | ||
| // to a Linode instance. | ||
| errAlreadyAttached = status.Error(codes.FailedPrecondition, "volume is already attached") |
There was a problem hiding this comment.
Before merging, I want to wait for an answer on this issue
kubernetes-csi/external-attacher#604
| case strings.Contains(apiErr.Message, "is already attached"): | ||
| return errAlreadyAttached |
There was a problem hiding this comment.
Question: We only get this err when the volume is attached to another linode?
I think pass the specific err message from the api which could include linode id of another node. This would be helpful in debugging issue in future.
| case strings.Contains(apiErr.Message, "is already attached"): | ||
| return errAlreadyAttached | ||
| case strings.Contains(apiErr.Message, "Maximum number of block storage volumes are attached to this Linode"): | ||
| return errMaxAttachments |
There was a problem hiding this comment.
Similar to my suggestion from other comment. We should try to pass along the err message by the api here too
| switch { | ||
| case strings.Contains(apiErr.Message, "is already attached"): | ||
| return errAlreadyAttached | ||
| case strings.Contains(apiErr.Message, "Maximum number of block storage volumes are attached to this Linode"): |
There was a problem hiding this comment.
Yeah def not the ideal way to do it. Hopefully linodego can provide better error codes in future so we don't have to build logic based on the err strings :/
This pull request focuses on simplifying the volume attachment logic in the
ControllerServerby removing redundant checks and related methods. The most important changes include the removal of thecheckAttachmentCapacityfunction and its associated methods, as well as the related test cases.Context
CSI caller (like Kubernetes) should already respect volume limitation from
NodeGetInfo.We don't need another check and logic at attach.
Motivation
Reduce logic and complexity and rely more on Linode API calls.
If there is an error, return it to the user for easier debug.
Risk
Making more failing attach requests and maybe hitting a rate limit.
This should not be a problem, as CSI attacher have a backoff logic.
Moreover, current limit logic is already doing api calls that should have hit API ratelimit.
Possible Mitigations
csiErrorBackoffmechanismIMHO, both are not mandatory for the moment.
Simplification of volume attachment logic:
checkAttachmentCapacityfunction and its invocation from theControllerPublishVolumemethod ininternal/driver/controllerserver.go.canAttachfunction, which was used to determine if an additional volume could be attached to an instance, frominternal/driver/controllerserver_helper.go.checkAttachmentCapacityfunction, which checked if an instance could accommodate additional volume attachments, frominternal/driver/controllerserver_helper.go.Removal of related test cases:
TestCheckAttachmentCapacitytest function frominternal/driver/controllerserver_helper_test.go, which tested thecheckAttachmentCapacitylogic.General:
Pull Request Guidelines: