Re: Documentation for Mesos On windows

[Andrew Schwartzmeyer]

 Hi sweta Das,

The mesos-master executable is not currently built on Windows. We're
waiting for leveldb to be ported to Windows to enable it
(https://github.com/google/leveldb/issues/519); however, most of the
code works anyway (as evidenced by `StartMaster()` in unit tests etc.).

If you'd like to try to build it, you can edit this code
https://github.com/apache/mesos/blob/5574681ddc7e053fd33c074023ff317394f6449c/src/master/CMakeLists.txt#L18
and remove the "NOT WIN32" guard around compiling the executable. I
can't promise it'll work though, I haven't yet gotten to try it.

Let me know how it goes!

Thanks,

Andy

On 11/29/2017 6:34 pm, Benjamin Mahler wrote: 

> +Andrew 
> 
> On Tue, Nov 28, 2017 at 5:41 PM, sweta Das  wrote:
> 
>> Hi 
>> 
>> Is there any other documentation than the one on mesos site 
>> http://mesos.apache.org/documentation/latest/windows/ [1] 
>> 
>> I was able to build mesos on AWS on an windows 2016 server. But I am not 
>> able to find any docs for starting the mesos master on windows? 
>> I understand that this is not recommended as of now, but for testing can 
>> anyone tell how can i start a master on windows?
>> 
>> Sent from my iPhone
 

Links:
--
[1] http://mesos.apache.org/documentation/latest/windows/

Re: Documentation for Mesos On windows

[Benjamin Mahler]

+Andrew

On Tue, Nov 28, 2017 at 5:41 PM, sweta Das  wrote:

> Hi
>
> Is there any other documentation than the one on mesos site
> http://mesos.apache.org/documentation/latest/windows/
>
> I was able to build mesos on AWS on an windows 2016 server. But I am not
> able to find any docs for starting the mesos master on windows?
> I understand that this is not recommended as of now, but for testing can
> anyone tell how can i start a master on windows?
>
> Sent from my iPhone
>

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

[Benjamin Mahler]

+1 (binding)

make check on macOS 10.13.1

On Wed, Nov 29, 2017 at 9:17 PM, Adam Bordelon  wrote:

> +1 (binding)
>
> Passed all tests in DC/OS integration CI, with a bump to 1.2.x at f8706e5,
> just one changelog update before 1.2.3-rc1.
> https://github.com/dcos/dcos/pull/2104#pullrequestreview-79333676
>
> On Tue, Nov 21, 2017 at 2:46 PM, Vinod Kone  wrote:
>
>> +1 (binding)
>>
>> Tested on ASF CI. The failures are due to 2 issues 1) perf core dump
>>  which was fixed in
>> 1.5.0 and 2) flaky oversubscription test
>>  also fixed in 1.5.0.
>>
>> *Revision*: 7559c9352c78912526820f6222ed2b17ad3b19cf
>>
>>- refs/tags/1.2.3-rc1
>>
>> Configuration Matrix gcc clang
>> centos:7 --verbose --enable-libevent --enable-ssl autotools
>> [image: Success]
>> 
>> [image: Not run]
>> cmake
>> [image: Success]
>> 
>> [image: Not run]
>> --verbose autotools
>> [image: Success]
>> 
>> [image: Not run]
>> cmake
>> [image: Success]
>> 
>> [image: Not run]
>> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
>> [image: Failed]
>> 
>> [image: Failed]
>> 
>> cmake
>> [image: Failed]
>> 
>> [image: Success]
>> 
>> --verbose autotools
>> [image: Success]
>> 
>> [image: Failed]
>> 
>> cmake
>> [image: Success]
>> 
>> [image: Success]
>> 
>>
>> On Wed, Nov 15, 2017 at 9:57 PM, Adam Bordelon 
>> wrote:
>>
>>> Hi all,
>>>
>>> Please vote on releasing the following candidate as Apache Mesos 1.2.3.
>>> 1.2.3 is our last scheduled bug fix release in the 1.2.x branch.
>>>
>>> The CHANGELOG for the release is available at:
>>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>>> lain;f=CHANGELOG;hb=1.2.3-rc1
>>> 
>>> 
>>>
>>> 

Re: Persistent volumes

[Benjamin Mahler]

+jpeach

The polling mechanism is used by the "disk/du" isolator to handle the case
where we don't have filesystem support for enforcing a quota on a
per-directory basis. I believe the "disk/xfs" isolator will stop writes
with EDQUOT without killing the task:

http://mesos.apache.org/documentation/latest/isolators/disk-xfs/

On Tue, Nov 28, 2017 at 1:19 PM, Gabriel Hartmann 
wrote:

