Conversation
| priority: priority, | ||
| } | ||
|
|
||
| if ext := filepath.Ext(spec.path); ext != ".yaml" && ext != ".json" { |
There was a problem hiding this comment.
I don't think we should be setting this in newSpec since we also call this when READING a spec. In which case we either do this TWICE, or modify the path before reading.
| var ( | ||
| specDir string | ||
| path string | ||
| err error | ||
| ) |
There was a problem hiding this comment.
Personal preference, but declaring these up front add additional vertical space to a function. Happy to revert if there is a strong opinion.
| specDir, _ = c.highestPrioritySpecDir() | ||
| specDir, _ := c.highestPrioritySpecDir() | ||
| if specDir == "" { | ||
| return errors.New("no Spec directories to remove from") |
There was a problem hiding this comment.
One question here: Should this really be an error when removing a spec? If this fails is that not essentially the same as "Not Found" ... we could even return a wrapped NotFound here.
There was a problem hiding this comment.
Yes, I think returning a wrapped appropriate error (maybe an fs.ErrNotExist) would probably be the right thing here, giving the caller an easy way to identify and ignore it at will.
There was a problem hiding this comment.
Created #309 since this is separate from the producer API.
68087b7 to
6fc7db9
Compare
Signed-off-by: Evan Lezar <elezar@nvidia.com>
6fc7db9 to
33d83be
Compare
| if err != nil { | ||
| return nil, err | ||
| } | ||
| data = append([]byte("---\n"), data...) |
There was a problem hiding this comment.
Why do we add this document separator in front ?
There was a problem hiding this comment.
This is to allow cat /var/run/*.yaml work as expected.
See here #126
(note that with the options we could now make this opt-out)
| type validator interface { | ||
| Validate(*cdi.Spec) error | ||
| } |
There was a problem hiding this comment.
nit: since this is now also defined in the newly added package, wouldn't it make sense define it as an exported type in one and have an alias for it in the other with a type Validator = $PKG.Validator ?
There was a problem hiding this comment.
I didn't want this PR to become about validation. We already have #247 open for this, and I would rather address reworking validation in a follow-up to keep the scope of this PR limited to actually writing specs.
| // we assume a json format. | ||
| producer.WithOutputFormat("json"), | ||
| producer.WithOverwrite(overwrite), | ||
| producer.WithPermissions(0), |
There was a problem hiding this comment.
nit: Isn't this the zero-value so we could just omit it ?
There was a problem hiding this comment.
The current implementation has permissions set to 0644 by default. I can change this though.
Update: My motivation for changing the default to 0644 in the producer package is that this generally does the right thing from a general producer perspective. The spec files NEED to be world readable to be generally useful since we have no control over the user that the consumer is running as.
There was a problem hiding this comment.
I think in the long run we should consider deprecating the cache.WriteSpec() function and require that producers explicitly use the producer API.
pkg/cdi-producer/save.go
Outdated
| } | ||
|
|
||
| func assertNotDirectory(path string) error { | ||
| info, err := os.Lstat(path) |
There was a problem hiding this comment.
Shouldn't this be os.Stat ? Now this will pass the check if path is a symlink pointing to a directory, but what happens later, and is it intentional ?
There was a problem hiding this comment.
It was intentional, but I think I was getting ahead of myself in terms of path traversal errors. Let me change this to os.Stat for simplicity since this doesn't actually handle the link case explicitly.
| @@ -14,7 +14,7 @@ | |||
| limitations under the License. | |||
| */ | |||
|
|
|||
| package cdi | |||
| package producer | |||
There was a problem hiding this comment.
nit: this new package could also be placed under pkg/cdi/producer.
There was a problem hiding this comment.
Yes, I was uncertain of where to store this. In the longer term, it may be useful to have this be a separate go module so that producers don't need to import all the unwanted dependencies. (e.g. spec generator).
There was a problem hiding this comment.
I moved this back to pkg/cdi/producer.
There was a problem hiding this comment.
Just a note that I think having it under pkg/cdi/producer shouldn't prevent it from being its own go module... although it might be that the location would be a bit strange if it were.
There was a problem hiding this comment.
That's true. I don't want to go into the module discussion in the first iteration though.
82ed0f3 to
437610e
Compare
This change addes a new producer subpackage to cdi. The purpose of this package is to handle use-cases that do not require a CDI cache and are only concerned with generating and outputing CDI specifications. Signed-off-by: Evan Lezar <elezar@nvidia.com>
Signed-off-by: Evan Lezar <elezar@nvidia.com>
Signed-off-by: Evan Lezar <elezar@nvidia.com>
437610e to
3f95ba4
Compare
This change revisits the idea of a separate producer package that was discussed prior to the v1.0.0 release.
Instead of relying on a separate module at this stage, I am using a new package at
pkg/cdi-producer.This is still a rough draft and I need to add better documentation to the API.
I have also created NVIDIA/nvidia-container-toolkit#1665 where I demonstrate the use of the API.