Re: Follow up to discussion regarding use : in paths on Windows (MESOS-9109)

[Andrew Schwartzmeyer]

 > 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 it might look funny) right where I'm currently applying the same
but only to `:`.

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.

I'm somewhat comfortable doing so only for Windows, as we don't really
need to worry about the recovery scenario; but very uncomfortable about
doing so for Linux etc., for precisely that reason.

So expanding this is definitely up for debate; but we must fix the bug
with `:`.

Thanks for the feedback,

Andy

On 08/22/2018 5:11 pm, Greg Mann wrote: 

> 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 in? As a 
> starting point, Wikipedia seems to have a decent survey of restrictions on 
> different filesystems here [5]. Looks like the percent character may be fine. 
> 
> I wonder if there are other characters we should be concerned about? I'm 
> guessing we should worry about slashes and backslashes as well? Seems like a 
> more general solution might help us avoid similar pitfalls in the future. 
> Perhaps we could just percent-encode executor and task IDs before we write to 
> disk? If we did this, we would have issues during recovery to consider, where 
> we need to look for "old" paths when recovering state from an "old" agent. 
> 
> In any case, I'm wondering if this warrants a general solution that could 
> take care of all filesystem-disallowed characters. WDYT? 
> 
> Cheers, 
> Greg 
> 
> On Tue, Aug 21, 2018 at 2:02 PM, Andrew Schwartzmeyer 
>  wrote:
> 
>> Hey all,
>> 
>> I have a set of patches up for MESOS-9109 that I need reviewed, starting 
>> here: https://reviews.apache.org/r/68297/ [1].
>> 
>> 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 framework (and task) IDs. Now, to maintain backward 
>> compatibility, we obviously can't disallow the use of `:` as there are 
>> frameworks already using it. However, this is a reserved character on 
>> Windows for file system paths 
>> (https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file [2]), 
>> so it cannot be in the path.
>> 
>> My first implementation simply applied `s/:/_COLON_` to `frameworkId` and 
>> `taskId` in the functions in `paths.cpp` which generate Mesos's filesystem 
>> paths. While this worked, it's kind of a kludge. Or that is to say, it would 
>> nicer to use the ASCII representation of `%3A` instead. Doing so, however, 
>> revealed a bug in libprocess (MESOS-9168) that I have also fixed and need 
>> reviewed, starting here: https://reviews.apache.org/r/68420/ [3]
>> 
>> So combining the two fixes, the chain maps `:` in `frameworkId` and `taskId` 
>> to `%3A` (and back when appropriate). This obviously doesn't fix any 
>> third-party tooling, but being Windows, I don't think there is any yet to 
>> worry about.
>> 
>> I wanted to get this in for 1.7, but due to a miscommunication, we were not 
>> able to land it in time. If you can, please review! Or if you have a better 
>> way of doing this, let me know!
>> 
>> Thanks,
>> 
>> Andy
>> 
>> P.S. Original discussion here: 
>> https://mesos.slack.com/archives/C1LPTK50T/p153332465396 [4] (our Slack 
>> archives seem to be down, so this is only available until Slack cycles out 
>> sadly).

 

Links:
--
[1] https://reviews.apache.org/r/68297/
[2]
https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file
[3] https://reviews.apache.org/r/68420/
[4] https://mesos.slack.com/archives/C1LPTK50T/p153332465396
[5]
https://en.wikipedia.org/wiki/Filename#Comparison_of_filename_limitations

Re: Follow up to discussion regarding use : in paths on Windows (MESOS-9109)

[Greg Mann]

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 in? As a
starting point, Wikipedia seems to have a decent survey of restrictions on
different filesystems here
.
Looks like the percent character may be fine.

I wonder if there are other characters we should be concerned about? I'm
guessing we should worry about slashes and backslashes as well? Seems like
a more general solution might help us avoid similar pitfalls in the future.
Perhaps we could just percent-encode executor and task IDs before we write
to disk? If we did this, we would have issues during recovery to consider,
where we need to look for "old" paths when recovering state from an "old"
agent.

In any case, I'm wondering if this warrants a general solution that could
take care of all filesystem-disallowed characters. WDYT?

Cheers,
Greg


On Tue, Aug 21, 2018 at 2:02 PM, Andrew Schwartzmeyer <
and...@schwartzmeyer.com> wrote:

