Using plugins out of tree / not with Kubernetes?

[vsoch]

Hi! I'm particularly interested in these two for functionality:

• https://github.com/containers/nri-plugins/blob/main/pkg/sysfs/system.go
• https://github.com/containers/nri-plugins/blob/main/cmd/plugins/balloons/policy/cputree.go#L243

And I'm wondering if 1) you have examples of using these outside of the context of Kubernetes, and 2) if it might be possible to vendor them separately to allow for such use cases? For some background, I'm designing extractors for compatibility, and nri was recommended to me as an alternative for topology to hwloc, which has technically "go bindings" but I'm finding them hard to use. If you'd be interested in this idea I can prototype / test the out of tree case, although it would be helpful to understand how to create the various plugins. Thanks!

[klihub]

Hi! I'm particularly interested in these two for functionality:

• https://github.com/containers/nri-plugins/blob/main/pkg/sysfs/system.go
• https://github.com/containers/nri-plugins/blob/main/cmd/plugins/balloons/policy/cputree.go#L243

And I'm wondering if 1) you have examples of using these outside of the context of Kubernetes, and 2) if it might be possible to vendor them separately to allow for such use cases?

I suspect that there are no external users of either of these. They are only in use by some of our NRI reference plugins.

For some background, I'm designing extractors for compatibility, and nri was recommended to me as an alternative for topology to hwloc, which has technically "go bindings" but I'm finding them hard to use.

I'm really not familiar with hwloc, but TBH trying to switch to our above mentioned sysfs package for topology detection might get you out of the frying pan into the fire. That code was merely thrown together to have something we can use (and easily modify) for our plugins. External consumption was not really a consideration and I suspect this inevitable shows in many ways. Some of the abstractions and interfaces are way off (or at least odd). There are implicit, target usage based assumptions which might not be generally true, etc.

Of course this does not mean that it could not be split out or get go-submoduled into a reusable package. It's just that in its current shape (and quality) it might not buy you much. And it could require quite a bit of banging to bend it into proper shape.

If you'd be interested in this idea I can prototype / test the out of tree case, although it would be helpful to understand how to create the various plugins. Thanks!

Related to how to create NRI plugins, can you provide a bit more info about what you try to do/what the plugins should accomplish ?

I have nothing against prototyping out of tree usage, if you really think those packages could be useful to you. But at least regarding the sysfs-based topology detection code (and especially the current abstractions), I think it might be a good idea to take a second, closer look to make sure they even remotely do what you need.

@marquiz @kad @askervin WDYT?