Proposal: Allow some paths to be relative and clarify semantics

[reidpr]

Presently, the specification:

1. Disallows relative paths in some places; for example, containerEdits.hooks.path (“that path MUST be absolute”).

2. Doesn’t say anything about relative/absolute in some (most?) places; for example, containerEdits.mounts.hostPath.

I’d like to have the specification, for every place a path is mentioned, state explicitly whether relative paths are allowed, and if so, what they are relative to. This could be rolled up also, e.g. “unless otherwise specified, all paths MUST be absolute”.

My specific use case is that I want to include some CDI specs in Charliecloud’s test suite, and it would be very helpful if those specs could include paths relative to the JSON file. This would allow us to package the JSON spec file alongside all the stuff it refers to.

I am happy to provide a PR if folks are open to this idea.

[elezar]

Thanks for calling out the inconsistency. We should definitely clarify things.

In these cases the objects in the CDI spec are heavily informed by the OCI runtime spec. In the case of the hooks, the restriction on the path is specified in the spec here. I beleive that the intention here is that a the executable that is run needs to be explicitly defined for reasons including security.

In the case of the mounts.hostPath (which maps to source in the OCI Runtime spec) the restriction there is relaxed as a user can specify a relative path in a mount. See here.

My suggestion for the Charliecloud tests specifically is to include a "template" as part of the test suite and then generate the specifications for a specific test run. Is this something that would be feasible to you?