Skip to content

Add basic producer package#308

Open
elezar wants to merge 4 commits intocncf-tags:mainfrom
elezar:improve-cache-save
Open

Add basic producer package#308
elezar wants to merge 4 commits intocncf-tags:mainfrom
elezar:improve-cache-save

Conversation

@elezar
Copy link
Contributor

@elezar elezar commented Feb 18, 2026

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.

priority: priority,
}

if ext := filepath.Ext(spec.path); ext != ".yaml" && ext != ".json" {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines -316 to -320
var (
specDir string
path string
err error
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #309 since this is separate from the producer API.

@elezar elezar force-pushed the improve-cache-save branch 6 times, most recently from 68087b7 to 6fc7db9 Compare February 18, 2026 21:08
Signed-off-by: Evan Lezar <elezar@nvidia.com>
if err != nil {
return nil, err
}
data = append([]byte("---\n"), data...)
Copy link
Contributor

@klihub klihub Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we add this document separator in front ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Comment on lines 35 to 37
type validator interface {
Validate(*cdi.Spec) error
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Isn't this the zero-value so we could just omit it ?

Copy link
Contributor Author

@elezar elezar Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in the long run we should consider deprecating the cache.WriteSpec() function and require that producers explicitly use the producer API.

}

func assertNotDirectory(path string) error {
info, err := os.Lstat(path)
Copy link
Contributor

@klihub klihub Feb 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this new package could also be placed under pkg/cdi/producer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this back to pkg/cdi/producer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's true. I don't want to go into the module discussion in the first iteration though.

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>
@elezar elezar force-pushed the improve-cache-save branch from 437610e to 3f95ba4 Compare February 20, 2026 08:08
@elezar elezar marked this pull request as ready for review February 20, 2026 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments