-
Notifications
You must be signed in to change notification settings - Fork 4
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
kubelet plugin #12
kubelet plugin #12
Conversation
0334013
to
1ea4dab
Compare
Example run:
|
// create json file | ||
filePath := ex.getJsonFilePath(req.ClaimUid) | ||
if err := os.WriteFile(filePath, jsonBytes, os.FileMode(0644)); err != nil { | ||
if err := os.WriteFile(filePath, buffer, os.FileMode(0644)); err != nil { |
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.
Have you considered using this API ?
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.
btw, it would be nice to avoid rewriting the file if its content is the same. We might need support from CDI for comparing specs to implement that.
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 haven't looked at the new API yet. Let's wait for cncf-tags/container-device-interface#77 before making further changes.
Rewriting the file should happen very infrequenly. I wouldn't write extra code for it.
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.
Well, NodePrepareResource can be called by Kubelet any time and with any frequency. Rewriting CDI file should either be atomic(btw, spec.Write seems to do it atomically) or, better, not happening at all. We can't predict when Kubelet will decide to call NodePrepareResource. It could happen at the same time when runtime reads previously created CDI file.
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 can use that API as it's most probably not going to change. Even if they add APIs for generating CDI file names it'll probably not change Write() API as a file path is passed to the spec constructor and Write API uses path that's set in the spec object.
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.
So your current code doesn't serialize that?
it does. There is a lock for this purpose, so two calls can't be done at the same time. However, it doesn't guarantee that NodePrepareResource can't be called for the (second) pod when runtime reads CDI file created by the previous call (for the first pod referencing the same claim).
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.
Yes, it's unlikely to happen, I agree. But it can happen, so it's better to avoid re-generate CDI files in my opinion.
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.
WriteSpec() uses Spec.Write() under the hood... which maybe should be an unexported Spec.write() instead.
Code in this PR does the following:
- creates spec object (passing CDI file path to it)
- marshals it to JSON
- writes json to the file (with the same CDI file path as was passed to the cdi.NewSpec)
That's why I thought that creating a spec object and then calling spec.Write() looks as a reasonable way to replace that code.
It seems not the case though. Can you explain what needs to be done instead?
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.
But preferably the Cache/Registry WriteSpec() interface should be used instead.
Wouldn't this require reading all CDI files present in CDI directories? This can potentially slow down the plugin. However, if it's done once on the plugin start it shouldn't be a problem, right?
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 added a TODO about using newer API(s) but for now would prefer to merge the code as-is so that we can make progress with other, more important aspects (like moving the code around).
@@ -114,8 +110,10 @@ func (ex *examplePlugin) NodePrepareResource(ctx context.Context, req *drapbv1.N | |||
} | |||
|
|||
spec := specs.Spec{ | |||
Version: cdiVersion, | |||
Version: "0.2.0", |
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.
@klihub: what is the "right" version string to use here?
Isn't it defined indirectly through the Go API, i.e. specs.Spec
, specs.Device
, etc.?
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.
Moved to cncf-tags/container-device-interface#60 (comment) and added a TODO to the code.
a25308e
to
064be9f
Compare
4ef7013
to
d46584b
Compare
allErrs = append(allErrs, field.Required(fldPath, "")) | ||
} | ||
|
||
if len(driverName) > 63 { |
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.
Why 63? In this case a constant or variable with a meaningful name would be more readable I believe.
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.
This is the same length limit as for CSI driver name. The entire function was copied from there.
I am following how API validation is handled elsewhere in Kubernetes:
- not all limitations are fully documented in code comments (but perhaps should be - not sure)
- no constants for such limits, neither in the API nor in the code
I can imagine that defining this limit as part of the API would be useful. I need to check with the API reviewers whether that is a good or bad idea.
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've added a TODO.
logger := klog.FromContext(ctx) | ||
deviceName := "claim-" + req.ClaimUid | ||
kind := ex.driverName + "/test" | ||
filePath := ex.getJSONFilePath(req.ClaimUid) |
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.
nit: I'd propose to move this variables to the place where they're used(filePath), or get rid of them (kind, deviceName) if they're used only once.
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.
Done. I kept logger where it is (top of the function) because if it was created directly before the first usage and then later another log line got added earlier in the function, the logger initialization would have to be moved.
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.
deviceName is used twice.
4b19411
to
dad1a28
Compare
All of these changes are now part of the dynamic-resource-allocation branch, after squashing the commits. |
This takes the latest code from PR #7 and updates the code to make it simpler and enhance various aspects (for example, logging).