Make cwd an abs path to avoid ambiguity

[duglin]

Signed-off-by: Doug Davis [email protected]

[jonboulle]

might want to consider behaviour if that path doesn't exist

[duglin]

hmm good point - I'll try to cover that in my change to the definition of the ops (in particular 'start') since that's when it matters.

[mrunalp]

Hmm, not sure if we should cover details for every misconfigured property. Does a catch all like "runtime will return an error if the config is invalid for properties that couldn't be validated statically" work? (Not here, but maybe in ops as @duglin suggested).

[duglin]

I didn't view this as a misconfiguraton issue - per se. I viewed @jonboulle's comment as:
1 - make sure we say that during a start the process must be run from the cwd (which I forgot to mention in my ops PR)
2 - make sure impls generate an error instead of creating the missing cwd - which some may think is a valid thing to do. Both are valid options but we need consistency and in this case I think erroring out is the better choice.

[wking]

On Fri, Jan 15, 2016 at 10:00:44AM -0800, Doug Davis wrote:

I didn't view this as a misconfiguraton issue - per se. I viewed
@jonboulle's comment as:
1 - make sure we say that during a start the process must be run
from the cwd (which I forgot to mention in my ops PR)
2 - make sure impls generate an error instead of creating the
missing cwd - which some may think is a valid thing to do. Both
are valid options but we need consistency and in this case I
think erroring out is the better choice.

These both sound valid to me, but seem orthogonal to whether cwd is
absolute/relative or required/optional.

For (2), I'd just say “If the cwd doesn't exist, the runtime MUST log
an error and jump to the cleanup step ($LIFECYLE_LINK). The runtime
MUST NOT create the missing directory.”

[duglin]

Whether cwd is required or not is a different issue/PR so its out of scope of this PR.

Given its required, I think abs path is the only valid choice - relative (w/o defining the starting point, which is what making cwd required was trying to avoid) makes no sense from an interop perspective.

The error stuff (in 2) is for the ops PR I'm still tweaking.

[wking]

On Fri, Jan 15, 2016 at 10:26:51AM -0800, Doug Davis wrote:

-* cwd (string, required) is the working directory that will be set for the executable.
+* cwd (string, required) is the working directory that will be set for the executable. This value MUST be an absolute path.

Whether cwd is required or not is a different issue/PR so its out of scope of this PR.

Given its required, I think abs path is the only valid choice…

I agree on both points. But since #307 is only two days old (from
proposal to merge), I thought I'd give folks another chance to revisit
before too much time was sunk in implementation details (like this PR)
for a feature I don't think we need (#307). If #307 is already locked
in, then yeah, I think this PR is the only sensible way forward.

[wking]

This seems like a bunch of spec/runtime hoop jumping to force config
authors to avoid getting bitten by their platform's default 1. Is
the platform-default workding directory that terrible? I'd rather
just revert #307. Bundle authors who don't trust their platform, or
who want something other than their platform's default, or who don't
want to bother figuring out their platform's default, etc. would still
be free to set process.cwd if they wanted.

 Subject: Exposing platform defaults
 Date: Thu, 14 Jan 2016 15:36:26 -0800
 Message-ID: <[email protected]>

[mrunalp]

@wking I see your point and agree about being consistent one way or the other.

[crosbymichael]

LGTM

[mrunalp]

LGTM