It seems we have the following issues w.r.t path generation:
1. Path separators are disallowed:
This is general to all systems, so we'll need to put a
platform-independent check. But since no one's doing this we can put this
into the backlog.
2. Other invalid characters on different
I think your approach would be fairly sound. That is, to change the
logic to read the IDs from the info file instead of the paths. But I
also think we can punt this for now (as I do not think a task ID like
'Hello%3AWorld' is plausibly in use right now), and implement a fix for
colons now that
I'm a bit concerned about the recovery logic and backward compatibility:
The changes we're making shouldn't affect existing users,
and we should try hard to avoid any future backward compatibility problem.
Say if there is already some custom framework using task ID 'Hello%3AWorld',
then if we
Thanks Andy! Responses inlined below.
> No: As the only character we've run into a problem with is `:`
> (MESOS-9109), it might not be worth it to generalize this to solve a bunch
> of problems that we haven't encountered.
>
>
It's true that I'm not aware of other scenarios where
> I'm surprised we haven't run into issues like this before on Linux.
Indeed!
> I'm wondering if this warrants a general solution that could take care of all
> filesystem-disallowed characters.
I think yes and no.
Yes: it'd be easy to just `process::http::encode(executorId/taskId)`
(though
Thanks for addressing this Andy!! AFAIK we allow all characters in executor
and task IDs; I'm surprised we haven't run into issues like this before on
Linux.
The percent-encoding approach seems fine to me. As long as the percent
character isn't an issue on any filesystems that we're interested
Hey all,
I have a set of patches up for MESOS-9109 that I need reviewed, starting
here: https://reviews.apache.org/r/68297/.
Eduard here was trying to use Chronos to schedule a task on a Windows
agent, and found an error due to the fact that Chronos uses colons (as
in `:`) in its generated