> I agree with pretty much everything Hendrik just said with the exception
> of the use of disk quota.  The polling mechanism employed for enforcing
> disk usage implies that any breach of the disk usage limit by a Task also
> implies loss of access to that data forever.  This is true for ROOT volumes
> at least.  MOUNT volumes can be configured to map to "real" devices which
> can provide normal write failures when exceeding disk limits instead of
> essentially revoking all access to data forever.
>
> On Mon, Nov 27, 2017 at 11:34 PM Hendrik Haddorp 
> wrote:
>
>> As said, I only use persistent volumes with my only scheduler straight
>> on Mesos so do not exactly know how this works in Marathon...
>>
>> The persistent volume is created on a Mesos agent and basically ends up
>> being a folder on that hosts disk. So yes, you can not use the volume on
>> a different agent/slave. For marathon you would need to set a hostname
>> constraint that makes sure the same host is used when restarting the
>> task. You won't be able to use fail over to different agents just have
>> Marathon restart your task once it fails. Also only one task at a time
>> can have the volume bound.
>>
>> Yes, you can achieve persistence in pretty much the same way by using a
>> hostpath but then you are using implicit knowledge about your
>> environment, which is not very clean in my opinion, and thus have a
>> tighter coupling. The nice thing about persistent volumes is that they
>> are managed by Mesos. I do not need to tell the Mesos admin that I need
>> space at some location. I do not need to do something special if I have
>> multiple instances running as they get all their own directory. And I
>> can programatically destroy the volume and then the directory on the
>> host gets deleted again (at least since Mesos 1.0). So in my opinion the
>> usage of persistent volumes is much cleaner. But there are certainly use
>> cases that do not really work with them, like being able to fail over to
>> different host. For that you would wither need a shared network mount or
>> storage like HDFS. Btw, the Mesos containerizer should also enforce disk
>> quotas so your task would not be able to fill the filesystem.
>>
>> On 27.11.2017 16:11, Dino Lokmic wrote:
>> > yes I did. So I don't have to prepare it before task? I can't use
>> > volume created on slave A, from slave B
>> >
>> > Once task fails where will it be restarted? Do I have to specify host?
>> >
>> > If I do, it means I can achieve "persistence" same way I deploy now,
>> > by specifying hostpath for volume and hostname
>> >
>> > 
>> >   "constraints": [
>> > [
>> >   "hostname",
>> >   "CLUSTER",
>> >   "MYHOSTNAME"
>> > ]
>> >   ],
>> >   "container": {
>> > "type": "DOCKER",
>> > "volumes": [
>> >   {
>> > "containerPath": "/opt/storm/storm-local",
>> > "hostPath": "/opt/docker_data/storm/storm-local",
>> > "mode": "RW"
>> >   },
>> >   {
>> > "containerPath": "/opt/storm/logs",
>> > "hostPath": "/opt/docker_logs/storm/logs",
>> > "mode": "RW"
>> >   },
>> >   {
>> > "containerPath": "/home/xx/runtime/storm",
>> > "hostPath": "/home/xx/runtime/storm",
>> > "mode": "RO"
>> >   }
>> > ],
>> > "docker": {
>> >   "image": "xxx/storm-1.1.0",
>> >   "network": "HOST",
>> >   "portMappings": [],
>> >   "privileged": false,
>> >   "parameters": [],
>> >   "forcePullImage": true
>> > }
>> >   },
>> >
>> > 
>> >
>> >
>> >
>> > On Mon, Nov 27, 2017 at 3:05 PM, Hendrik Haddorp
>> > > wrote:
>> >
>> > I have my own scheduler that is performing a create operation. As
>> > you are using Marathon this call would have to be done by Marathon.
>> > Did you read
>> > https://mesosphere.github.io/marathon/docs/persistent-volumes.html
>> > 
>> ?
>> >
>> > On 27.11.2017 14:59, Dino Lokmic wrote:
>> >
>> > @hendrik
>> >
>> > How did you create this
>> > "my-volume-227927c2-3266-412b-8572-92c5c93c051a" volume?
>> >
>> > On Mon, Nov 27, 2017 at 7:59 AM, Hendrik Haddorp
>> > 
>> > > > >> wrote:
>> >
>> > Hi,
>> >
>> > I'm using persistent volumes directly on Mesos, without

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

[Adam Bordelon]

+1 (binding)

Passed all tests in DC/OS integration CI, with a bump to 1.2.x at f8706e5,
just one changelog update before 1.2.3-rc1.
https://github.com/dcos/dcos/pull/2104#pullrequestreview-79333676

On Tue, Nov 21, 2017 at 2:46 PM, Vinod Kone  wrote:

> +1 (binding)
>
> Tested on ASF CI. The failures are due to 2 issues 1) perf core dump
>  which was fixed in
> 1.5.0 and 2) flaky oversubscription test
>  also fixed in 1.5.0.
>
> *Revision*: 7559c9352c78912526820f6222ed2b17ad3b19cf
>
>- refs/tags/1.2.3-rc1
>
> Configuration Matrix gcc clang
> centos:7 --verbose --enable-libevent --enable-ssl autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> --verbose autotools
> [image: Success]
> 
> [image: Not run]
> cmake
> [image: Success]
> 
> [image: Not run]
> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
> [image: Failed]
> 
> [image: Failed]
> 
> cmake
> [image: Failed]
> 
> [image: Success]
> 
> --verbose autotools
> [image: Success]
> 
> [image: Failed]
> 
> cmake
> [image: Success]
> 
> [image: Success]
> 
>
> On Wed, Nov 15, 2017 at 9:57 PM, Adam Bordelon  wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 1.2.3.
>> 1.2.3 is our last scheduled bug fix release in the 1.2.x branch.
>>
>> The CHANGELOG for the release is available at:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_p
>> lain;f=CHANGELOG;hb=1.2.3-rc1
>> 
>> 
>>
>> The candidate for Mesos 1.2.3 release is available at:
>> https://dist.apache.org/repos/dist/dev/mesos/1.2.3-rc1/mesos-1.2.3.tar.gz
>>
>> The tag to be voted on is 1.2.3-rc1:
>>