Plugin API structure

[wilsonehusin]

Describe the solution you'd like

There is a lack of interface for handling image dependencies in Sonobuoy plugins. For example, In Kubernetes conformance testing, we handle dependencies by executing:

docker run -it k8s.gcr.io/conformance:TAG /e2e.test -list-images

Ideally this should be in a better formed API for any plugin to let Sonobuoy know that there are extra container image dependencies.

Anything else you would like to add:
This is a placeholder issue to discuss other requirements which could increase the usability of plugin architecture. Anything is fair game at the moment, the goal is to have a uniform approach for all plugins, not just conformance.

[johnSchnake]

So at a basic level we need a list of images. We could:

• hard code them in the plugin format. Requires the plugin (yaml) to constantly be updated as the actual code/image is as well. Double the overhead and will definitely get out of date.
• Rely on a default-named flag on the image itself. This would mean just making the convention based on what the e2e image does here. We could just say that if any plugin image has extra image dependencies we will always do the same thing: run the plugin first with the --list-images flag to generate a list of images, then process those images based on the context (pull, etc)
• Use a webhook (which is just a fancy hardcoded list and suffers the same problem as that approach)

Am I missing any general approaches you can think of?

It seems to me the easiest approach would be to just require images/plugins that want to use this feature to support that flag by convention.

[stale]

There has not been much activity here. We'll be closing this issue if there are no follow-ups within 15 days.