Spec discussion: Should plugins support a top level container_spec?

[aaronsteers]

We considered supporting a plugin-level container_spec option when we released the container_spec feature. The two reasons we declined a plugin-level container_spec at the time were:

Challenge 1. Problematic UX around inheritance between the plugin and its commands.

There are a number of confusing and difficult-to-impossible UX problems that inheritance would create:

1. The plugin defines a specific image and default port mappings. When a command is declared to run under a different image, does it still inherit the default port mappings?
2. If ports are defined on the parent image, does this mean that no two commands can ever be run simultaneously. (At the command level, we solve this by only claiming ports for commands that need them.)
3. Same inheritance problem with volumes. If some commands don't need volumes, they nevertheless would be inherited by default from a top-level declaration.

Note:

• The best mitigation for these UX issues is to probably for the plugin author to negate the plugin-level container_spec settings with explicit (often empty) command-level ones; however, then we end up with a solution which is potentially more verbose and less intuitive (perhaps harder to read/debug) than relying on self-contained command-level specs.
• Another mitigation would be

Challenge 2. Unclear resolution path for commands that themselves do not have container_spec defined

The presence of a container_spec at the plugin level implies that the entire plugin supports containerization and would inherit the spec of the plugin which is parent to the command. However, there are clear cases where this should not be the case. Just because a plugin has some commands that have a container_spec, this does not imply that all commands are containerizable.

1. A pull_image command which would be run before the image is available to run - and which itself would fail if run from inside the container.
2. Some proposals (and our own natural intuitions) may also suggest that if the plugin contains a plugin-level container_spec, then args and/or executable would/could/should be executable from within that spec. However, this is not the case, since the (native/local) executable and args would be designed to executing locally, and often would be different than the syntax and args needed within that command's container_spec declaration.