csi: add scaffolding for node-specific restriction handling#5508
csi: add scaffolding for node-specific restriction handling#5508mrhapile wants to merge 3 commits intofluid-cloudnative:masterfrom
Conversation
Signed-off-by: mrhapile <allinonegaming3456@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Summary of ChangesHello @mrhapile, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request establishes foundational scaffolding within the CSI Node plugin to enable future implementation of node-specific restriction handling. It introduces an extensible Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
Hi @mrhapile. Thanks for your PR. I'm waiting for a fluid-cloudnative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This Pull Request introduces the scaffolding for node-specific restriction handling in the CSI Node plugin. It adds a NodeRestrictionChecker abstraction with a no-op implementation and integrates it into the NodePublishVolume operation for observability. The changes align with the PR description, laying the groundwork for future node-level constraint enforcement without altering current behavior.
| // NodeRestriction represents node-level CSI constraints | ||
| type NodeRestriction struct { | ||
| CSIDisabled bool | ||
| MaxVolumes int |
There was a problem hiding this comment.
The MaxVolumes field is an int. If a negative value is assigned in future implementations, it could lead to unexpected behavior (e.g., infinite volumes or panics). Consider using an unsigned integer type or adding validation to ensure it's non-negative if that's the intended constraint.
There was a problem hiding this comment.
This PR only introduces scaffolding without enforcement. Validation logic will be added when restrictions are enforced in follow-up PRs.
There was a problem hiding this comment.
Pull request overview
Adds scaffolding to the CSI node plugin for future node-specific restriction enforcement by introducing a pluggable checker, wiring in a default no-op implementation, and emitting restriction-related logs during NodePublishVolume.
Changes:
- Add
NodeRestrictionCheckerinterface and a no-op implementation. - Store a restriction checker on the CSI node server and query it during
NodePublishVolume(logging only). - Wire the default no-op checker into node server construction.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pkg/csi/plugins/nodeserver.go | Adds a restrictionChecker field and logs checker output during NodePublishVolume. |
| pkg/csi/plugins/node_restriction.go | Introduces restriction types, checker interface, and a no-op checker implementation. |
| pkg/csi/plugins/driver.go | Wires the no-op checker into the node server constructor. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| apiReader: d.apiReader, | ||
| nodeAuthorizedClient: d.nodeAuthorizedClient, | ||
| locks: d.locks, | ||
| locks: d.locks, | ||
| restrictionChecker: NewNoopRestrictionChecker(), | ||
| } |
There was a problem hiding this comment.
This file appears to have gofmt issues (e.g., trailing whitespace after d.locks, in the struct literal). CI in this repo runs gofmt checks, so please run gofmt (or make fmt) to avoid formatting failures.
| // NodeRestrictionChecker fetches node restrictions | ||
| type NodeRestrictionChecker interface { | ||
| GetRestriction(nodeName string) (*NodeRestriction, error) | ||
| } |
There was a problem hiding this comment.
NodeRestrictionChecker.GetRestriction takes a parameter named nodeName, but callers pass ns.nodeId. To avoid confusion for future implementations, consider renaming the parameter (and related comments) to nodeID/nodeIDOrName to match how it is actually used.
There was a problem hiding this comment.
Thanks for the suggestion. Since this is scaffolding-only and not yet enforcing restrictions, I’ll keep the current naming for now and refine it in the enforcement phase if needed.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #5508 +/- ##
==========================================
+ Coverage 56.82% 56.87% +0.05%
==========================================
Files 443 444 +1
Lines 30735 30297 -438
==========================================
- Hits 17464 17232 -232
+ Misses 11717 11571 -146
+ Partials 1554 1494 -60 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Signed-off-by: mrhapile <allinonegaming3456@gmail.com>
Signed-off-by: mrhapile <allinonegaming3456@gmail.com>
|
|
@TrafalgarZZZ can you tell me what changes can I make |
1 participant
Ⅰ. Describe what this PR does
This PR introduces scaffolding in the CSI Node plugin to support future
node-specific restriction handling.
Specifically, it:
NodeRestrictionCheckerabstractionNodePublishVolumefor observability (logging only)There is no behavior change in this PR. All volume publish operations
continue to function as before.
This lays the groundwork for enforcing node-level constraints (e.g. based on
node labels or annotations) in follow-up PRs.
Ⅱ. Does this pull request fix one issue?
NONE
(Related to #5315 , but does not close it as this PR only adds scaffolding.)
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
No tests are added in this PR.
This change only introduces structural scaffolding and logging without
altering any functional behavior, so existing tests remain sufficient.
Future PRs that add enforcement logic will include corresponding tests.