> 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 framework (and task) IDs. Now, to maintain backward
> compatibility, we obviously can't disallow the use of `:` as there are
> frameworks already using it. However, this is a reserved character on
> Windows for file system paths (https://docs.microsoft.com/en
> -us/windows/desktop/FileIO/naming-a-file), so it cannot be in the path.
>
> My first implementation simply applied `s/:/_COLON_` to `frameworkId` and
> `taskId` in the functions in `paths.cpp` which generate Mesos's filesystem
> paths. While this worked, it's kind of a kludge. Or that is to say, it
> would nicer to use the ASCII representation of `%3A` instead. Doing so,
> however, revealed a bug in libprocess (MESOS-9168) that I have also fixed
> and need reviewed, starting here: https://reviews.apache.org/r/68420/
>
> So combining the two fixes, the chain maps `:` in `frameworkId` and
> `taskId` to `%3A` (and back when appropriate). This obviously doesn't fix
> any third-party tooling, but being Windows, I don't think there is any yet
> to worry about.
>
> I wanted to get this in for 1.7, but due to a miscommunication, we were
> not able to land it in time. If you can, please review! Or if you have a
> better way of doing this, let me know!
>
> Thanks,
>
> Andy
>
> P.S. Original discussion here: https://mesos.slack.com/archiv
> es/C1LPTK50T/p153332465396 (our Slack archives seem to be down, so
> this is only available until Slack cycles out sadly).
>

Re: [VOTE] Release Apache Mesos 1.7.0 (rc1)

[Chun-Hung Hsiao]

Hi all,

The URL for the JAR in the previous email is incorrect.
The JAR is in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1232

Thanks,
Chun-Hung

On Tue, Aug 21, 2018 at 7:34 PM Chun-Hung Hsiao  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.7.0.
>
>
> 1.7.0 includes the following:
>
> 
> * Performance Improvements:
>   * Master `/state` endpoint: ~130% throughput improvement through
> RapidJSON
>   * Allocator: Improved allocator cycle significantly
>   * Agent `/containers` endpoint: Fixed a performance issue
>   * Agent container launch / destroy throughput is significantly improved
> * Containerization:
>   * **Experimental** Supported docker image tarball fetching from HDFS
>   * Added new `cgroups/all` and `linux/devices` isolators
>   * Added metrics for `network/cni` isolator and docker pull latency
> * Windows:
>   * Added support to libprocess for the Windows Thread Pool API
> * Multi-Framework Workloads:
>   * **Experimental** Added per-framework metrics to the master
>   * A new weighted random sorter was added as an alternative to the DRF
> sorter
> * Bug fixes: 84 bugs fixed, including 20 critical ones.
>
> The CHANGELOG for the release is available at:
>
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=1.7.0-rc1
>
> 
>
> The candidate for Mesos 1.7.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/mesos-1.7.0.tar.gz
>
> The tag to be voted on is 1.7.0-rc1:
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.7.0-rc1
>
> The SHA512 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/mesos-1.7.0.tar.gz.sha512
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/mesos-1.7.0.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is in a staging repository here:
>
> https://repository.apache.org/service/local/repositories/orgapachemesos-1232/
>
> Please vote on releasing this package as Apache Mesos 1.7.0!
>
> The vote is open until Fri Aug 24 19:16:39 PDT 2018 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 1.7.0
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Chun-Hung & Gaston
>

Re: [VOTE] Release Apache Mesos 1.7.0 (rc1)

[Alex Rukletsov]

MESOS-9177 has been filed today. It is very likely a regression introduced
by one of the state.json improvements. We are still investigating, but it
is obviously a

-1 (binding)

for rc1.

Alex.


On Wed, Aug 22, 2018 at 4:34 AM, Chun-Hung Hsiao  wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 1.7.0.
>
>
> 1.7.0 includes the following:
> 
> 
> * Performance Improvements:
>   * Master `/state` endpoint: ~130% throughput improvement through
> RapidJSON
>   * Allocator: Improved allocator cycle significantly
>   * Agent `/containers` endpoint: Fixed a performance issue
>   * Agent container launch / destroy throughput is significantly improved
> * Containerization:
>   * **Experimental** Supported docker image tarball fetching from HDFS
>   * Added new `cgroups/all` and `linux/devices` isolators
>   * Added metrics for `network/cni` isolator and docker pull latency
> * Windows:
>   * Added support to libprocess for the Windows Thread Pool API
> * Multi-Framework Workloads:
>   * **Experimental** Added per-framework metrics to the master
>   * A new weighted random sorter was added as an alternative to the DRF
> sorter
> * Bug fixes: 84 bugs fixed, including 20 critical ones.
>
> The CHANGELOG for the release is available at:
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=blob_
> plain;f=CHANGELOG;hb=1.7.0-rc1
> 
> 
>
> The candidate for Mesos 1.7.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/mesos-1.7.0.tar.gz
>
> The tag to be voted on is 1.7.0-rc1:
> https://gitbox.apache.org/repos/asf?p=mesos.git;a=commit;h=1.7.0-rc1
>
> The SHA512 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/
> mesos-1.7.0.tar.gz.sha512
>
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/1.7.0-rc1/
> mesos-1.7.0.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is in a staging repository here:
> https://repository.apache.org/service/local/repositories/
> orgapachemesos-1232/
>
> Please vote on releasing this package as Apache Mesos 1.7.0!
>
> The vote is open until Fri Aug 24 19:16:39 PDT 2018 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 1.7.0
> [ ] -1 Do not release this package because ...
>
> Thanks,
> Chun-Hung & Gaston
>