Re: mesos git commit: Added documentation for access_sandboxes and access_mesos_logs acls.

[Alexander Rojas]

Sorry guys, that was an oversight. I added reviews:

https://reviews.apache.org/r/48310/  - 
Fixes some endpoint spaces in docs.
https://reviews.apache.org/r/48311/  - 
Result of running the script.

> On 06 Jun 2016, at 23:54, Adam Bordelon  wrote:
> 
> Good point. Vinod was working on the endpoints script right next to me, but
> I guess he did his pre-release run before I committed Alexander's change.
> We'll have to do another run before rc2.
> 
> On Mon, Jun 6, 2016 at 5:36 AM, Neil Conway  wrote:
> 
>> FYI, this commit should have included the changes produced by
>> re-running the `generate-endpoint.py` script.
>> 
>> Neil
>> 
>> On Wed, Jun 1, 2016 at 8:26 AM,   wrote:
>>> Repository: mesos
>>> Updated Branches:
>>>  refs/heads/master 5263a6211 -> 53b5164bb
>>> 
>>> 
>>> Added documentation for access_sandboxes and access_mesos_logs acls.
>>> 
>>> Modifies the file `acls.proto` to take into consideration the added
>>> authorization actions `access_sandboxes` and `access_mesos_logs`.
>>> 
>>> Review: https://reviews.apache.org/r/48048/
>>> 
>>> 
>>> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/53b5164b
>>> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/53b5164b
>>> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/53b5164b
>>> 
>>> Branch: refs/heads/master
>>> Commit: 53b5164bb51ebe850dec5ab19b8382f5c4a59391
>>> Parents: 5263a62
>>> Author: Alexander Rojas 
>>> Authored: Tue May 31 23:20:50 2016 -0700
>>> Committer: Adam B 
>>> Committed: Tue May 31 23:24:55 2016 -0700
>>> 
>>> --
>>> docs/authorization.md |  2 ++
>>> src/files/files.cpp   | 34 +++---
>>> 2 files changed, 33 insertions(+), 3 deletions(-)
>>> --
>>> 
>>> 
>>> 
>> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/docs/authorization.md
>>> --
>>> diff --git a/docs/authorization.md b/docs/authorization.md
>>> index 0e58b9b..189b70d 100644
>>> --- a/docs/authorization.md
>>> +++ b/docs/authorization.md
>>> @@ -131,6 +131,8 @@ entries, each representing an authorizable action:
>>> |`view_framework`|UNIX user of whom executors can be
>> viewed.|`Framework_Info` which can be viewed.|Filtering http endpoints.|
>>> |`view_executor`|UNIX user of whom executors can be
>> viewed.|`Executor_Info` and `Framework_Info` which can be viewed.|Filtering
>> http endpoints.|
>>> |`view_task`|UNIX user of whom tasks can be viewed.|(`Task` or
>> `Task_Info`) and `Framework_Info` which can be viewed.|Filtering http
>> endpoints.|
>>> +|`access_sandboxes`|Operator username.|Operating system user whose
>> executor/task sandboxes can be accessed.|Access task sandboxes.|
>>> +|`access_mesos_logs`|Operator username.|Implicitly given. A user should
>> only use types ANY and NONE to allow/deny access to the log.|Access Mesos
>> logs.|
>>> 
>>> ### Examples
>>> 
>>> 
>>> 
>> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/src/files/files.cpp
>>> --
>>> diff --git a/src/files/files.cpp b/src/files/files.cpp
>>> index 873664d..094a00c 100644
>>> --- a/src/files/files.cpp
>>> +++ b/src/files/files.cpp
>>> @@ -57,6 +57,7 @@
>>> using namespace process;
>>> 
>>> using process::AUTHENTICATION;
>>> +using process::AUTHORIZATION;
>>> using process::DESCRIPTION;
>>> using process::HELP;
>>> using process::TLDR;
>>> @@ -295,7 +296,16 @@ const string FilesProcess::BROWSE_HELP = HELP(
>>> "Query parameters:",
>>> "",
>>> ">path=VALUE  The path of directory to
>> browse."),
>>> -AUTHENTICATION(true));
>>> +AUTHENTICATION(true),
>>> +AUTHORIZATION(
>>> +"Browsing files requires that the request principal is ",
>>> +"authorized to do so for the target virtual file path.",
>>> +"",
>>> +"Authorizers may categorize different virtual paths into",
>>> +"different ACLs, e.g. logs in one and task sandboxes in",
>>> +"another.",
>>> +"",
>>> +"See authorization documentation for details."));
>>> 
>>> 
>>> Future FilesProcess::authorize(
>>> @@ -409,7 +419,16 @@ const string FilesProcess::READ_HELP = HELP(
>>> ">offset=VALUEValue added to base address to
>> obtain "
>>> "a second address",
>>> ">length=VALUELength of file to read."),
>>> -AUTHENTICATION(true));
>>> +AUTHENTICATION(true),
>>> +AUTHORIZATION(
>>> +"Reading files requires that the request principal is ",
>>> +"authorized to do so for the target 

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

[Robert Lacroix]

Hi Vinod,

In convert.cpp 
 we 
compare the major versions of the native library and the jar. This makes 
upgrading frameworks unnecessarily hard because you would have to deploy Mesos 
and frameworks in lockstep.

Non-binding -1 , as this check isn’t strictly useful - especially given this 
is probably the last major upgrade where libmesos is even relevant.

 Robert

> On Jun 1, 2016, at 12:38 AM, Vinod Kone  > wrote:
> 
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 1.0.0.
> 
> 
> NOTE: The voting period for this release is 3 weeks. Also, we are willing
> to make API changes before the final release. So please test it thoroughly.
> 
> 
> 1.0.0 includes the following features:
> 
> 
> 
>  * Scheduler and Executor v1 HTTP APIs are now considered stable.
> 
> 
> 
> 
> 
>  * [MESOS-4791] - **Experimental** support for v1 Master and Agent APIs.
> These
> 
>APIs let operators and services (monitoring, load balancers) send HTTP
> 
> 
>requests to '/api/v1' endpoint on master or agent. These APIs look
> similar
> 
>to the v1 Scheduler and Executor APIs.
> 
> 
> 
> 
> 
>  * [MESOS-4828] - **Experimental** support for a new `disk/xfs' isolator
> 
> 
>has been added to isolate disk resources more efficiently. Please refer
> to
> 
>docs/mesos-containerizer.md for more details.
> 
> 
> 
> 
> 
>  * [MESOS-4355] - **Experimental** support for Docker volume plugin. We
> added a
> 
>new isolator 'docker/volume' which allows users to use external volumes
> in
> 
>Mesos containerizer. Currently, the isolator interacts with the Docker
> 
> 
>volume plugins using a tool called 'dvdcli'. By speaking the Docker
> volume
> 
>plugin API, most of the Docker volume plugins are supported.
> 
> 
> 
> 
> 
>  * [MESOS-4641] - **Experimental** A new network isolator, the
> 
> 
>`network/cni` isolator, has been introduced in the
> `MesosContainerizer`. The
> 
>`network/cni` isolator implements the Container Network Interface (CNI)
> 
> 
>specification proposed by CoreOS.  With CNI the `network/cni` isolator
> is
> 
>able to allocate a network namespace to Mesos containers and attach the
> 
> 
>container to different types of IP networks by invoking network drivers
> 
> 
>called CNI plugins.
> 
> 
> 
> 
> 
>  * [MESOS-2948, MESOS-5403] - The authorizer interface has been refactored
> in
> 
>order to decouple the ACLs definition language from the interface.
> 
> 
>It additionally includes the option of retrieving `ObjectApprover`. An
> 
> 
>`ObjectApprover` can be used to synchronously check authorizations for
> a
> 
>given object and is hence useful when authorizing a large number of
> objects
> 
>and/or large objects (which need to be copied using request based
> 
> 
>authorization). NOTE: This is a **breaking change** for authorizer
> modules.
> 
> 
> 
> 
>  * [MESOS-4931] - Authorization based HTTP endpoint filtering enables
> operators
> 
>to restrict what part of the cluster state a user is authorized to see.
> 
> 
>Consider for example the `/state` master endpoint: an operator can now
> 
> 
>authorize users to only see a subset of the running frameworks, tasks,
> or
> 
>executors.
> 
> 
> 
> 
> 
>  * [MESOS-4909] - Tasks can now specify a kill policy. They are
> best-effort,
> 
>because machine failures or forcible terminations may occur. Currently,
> the
> 
>only available kill policy is how long to wait between graceful and
> forcible
> 
>task kill. In the future, more policies may be available (e.g. hitting
> an
> 
>HTTP endpoint, running a command, etc). Note that it is the executor's
> 
> 
>responsibility to enforce kill policies. For executor-less
> command-based
> 
>tasks, the kill is performed via sending a signal to the task process:
> 
> 
>SIGTERM for the graceful kill and SIGKILL for the forcible kill. For
> docker
> 
>executor-less tasks the grace period is passed to 'docker stop --time'.
> This
> 
>feature supersedes the '--docker_stop_timeout', which is now
> deprecated.
> 
> 
> 
> 
>  * [MESOS-4908] - The task kill policy defined within 'TaskInfo' can now
> be
> 
>overridden when the scheduler kills the task. This can be used by
> schedulers
> 
>to forcefully kill a task which is already being killed, e.g. if
> something
> 
>went wrong during a graceful kill and a forcible kill is desired. Note
> that
> 
>it is the executor's responsibility to honor the
> 'Event.kill.kill_policy'
> 
>field and override the task's kill policy and kill policy from a
> previous
> 
>kill task request. To use this feature, schedulers and executors must
> 
> 
>support HTTP API; use the '--http_command_executor' agent flag to
> ensure
> 
>  

Re: mesos/kafka issues (reviving old thread)

[Vinit Mahedia]

Vinod,

In my case, have two vagrant VMs, one where mesos-master runs and
frameworks on another.
This is my dev/debug setup where both marathon and kafka frameworks are
failing not just kafka.

But we do have a real (bare metal machines cluster) running marathon
successfully but kafka
framework fails there. I have tried both framework as a docker image and
running it directly on
machine.

I have the debugging environment setup, I see requests successfully
completed on master, it even
(thinks) it sends successfully, but framework never receives it. Nothing
can be seen on packet capture
as well which confuses me.


On Mon, Jun 6, 2016 at 2:23 PM, Vinod Kone  wrote:

> ZK communication is little different from framework communication. In the
> former case, the ZK client library inside master opens up a connection to
> the ZK server ensemble. In the latter case, the scheduler driver inside the
> framework scheduler opens up a connection to the mesos master. But it is
> strange that marathon from a different remote host works fine but
> kafka-mesos from a different remote host has issues.
>
> On Mon, Jun 6, 2016 at 3:12 PM, Justin Ryan  wrote:
>
> > inline
> >
> > On 6/6/16, 8:40 AM, "Vinod Kone"  wrote:
> >
> > >Have you tried running a different framework than the kafka one (maybe
> > marathon? or chronos?) to rule out framework related issues? I'm
> surprised
> > that it works when the scheduler and master are on the same host but not
> > when they are different.
> > > Looks like the request packets are getting dropped somewhere between
> the
> > master NIC and the application.
> > >
> >
> > Marathon is working just fine, I have flume running via Marathon and
> kafka
> > running via kafka-mesos.
> >
> > Yah, it does seem like the request packets are getting dropped, but that
> > makes no sense – how can the mesos-masters and zookeepers communicate
> with
> > each other, but an arbitrary other process can’t communicate with the
> > active mesos-master from another host which is a mesos-master? I’ve done
> a
> > lot of packet inspection and can do more, but overwhelmingly this seems
> to
> > anchor the notion that there is no firewall in play.
> >
> > 
> >
> > P Please consider the environment before printing this e-mail
> >
> > The information in this electronic mail message is the sender's
> > confidential business and may be legally privileged. It is intended
> solely
> > for the addressee(s). Access to this internet electronic mail message by
> > anyone else is unauthorized. If you are not the intended recipient, any
> > disclosure, copying, distribution or any action taken or omitted to be
> > taken in reliance on it is prohibited and may be unlawful. The sender
> > believes that this E-mail and any attachments were free of any virus,
> worm,
> > Trojan horse, and/or malicious code when sent. This message and its
> > attachments could have been infected during transmission. By reading the
> > message and opening any attachments, the recipient accepts full
> > responsibility for taking protective and remedial action about viruses
> and
> > other defects. The sender's employer is not liable for any loss or damage
> > arising in any way.
> >
>



-- 
~Vinit

Re: mesos/kafka issues (reviving old thread)

[Justin Ryan]

Right, mentioning ZK may have been a distraction.

My point was that the inactive mesos-master on the host running kafka-mesos 
scheduler is communicating with the active mesos-master.

To elaborate, this problem currently arises when a mesos-master failover 
occurs.  If I shut off the active master briefly and cause a failover back to 
the host running kafka-mesos, it starts working again.

The idea of sharing this was simply to elaborate that there’s no way port 5050 
of the mesos-master is inaccessible from the host running kafka-mesos, as mesos 
itself is communicating between those two hosts with that port.

On 6/6/16, 12:23 PM, "Vinod Kone"  wrote:

>ZK communication is little different from framework communication. In the 
>former case, the ZK client library inside master opens up a connection to the 
>ZK server ensemble. In the latter case, the scheduler driver inside the 
>framework scheduler
> opens up a connection to the mesos master. But it is strange that marathon 
> from a different remote host works fine but kafka-mesos from a different 
> remote host has issues.
>




P Please consider the environment before printing this e-mail

The information in this electronic mail message is the sender's confidential 
business and may be legally privileged. It is intended solely for the 
addressee(s). Access to this internet electronic mail message by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. The sender believes that this E-mail and any 
attachments were free of any virus, worm, Trojan horse, and/or malicious code 
when sent. This message and its attachments could have been infected during 
transmission. By reading the message and opening any attachments, the recipient 
accepts full responsibility for taking protective and remedial action about 
viruses and other defects. The sender's employer is not liable for any loss or 
damage arising in any way.

Re: Mesos HA does not work (Failed to recover registrar)

[Chengwei Yang]

@Qian,

I think you're running issues with firewall, did you make sure your master can
reach from each other?

FROM master A
$ telnet B 5050

I think it fail to connect.

Please ensure shutdown any firewall.

-- 
Thanks,
Chengwei

On Mon, Jun 06, 2016 at 09:06:43PM +0800, Qian Zhang wrote:
> I deleted everything in the work dir (/var/lib/mesos/master), and tried again,
> the same error still happened :-(
> 
> 
> Thanks,
> Qian Zhang
> 
> On Mon, Jun 6, 2016 at 3:03 AM, Jean Christophe “JC” Martin <
> jch.mar...@gmail.com> wrote:
> 
> Qian,
> 
> Zookeeper should be able to reach a quorum with 2, no need to start 3
> simultaneously, but there is an issue with Zookeeper related to connection
> timeouts.
> https://issues.apache.org/jira/browse/ZOOKEEPER-2164
> In some circumstances, the timeout is higher than the sync timeout, which
> cause the leader election to fail.
> Try setting the parameter cnxtimeout in zookeeper (by default it’s 5000ms)
> to the value 500 (500ms). After doing this, leader election in ZK will be
> super fast even if a node is disconnected.
>
> JC
>
> > On Jun 4, 2016, at 4:34 PM, Qian Zhang  wrote:
> >
> > Thanks Vinod and Dick.
> >
> > I think my 3 ZK servers have formed a quorum, each of them has the
> > following config:
> >    $ cat conf/zoo.cfg
> >    server.1=192.168.122.132:2888:3888
> >    server.2=192.168.122.225:2888:3888
> >    server.3=192.168.122.171:2888:3888
> >    autopurge.purgeInterval=6
> >    autopurge.snapRetainCount=5
> >    initLimit=10
> >    syncLimit=5
> >    maxClientCnxns=0
> >    clientPort=2181
> >    tickTime=2000
> >    quorumListenOnAllIPs=true
> >    dataDir=/home/stack/packages/zookeeper-3.4.8/snapshot
> >    dataLogDir=/home/stack/packages/zookeeper-3.4.8/transactions
> >
> > And when I run "bin/zkServer.sh status" on each of them, I can see 
> "Mode:
> > leader" for one, and "Mode: follower" for the other two.
> >
> > I have already tried to manually start 3 masters simultaneously, and 
> here
> > is what I see in their log:
> > In 192.168.122.171(this is the first master I started):
> >    I0605 07:12:49.418721  1187 detector.cpp:152] Detected a new leader:
> > (id='25')
> >    I0605 07:12:49.419276  1186 group.cpp:698] Trying to get
> > '/mesos/log_replicas/24' in ZooKeeper
> >    I0605 07:12:49.420013  1188 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> >    I0605 07:12:49.423807  1188 zookeeper.cpp:259] A new leading master
> > (UPID=master@192.168.122.171:5050) is detected
> >    I0605 07:12:49.423841 1186 network.hpp:461] ZooKeeper group PIDs: {
> > log-replica(1)@192.168.122.171:5050 }
> >    I0605 07:12:49.424281 1187 master.cpp:1951] The newly elected leader
> > is master@192.168.122.171:5050 with id
> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
> >    I0605 07:12:49.424895  1187 master.cpp:1964] Elected as the leading
> > master!
> >
> > In 192.168.122.225 (second master I started):
> >    I0605 07:12:51.918702  2246 detector.cpp:152] Detected a new leader:
> > (id='25')
> >    I0605 07:12:51.919983  2246 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> >    I0605 07:12:51.921910  2249 network.hpp:461] ZooKeeper group PIDs: {
> > log-replica(1)@192.168.122.171:5050 }
> >    I0605 07:12:51.925721 2252 replica.cpp:673] Replica in EMPTY status
> > received a broadcasted recover request from (6)@192.168.122.225:5050
> >    I0605 07:12:51.927891  2246 zookeeper.cpp:259] A new leading master
> > (UPID=master@192.168.122.171:5050) is detected
> >    I0605 07:12:51.928444 2246 master.cpp:1951] The newly elected leader
> > is master@192.168.122.171:5050 with id
> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
> >
> > In 192.168.122.132 (last master I started):
> > I0605 07:12:53.553949 16426 detector.cpp:152] Detected a new leader:
> > (id='25')
> > I0605 07:12:53.555179 16429 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> > I0605 07:12:53.560045 16428 zookeeper.cpp:259] A new leading master 
> (UPID
> =
> > master@192.168.122.171:5050) is detected
> >
> > So right after I started these 3 masters, the first one 
> (192.168.122.171)
> > was successfully elected as leader, but after 60s, 192.168.122.171 
> failed
> > with the error mentioned in my first mail, and then 192.168.122.225 was
> > elected as leader, but it failed with the same error too after another
> 60s,
> > and the same thing happened to the last one (192.168.122.132). So after
> > about 180s, all my 3 master were down.
> >
> > I tried both:
> >    sudo ./bin/mesos-master.sh --zk=zk://127.0.0.1:2181/mesos --quorum=2
> > 

Re: Mesos 0.24.1 on Raspberry Pi 3

[Benjamin Mahler]

Cool stuff Andrew, thanks for sharing!

On Thu, Jun 2, 2016 at 11:50 AM, Andrew Spyker 
wrote:

> FYI, based on the work others have done in the past, Netflix was able to
> get Mesos agent building and running on Raspberry Pi natively and under
> Docker containers.  Please see this blog for the information:
>
> bit.ly/TitusOnPi
>
> --
> Andrew Spyker (aspy...@netflix.com)
> Twitter:  @aspyker  Blog:  ispyker.blogspot.com
>

Re: Status acknowledgements in MesosExecutor

[Anand Mazumdar]

Hi Evers,

Thanks for taking this on. Vinod has agreed to shepherd this and I would be 
happy to be the initial reviewer for the patches.

-anand


> On Jun 1, 2016, at 10:27 AM, Evers Benno  wrote:
> 
> Some more context about this bug:
> 
> We did some tests with a framework that does nothing but send empty
> tasks and sample executor that does nothing but send TASK_FINISHED and
> shut itself down.
> 
> Running on two virtual machines on the same host (i.e. no network
> involved), we see TASK_FAILED in about 3% of all tasks (271 out of
> 9000). Adding some megabytes of data into update.data, this can go up
> to 80%. In all cases where I looked manually, the logs look like this:
> (id's shortened to three characters for better readability)
> 
> [...]
> I0502 14:40:33.151075 394179 slave.cpp:3002] Handling status update
> TASK_FINISHED (UUID: 20c) for task 24c of framework f20 from
> executor(1)@[2a02:6b8:0:1a16::165]:49266
> I0502 14:40:33.151175 394179 slave.cpp:3528]
> executor(1)@[2a02:6b8:0:1a16::165]:49266 exited
> I0502 14:40:33.151190 394179 slave.cpp:3886] Executor 'executor_24c' of
> framework f20 exited with status 0
> I0502 14:40:33.151216 394179 slave.cpp:3002] Handling status update
> TASK_FAILED (UUID: 01b) for task 24c of framework f20 from @0.0.0.0:0
> [...]
> 
> The random failure chance is a bit too high to ignore, so we're
> currently writing/testing a patch to wait for confirmations for all
> status updates on executor shutdown.
> 
> It would be great if someone would like to shepherd this.
> 
> Best regards,
> Benno
> 
> On 03.05.2016 14:49, Evers Benno wrote:
>> Hi,
>> 
>> I was wondering about the semantics of the Executor::sendStatusUpdate()
>> method. It is described as
>> 
>>// Sends a status update to the framework scheduler, retrying as
>>// necessary until an acknowledgement has been received or the
>>// executor is terminated (in which case, a TASK_LOST status update
>>// will be sent). See Scheduler::statusUpdate for more information
>>// about status update acknowledgements.
>> 
>> I was understanding this to say that the function blocks until an
>> acknowledgement is received, but looking at the implementation of
>> MesosExecutor it seems that "retrying as necessary" only means
>> re-sending of unacknowledged updates when the slave reconnects.
>> (exec/exec.cpp:274)
>> 
>> I'm wondering because we're currently running a python executor which
>> ends its life like this:
>> 
>>driver.sendStatusUpdate(_create_task_status(TASK_FINISHED))
>>driver.stop()
>># in a different thread:
>>sys.exit(0 if driver.run() == mesos_pb2.DRIVER_STOPPED else 1)
>> 
>> and we're seeing situations (roughly once per 10,000 tasks) where the
>> executor process is reaped before the acknowledgement for TASK_FINISHED
>> is sent from slave to executor. This results in mesos generating a
>> TASK_FAILED status update, probably from
>> Slave::sendExecutorTerminatedStatusUpdate().
>> 
>> So, did I misunderstand how MesosExecutor works? Or is it indeed a race,
>> and we have to change the executor shutdown?
>> 
>> Best regards,
>> Benno
>> 

Re: [C++11] Please use `nullptr`!

[Benjamin Mahler]

Thanks Tomasz!

Does the style checker now catch NULL introductions?

On Mon, Jun 6, 2016 at 2:12 PM, Michael Park  wrote:

> Hello,
>
> Tomasz Janiszewski kindly started the initiative on the migration to
> `nullptr`, and we have closed MESOS-3243
> .
>
> The existing instances of `NULL` have been replaced with `nullptr`, and any
> new or remaining instances of `NULL` are bugs. Please let me know if we
> missed any, or if there are any that happen to sneak through during this
> transition period.
>
> Thanks,
>
> MPark
>

Re: mesos git commit: Added documentation for access_sandboxes and access_mesos_logs acls.

[Adam Bordelon]

Good point. Vinod was working on the endpoints script right next to me, but
I guess he did his pre-release run before I committed Alexander's change.
We'll have to do another run before rc2.

On Mon, Jun 6, 2016 at 5:36 AM, Neil Conway  wrote:

> FYI, this commit should have included the changes produced by
> re-running the `generate-endpoint.py` script.
>
> Neil
>
> On Wed, Jun 1, 2016 at 8:26 AM,   wrote:
> > Repository: mesos
> > Updated Branches:
> >   refs/heads/master 5263a6211 -> 53b5164bb
> >
> >
> > Added documentation for access_sandboxes and access_mesos_logs acls.
> >
> > Modifies the file `acls.proto` to take into consideration the added
> > authorization actions `access_sandboxes` and `access_mesos_logs`.
> >
> > Review: https://reviews.apache.org/r/48048/
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/53b5164b
> > Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/53b5164b
> > Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/53b5164b
> >
> > Branch: refs/heads/master
> > Commit: 53b5164bb51ebe850dec5ab19b8382f5c4a59391
> > Parents: 5263a62
> > Author: Alexander Rojas 
> > Authored: Tue May 31 23:20:50 2016 -0700
> > Committer: Adam B 
> > Committed: Tue May 31 23:24:55 2016 -0700
> >
> > --
> >  docs/authorization.md |  2 ++
> >  src/files/files.cpp   | 34 +++---
> >  2 files changed, 33 insertions(+), 3 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/docs/authorization.md
> > --
> > diff --git a/docs/authorization.md b/docs/authorization.md
> > index 0e58b9b..189b70d 100644
> > --- a/docs/authorization.md
> > +++ b/docs/authorization.md
> > @@ -131,6 +131,8 @@ entries, each representing an authorizable action:
> >  |`view_framework`|UNIX user of whom executors can be
> viewed.|`Framework_Info` which can be viewed.|Filtering http endpoints.|
> >  |`view_executor`|UNIX user of whom executors can be
> viewed.|`Executor_Info` and `Framework_Info` which can be viewed.|Filtering
> http endpoints.|
> >  |`view_task`|UNIX user of whom tasks can be viewed.|(`Task` or
> `Task_Info`) and `Framework_Info` which can be viewed.|Filtering http
> endpoints.|
> > +|`access_sandboxes`|Operator username.|Operating system user whose
> executor/task sandboxes can be accessed.|Access task sandboxes.|
> > +|`access_mesos_logs`|Operator username.|Implicitly given. A user should
> only use types ANY and NONE to allow/deny access to the log.|Access Mesos
> logs.|
> >
> >  ### Examples
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/src/files/files.cpp
> > --
> > diff --git a/src/files/files.cpp b/src/files/files.cpp
> > index 873664d..094a00c 100644
> > --- a/src/files/files.cpp
> > +++ b/src/files/files.cpp
> > @@ -57,6 +57,7 @@
> >  using namespace process;
> >
> >  using process::AUTHENTICATION;
> > +using process::AUTHORIZATION;
> >  using process::DESCRIPTION;
> >  using process::HELP;
> >  using process::TLDR;
> > @@ -295,7 +296,16 @@ const string FilesProcess::BROWSE_HELP = HELP(
> >  "Query parameters:",
> >  "",
> >  ">path=VALUE  The path of directory to
> browse."),
> > -AUTHENTICATION(true));
> > +AUTHENTICATION(true),
> > +AUTHORIZATION(
> > +"Browsing files requires that the request principal is ",
> > +"authorized to do so for the target virtual file path.",
> > +"",
> > +"Authorizers may categorize different virtual paths into",
> > +"different ACLs, e.g. logs in one and task sandboxes in",
> > +"another.",
> > +"",
> > +"See authorization documentation for details."));
> >
> >
> >  Future FilesProcess::authorize(
> > @@ -409,7 +419,16 @@ const string FilesProcess::READ_HELP = HELP(
> >  ">offset=VALUEValue added to base address to
> obtain "
> >  "a second address",
> >  ">length=VALUELength of file to read."),
> > -AUTHENTICATION(true));
> > +AUTHENTICATION(true),
> > +AUTHORIZATION(
> > +"Reading files requires that the request principal is ",
> > +"authorized to do so for the target virtual file path.",
> > +"",
> > +"Authorizers may categorize different virtual paths into",
> > +"different ACLs, e.g. logs in one and task sandboxes in",
> > +"another.",
> > +"",
> > +"See authorization documentation for details."));
> >
> >
> >  Future FilesProcess::read(
> > @@ -585,7 +604,16 @@ const string 

Re: 0.28.2 has been released

[Kapil Arya]

Hi Craig,

I should be sending out a link to the RPM packages in a couple of days.
(Our packaging scripts had some issues and I am working on fixing them).

Kapil

On Mon, Jun 6, 2016 at 6:15 AM, craig w  wrote:

> Jie,
>
> Thanks for the updates. When will the packages be available (in particular
> RPM)?
>
> -craig
>
> On Sun, Jun 5, 2016 at 2:31 PM, Jie Yu  wrote:
>
>> Hi folks,
>>
>> I just released Mesos 0.28.2 and updated the website.
>>
>> It includes some important bug fixes. The change log can be found here:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.2
>>
>> If you are considering using 0.28, please use 0.28.2!
>>
>> Thanks!
>> - Jie
>>
>
>
>
> --
>
> https://github.com/mindscratch
> https://www.google.com/+CraigWickesser
> https://twitter.com/mind_scratch
> https://twitter.com/craig_links
>
>

[C++11] Please use `nullptr`!

[Michael Park]

Hello,

Tomasz Janiszewski kindly started the initiative on the migration to
`nullptr`, and we have closed MESOS-3243
.

The existing instances of `NULL` have been replaced with `nullptr`, and any
new or remaining instances of `NULL` are bugs. Please let me know if we
missed any, or if there are any that happen to sneak through during this
transition period.

Thanks,

MPark

Re: mesos/kafka issues (reviving old thread)

[Vinod Kone]

ZK communication is little different from framework communication. In the
former case, the ZK client library inside master opens up a connection to
the ZK server ensemble. In the latter case, the scheduler driver inside the
framework scheduler opens up a connection to the mesos master. But it is
strange that marathon from a different remote host works fine but
kafka-mesos from a different remote host has issues.

On Mon, Jun 6, 2016 at 3:12 PM, Justin Ryan  wrote:

> inline
>
> On 6/6/16, 8:40 AM, "Vinod Kone"  wrote:
>
> >Have you tried running a different framework than the kafka one (maybe
> marathon? or chronos?) to rule out framework related issues? I'm surprised
> that it works when the scheduler and master are on the same host but not
> when they are different.
> > Looks like the request packets are getting dropped somewhere between the
> master NIC and the application.
> >
>
> Marathon is working just fine, I have flume running via Marathon and kafka
> running via kafka-mesos.
>
> Yah, it does seem like the request packets are getting dropped, but that
> makes no sense – how can the mesos-masters and zookeepers communicate with
> each other, but an arbitrary other process can’t communicate with the
> active mesos-master from another host which is a mesos-master? I’ve done a
> lot of packet inspection and can do more, but overwhelmingly this seems to
> anchor the notion that there is no firewall in play.
>
> 
>
> P Please consider the environment before printing this e-mail
>
> The information in this electronic mail message is the sender's
> confidential business and may be legally privileged. It is intended solely
> for the addressee(s). Access to this internet electronic mail message by
> anyone else is unauthorized. If you are not the intended recipient, any
> disclosure, copying, distribution or any action taken or omitted to be
> taken in reliance on it is prohibited and may be unlawful. The sender
> believes that this E-mail and any attachments were free of any virus, worm,
> Trojan horse, and/or malicious code when sent. This message and its
> attachments could have been infected during transmission. By reading the
> message and opening any attachments, the recipient accepts full
> responsibility for taking protective and remedial action about viruses and
> other defects. The sender's employer is not liable for any loss or damage
> arising in any way.
>

Re: mesos/kafka issues (reviving old thread)

[Justin Ryan]

inline

On 6/6/16, 8:40 AM, "Vinod Kone"  wrote:

>Have you tried running a different framework than the kafka one (maybe 
>marathon? or chronos?) to rule out framework related issues? I'm surprised 
>that it works when the scheduler and master are on the same host but not when 
>they are different.
> Looks like the request packets are getting dropped somewhere between the 
> master NIC and the application.
>

Marathon is working just fine, I have flume running via Marathon and kafka 
running via kafka-mesos.

Yah, it does seem like the request packets are getting dropped, but that makes 
no sense – how can the mesos-masters and zookeepers communicate with each 
other, but an arbitrary other process can’t communicate with the active 
mesos-master from another host which is a mesos-master? I’ve done a lot of 
packet inspection and can do more, but overwhelmingly this seems to anchor the 
notion that there is no firewall in play.



P Please consider the environment before printing this e-mail

The information in this electronic mail message is the sender's confidential 
business and may be legally privileged. It is intended solely for the 
addressee(s). Access to this internet electronic mail message by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. The sender believes that this E-mail and any 
attachments were free of any virus, worm, Trojan horse, and/or malicious code 
when sent. This message and its attachments could have been infected during 
transmission. By reading the message and opening any attachments, the recipient 
accepts full responsibility for taking protective and remedial action about 
viruses and other defects. The sender's employer is not liable for any loss or 
damage arising in any way.

Re: mesos/kafka issues (reviving old thread)

[Justin Ryan]

Hiya Vinit,

I’ve made some progress, I have a conditionally working setup, and another 
setup which was working now failing in new ways.

It does sound like your captures are similar to mine, what I found is that if I 
run the scheduler on, say, zk01 (which is also a mesos-master), while it is the 
leader, things work fine.  If mesos-master fails over to zk02 or zk03, the 
scheduler running on zk01 stops working, though its’ config points at all three 
machines.  Obviously this makes it difficult to run the scheduler itself as a 
mesos task.

Though I wish neither of us were having this problem, it’s good to not feel 
like I’m crazy, I kinda ran out of things to test until one day it occurred to 
me to check if it matters whether the scheduler runs on the active 
mesos-master.  I can think of a couple reasons this would be so, but haven’t 
had time to narrow it down.

Cheers!

Justin

On 6/3/16, 12:52 PM, "Vinit Mahedia"  wrote:

>
>
>​​Hey Justin,
>
>
>I am running in the same issues as you mentioned in this old
> thread 
> ,
>  did you resolve it?
>
>
>I see that kafka framework sends a POST request to register itself but mesos 
>master logs does not even show that the request was received, packet capture 
>does. My guess was that something is
> wrong in HTTP request but doing this same thing on local setup works fine so 
> that can't be the case. I can capture the requests on the master node so 
> there's no network issues either, just like in your case. I also verified 
> that two machines can communicate
> on using netcat as well.
>
>
>
>Like you mentioned in your thread, once it registered with mesos but that was 
>the only time that happened, the brokers did not start even then - "start" 
>timed out.
>
>
>^that behavior hints at possible bug in mesos, where it sits on this request 
>for too long and some times under some conditions, it gets through, that's 
>when it works.
>
>
>PS I have network capture showing POST from framework to master, if anyone 
>wants to take a look at it.
>
>
>--
>Vinit
>
>



P Please consider the environment before printing this e-mail

The information in this electronic mail message is the sender's confidential 
business and may be legally privileged. It is intended solely for the 
addressee(s). Access to this internet electronic mail message by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. The sender believes that this E-mail and any 
attachments were free of any virus, worm, Trojan horse, and/or malicious code 
when sent. This message and its attachments could have been infected during 
transmission. By reading the message and opening any attachments, the recipient 
accepts full responsibility for taking protective and remedial action about 
viruses and other defects. The sender's employer is not liable for any loss or 
damage arising in any way.

Re: 0.28.2 has been released

[craig w]

Jie,

Thanks for the updates. When will the packages be available (in particular
RPM)?

-craig

On Sun, Jun 5, 2016 at 2:31 PM, Jie Yu  wrote:

> Hi folks,
>
> I just released Mesos 0.28.2 and updated the website.
>
> It includes some important bug fixes. The change log can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.28.2
>
> If you are considering using 0.28, please use 0.28.2!
>
> Thanks!
> - Jie
>



-- 

https://github.com/mindscratch
https://www.google.com/+CraigWickesser
https://twitter.com/mind_scratch
https://twitter.com/craig_links

Re: mesos/kafka issues (reviving old thread)

[Justin Ryan]

inline

On 6/3/16, 2:19 PM, "Vinit Mahedia"  wrote:

>Justin,
>Yeah - as long as everything is on a single box (mesos-kafka scheduler, 
>mesos-master, zk etc.)
>things work just fine, which is what I meant by local setup.
>
>
>I did a local cluster setup as well, 3 vagrant machines, where it does
>not work. So it does not work at all
>if you have multi node setup (vagrant machines or bare metal).
>

I do have two working clusters, but the mesos-kafka scheduler must run on the 
active mesos-master leader, which may also be an indication of another symptom 
that just *happens* to coincide with this.

>
>others,
>
>Is there any alternative for getting kafka up and running on mesos  other than 
>this -
>mesos/kafka  ?
>

I thought about this for a while, but digging into the code, this is just an 
extension of MesosFramework, which is core mesos functionality.

We’re either missing something or have exposed a bug.

Of course, a person could just run kafka brokers with marathon, but I think 
this is worth the trouble and is fundamentally how things should be done.




P Please consider the environment before printing this e-mail

The information in this electronic mail message is the sender's confidential 
business and may be legally privileged. It is intended solely for the 
addressee(s). Access to this internet electronic mail message by anyone else is 
unauthorized. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it is 
prohibited and may be unlawful. The sender believes that this E-mail and any 
attachments were free of any virus, worm, Trojan horse, and/or malicious code 
when sent. This message and its attachments could have been infected during 
transmission. By reading the message and opening any attachments, the recipient 
accepts full responsibility for taking protective and remedial action about 
viruses and other defects. The sender's employer is not liable for any loss or 
damage arising in any way.

Re: Proposal: move content in Wiki to docs in code repo

[Vinod Kone]

Works for me. Some things we might miss from wiki would be comments and
ability to watch for updates; but I don't think many people use them.

On Mon, Jun 6, 2016 at 3:15 PM, Gilbert Song  wrote:

> +1.
>
> At least I personally rarely touch the wiki.
>
> Gilbert
>
> On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing  wrote:
>
>> +1
>>
>> It's good idea to collect and gather every thing in one single repo,
>> would be easier for users to find out.
>>
>> Thanks & Best Wishes,
>>
>> Tom Xing(邢舟)
>> Emerging Technology Institute, IBM China Software Development Lab
>> --
>> IBM China Software Development Laboratory (CSDL)
>> Notes ID:Zhou Z Xing/China/IBM
>> Phone :86-10-82450442
>> e-Mail :xingz...@cn.ibm.com
>> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei Wang
>> West Road, Haidian District, Beijing, P.R.China 100193
>> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>>
>>
>> [image: Inactive hide details for Jie Yu ---2016-06-06 上午 11:29:42---Hi
>> folks, I am proposing moving our content in Wiki (e.g., wor]Jie Yu
>> ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our content in
>> Wiki (e.g., working groups, release
>>
>> From: Jie Yu 
>> To: mesos , "u...@mesos.apache.org" <
>> u...@mesos.apache.org>
>> Date: 2016-06-06 上午 11:29
>> Subject: Proposal: move content in Wiki to docs in code repo
>> --
>>
>>
>>
>> Hi folks,
>>
>> I am proposing moving our content in Wiki (e.g., working groups, release
>> tracking, etc.) to our docs in the code repo. I personally found that wiki
>> is hard to use and there's no reviewing process for changes in the Wiki.
>> The content in Wiki historically received less attention than that in the
>> docs.
>>
>> What do you think?
>>
>> - Jie
>>
>>
>>
>>
>

Re: Proposal: move content in Wiki to docs in code repo

[Gilbert Song]

+1.

At least I personally rarely touch the wiki.

Gilbert

On Mon, Jun 6, 2016 at 11:51 AM, Zhou Z Xing  wrote:

> +1
>
> It's good idea to collect and gather every thing in one single repo, would
> be easier for users to find out.
>
> Thanks & Best Wishes,
>
> Tom Xing(邢舟)
> Emerging Technology Institute, IBM China Software Development Lab
> --
> IBM China Software Development Laboratory (CSDL)
> Notes ID:Zhou Z Xing/China/IBM
> Phone :86-10-82450442
> e-Mail :xingz...@cn.ibm.com
> Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei Wang
> West Road, Haidian District, Beijing, P.R.China 100193
> 地址 :中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193
>
>
> [image: Inactive hide details for Jie Yu ---2016-06-06 上午 11:29:42---Hi
> folks, I am proposing moving our content in Wiki (e.g., wor]Jie Yu
> ---2016-06-06 上午 11:29:42---Hi folks, I am proposing moving our content in
> Wiki (e.g., working groups, release
>
> From: Jie Yu 
> To: mesos , "u...@mesos.apache.org" <
> u...@mesos.apache.org>
> Date: 2016-06-06 上午 11:29
> Subject: Proposal: move content in Wiki to docs in code repo
> --
>
>
>
> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
>
> What do you think?
>
> - Jie
>
>
>
>

Re: Proposal: move content in Wiki to docs in code repo

[Zhou Z Xing]

+1

It's good idea to collect and gather every thing in one single repo, would
be easier for users to find out.

Thanks & Best Wishes,

Tom Xing(邢舟)
Emerging Technology Institute, IBM China Software Development Lab
--
IBM China Software Development Laboratory (CSDL)
Notes ID:Zhou Z Xing/China/IBM
Phone   :86-10-82450442
e-Mail  :xingz...@cn.ibm.com
Address :Building No.28, ZhongGuanCun Software Park, No.8 Dong Bei Wang
West Road, Haidian District, Beijing, P.R.China 100193
地址:中国北京市海淀区东北旺西路8号 中关村软件园28号楼 100193




From:   Jie Yu 
To: mesos , "u...@mesos.apache.org"

Date:   2016-06-06 上午 11:29
Subject:Proposal: move content in Wiki to docs in code repo



Hi folks,

I am proposing moving our content in Wiki (e.g., working groups, release
tracking, etc.) to our docs in the code repo. I personally found that wiki
is hard to use and there's no reviewing process for changes in the Wiki.
The content in Wiki historically received less attention than that in the
docs.

What do you think?

- Jie

Re: Proposal: move content in Wiki to docs in code repo

[Tomek Janiszewski]

+1
For a long time I didn't knew that wiki exists. It's hidden from a new
users and search engines - I remember only one place where it's linked in
docs.
I can help with move.

pon., 6.06.2016, 20:29 użytkownik Jie Yu  napisał:

> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
>
> What do you think?
>
> - Jie
>

Re: Proposal: move content in Wiki to docs in code repo

[Avinash Sridharan]

+1

I think moving the wiki into docs would make information about working
groups, release tracking first class citizens and help disseminate
information better.

On Mon, Jun 6, 2016 at 11:29 AM, Jie Yu  wrote:

> Hi folks,
>
> I am proposing moving our content in Wiki (e.g., working groups, release
> tracking, etc.) to our docs in the code repo. I personally found that wiki
> is hard to use and there's no reviewing process for changes in the Wiki.
> The content in Wiki historically received less attention than that in the
> docs.
>
> What do you think?
>
> - Jie
>



-- 
Avinash Sridharan, Mesosphere
+1 (323) 702 5245

Proposal: move content in Wiki to docs in code repo

[Jie Yu]

Hi folks,

I am proposing moving our content in Wiki (e.g., working groups, release
tracking, etc.) to our docs in the code repo. I personally found that wiki
is hard to use and there's no reviewing process for changes in the Wiki.
The content in Wiki historically received less attention than that in the
docs.

What do you think?

- Jie

Re: Mesos installation in cloud network fails when zookeeper elects a master with internal ip

[haosdent]

>Here I am facing another issue in mesos master installation. I am passing
> internal ip address to /etc/mesos-master/hostname and ip files in each
> master node.
>
> my hostname and ip file looks like:
> 10.40.0.128

Hi, @Pankaj You could not use same hostname and ip in each master node.
Instead,
you should use the corresponding ip and hostname of your master machine.
And make
sure those ip could be accessed in your env.

On Wed, May 25, 2016 at 1:22 AM, Pankaj Saha  wrote:

> got it thanks.
>
> Here I am facing another issue in mesos master installation. I am passing
>  internal ip address to /etc/mesos-master/hostname and ip files in each
> master node.
> I can not start mesos-master with web UI at any of the nodes in
> the presence of hostname and ip file in /etc/mesos-master directory.
>
> my hostname and ip file looks like:
>
> > 10.40.0.128
>
>
> my /etc/zookeeper/zoo.cfg configuration looks like:
>
>
> > server.1=10.40.0.128:2888:3888
> > server.2=10.40.0.129:2888:3888
> > server.3=10.40.0.130:2888:3888
>
>
> my /etc/mesos/zk file looks like :
>
> > zk://10.40.0.128:2181,10.40.0.129:2181,10.40.0.130:2181/mesos
>
>
> But if I remove hostname and ip file from /etc/mesos-master directory, I am
> able to open web UI for each mesos-master but none of them are connected.
> Each portals say "No master is currently leading ..."
>
> Please help.
>
> Thanks
> Pankaj
>
>
> On Mon, May 23, 2016 at 4:28 PM, Arslan Abbasi 
> wrote:
>
> > The /etc/hosts file should be edited on the machine where you are
> accessing
> > the GUI for Mesos. All the Master Nodes should have no idea about the
> > floating IPs
> >
> >
> >
> > On Mon, May 23, 2016 at 1:21 PM, Pankaj Saha 
> > wrote:
> >
> > > Thanks Arslan,
> > > Okay, so you mean to change the /etc/host file changes to all master
> > nodes
> > > and provide the assigned floating ip to them. I will try and will let
> you
> > > know.
> > >
> > > my understanding was, zookeeper picks the ip address of the
> mesos-master
> > > host from /etc/mesos-master/hostname file.
> > >
> > > On Mon, May 23, 2016 at 4:07 PM, Arslan Abbasi <
> > arslan.abbas...@gmail.com>
> > > wrote:
> > >
> > > > I believe when a new master is elected, the new url contains the Host
> > > Name
> > > > of the newly Elected leader. From the Mesos setup point of view, all
> > the
> > > > configuration will be done using the *internal IP addresses* but when
> > you
> > > > try to access the Mesos GUI from the outside, you will access it over
> > the
> > > > Floating IP/s.
> > > >
> > > > To resolve the IP address of newly elected leader, you can edit your
> > > > /etc/hosts file, on the machine where you are accessing the Mesos
> GUI,
> > to
> > > > contain the hostname to IP mapping for the Mesos Nodes. Note that
> this
> > > > would be the floating IP address of the newly elected leader.
> > > >
> > > > Hope this helps
> > > >
> > > > On Mon, May 23, 2016 at 11:18 AM, Pankaj Saha  >
> > > > wrote:
> > > >
> > > > > hello devs,
> > > > >
> > > > > I have a situation where I am given 6 nodes to configure mesos
> > > cluster(3
> > > > > masters 3 slaves) in a chameleon cloud setup. Each of the node has
> a
> > > > > floating public ip and an internal ip.
> > > > >
> > > > > My setup consists of libraries from mesosphere package. In
> zookeeper
> > > > > configuration I have mentioned three internal ip addresses of
> > > > mesos-master
> > > > > as zookeepee server in "zoo.cfg" file, and in mesos-master
> > > configuration
> > > > I
> > > > > have mentioned masters internal ip in etc/mesos-master/ "hostname"
> > and
> > > > "ip"
> > > > > file.
> > > > >
> > > > > Now after starting all services I can see mesos portal in one of
> the
> > > > > mesos-masters-public-ip:5050, But it fails immediately when
> zookeeper
> > > > > changes its next leader and fetches internal ip address of the next
> > > > > mesos-master leader.
> > > > >
> > > > > in zookeeper and mesos master configuration I can not put floating
> > > public
> > > > > ip address as those are not known to zookeeper server and mesos
> > nodes.
> > > > >
> > > > > Please guide me how can I make the setup working. do I need to make
> > > > changes
> > > > > to network configuration or anything else so that zookeeper can
> > elect a
> > > > > master with public ip.
> > > > >
> > > > >
> > > > > Thanks
> > > > > Pankaj
> > > > >
> > > >
> > >
> >
>



-- 
Best Regards,
Haosdent Huang

Re: Mesos HA does not work (Failed to recover registrar)

[haosdent]

Hi, @Qian Zhang Your issue reminds me of this
http://search-hadoop.com/m/0Vlr69BZgz1NlAPP1=Re+Mesos+Masters+Leader+Keeps+Fluctuating
which I could not reproduce in my env. I am not sure whether your case are
same with Stefano or not.

On Mon, Jun 6, 2016 at 9:06 PM, Qian Zhang  wrote:

> I deleted everything in the work dir (/var/lib/mesos/master), and tried
> again, the same error still happened :-(
>
>
> Thanks,
> Qian Zhang
>
> On Mon, Jun 6, 2016 at 3:03 AM, Jean Christophe “JC” Martin <
> jch.mar...@gmail.com> wrote:
>
>> Qian,
>>
>> Zookeeper should be able to reach a quorum with 2, no need to start 3
>> simultaneously, but there is an issue with Zookeeper related to connection
>> timeouts.
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2164
>> In some circumstances, the timeout is higher than the sync timeout, which
>> cause the leader election to fail.
>> Try setting the parameter cnxtimeout in zookeeper (by default it’s
>> 5000ms) to the value 500 (500ms). After doing this, leader election in ZK
>> will be super fast even if a node is disconnected.
>>
>> JC
>>
>> > On Jun 4, 2016, at 4:34 PM, Qian Zhang  wrote:
>> >
>> > Thanks Vinod and Dick.
>> >
>> > I think my 3 ZK servers have formed a quorum, each of them has the
>> > following config:
>> >$ cat conf/zoo.cfg
>> >server.1=192.168.122.132:2888:3888
>> >server.2=192.168.122.225:2888:3888
>> >server.3=192.168.122.171:2888:3888
>> >autopurge.purgeInterval=6
>> >autopurge.snapRetainCount=5
>> >initLimit=10
>> >syncLimit=5
>> >maxClientCnxns=0
>> >clientPort=2181
>> >tickTime=2000
>> >quorumListenOnAllIPs=true
>> >dataDir=/home/stack/packages/zookeeper-3.4.8/snapshot
>> >dataLogDir=/home/stack/packages/zookeeper-3.4.8/transactions
>> >
>> > And when I run "bin/zkServer.sh status" on each of them, I can see
>> "Mode:
>> > leader" for one, and "Mode: follower" for the other two.
>> >
>> > I have already tried to manually start 3 masters simultaneously, and
>> here
>> > is what I see in their log:
>> > In 192.168.122.171(this is the first master I started):
>> >I0605 07:12:49.418721  1187 detector.cpp:152] Detected a new leader:
>> > (id='25')
>> >I0605 07:12:49.419276  1186 group.cpp:698] Trying to get
>> > '/mesos/log_replicas/24' in ZooKeeper
>> >I0605 07:12:49.420013  1188 group.cpp:698] Trying to get
>> > '/mesos/json.info_25' in ZooKeeper
>> >I0605 07:12:49.423807  1188 zookeeper.cpp:259] A new leading master
>> > (UPID=master@192.168.122.171:5050) is detected
>> >I0605 07:12:49.423841 1186 network.hpp:461] ZooKeeper group PIDs: {
>> > log-replica(1)@192.168.122.171:5050 }
>> >I0605 07:12:49.424281 1187 master.cpp:1951] The newly elected leader
>> > is master@192.168.122.171:5050 with id
>> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
>> >I0605 07:12:49.424895  1187 master.cpp:1964] Elected as the leading
>> > master!
>> >
>> > In 192.168.122.225 (second master I started):
>> >I0605 07:12:51.918702  2246 detector.cpp:152] Detected a new leader:
>> > (id='25')
>> >I0605 07:12:51.919983  2246 group.cpp:698] Trying to get
>> > '/mesos/json.info_25' in ZooKeeper
>> >I0605 07:12:51.921910  2249 network.hpp:461] ZooKeeper group PIDs: {
>> > log-replica(1)@192.168.122.171:5050 }
>> >I0605 07:12:51.925721 2252 replica.cpp:673] Replica in EMPTY status
>> > received a broadcasted recover request from (6)@192.168.122.225:5050
>> >I0605 07:12:51.927891  2246 zookeeper.cpp:259] A new leading master
>> > (UPID=master@192.168.122.171:5050) is detected
>> >I0605 07:12:51.928444 2246 master.cpp:1951] The newly elected leader
>> > is master@192.168.122.171:5050 with id
>> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
>> >
>> > In 192.168.122.132 (last master I started):
>> > I0605 07:12:53.553949 16426 detector.cpp:152] Detected a new leader:
>> > (id='25')
>> > I0605 07:12:53.555179 16429 group.cpp:698] Trying to get
>> > '/mesos/json.info_25' in ZooKeeper
>> > I0605 07:12:53.560045 16428 zookeeper.cpp:259] A new leading master
>> (UPID=
>> > master@192.168.122.171:5050) is detected
>> >
>> > So right after I started these 3 masters, the first one
>> (192.168.122.171)
>> > was successfully elected as leader, but after 60s, 192.168.122.171
>> failed
>> > with the error mentioned in my first mail, and then 192.168.122.225 was
>> > elected as leader, but it failed with the same error too after another
>> 60s,
>> > and the same thing happened to the last one (192.168.122.132). So after
>> > about 180s, all my 3 master were down.
>> >
>> > I tried both:
>> >sudo ./bin/mesos-master.sh --zk=zk://127.0.0.1:2181/mesos --quorum=2
>> > --work_dir=/var/lib/mesos/master
>> > and
>> >sudo ./bin/mesos-master.sh --zk=zk://192.168.122.132:2181,
>> > 192.168.122.171:2181,192.168.122.225:2181/mesos --quorum=2
>> > --work_dir=/var/lib/mesos/master
>> > And I see the same error for both.
>> >
>> > 

Re: [MesosCon][Slides] Any slides sharing plan for MesosCon

[Guangya Liu]

Great! Thanks Artem :D

On Monday, June 6, 2016, Artem Harutyunyan  wrote:

> Hi Guangya,
>
> You should see the slides if you go to individual talk pages, like this one
> [0]
> <
> http://mesosconna2016.sched.org/event/6jtl/containers-in-apache-mesos-present-and-future-jie-yu-tim-chen-mesosphere?iframe=yes=i:0;=yes=no
> >.
> Some of the speakers have uploaded their slides to Sched.
>
> Artem.
>
> [0] -
>
> http://mesosconna2016.sched.org/event/6jtl/containers-in-apache-mesos-present-and-future-jie-yu-tim-chen-mesosphere?iframe=yes=i:0;=yes=no
>
> On Fri, Jun 3, 2016 at 8:42 PM, Guangya Liu  > wrote:
>
> > Unlike last year's MesosCon, I saw that the slides was not shared till
> now
> > in http://events.linuxfoundation.org/events/mesoscon-north-america , any
> > plan to share those slides?
> >
> > Thanks,
> >
> > Guangya
> >
>

Re: mesos/kafka issues (reviving old thread)

[Vinod Kone]

Have you tried running a different framework than the kafka one (maybe
marathon? or chronos?) to rule out framework related issues? I'm surprised
that it works when the scheduler and master are on the same host but not
when they are different. Looks like the request packets are getting dropped
somewhere between the master NIC and the application.

On Fri, Jun 3, 2016 at 6:59 PM, Vinit Mahedia 
wrote:

> Justin,
>
> There's certainly a bug somewhere, either in mesos kafka framework or mesos
> itself. If I can get this
> mesos master running under debugger, this would be over in maybe few hours
> or few days.
>
> Kafka is a stateful service so can't run on marathon directly, there has to
> be some framework/wrapper
> which manages brokers - Read here
> <
> https://mesosphere.com/blog/2015/07/16/making-apache-kafka-elastic-with-apache-mesos/
> >
> .
>
> On Fri, Jun 3, 2016 at 4:36 PM, Justin Ryan  wrote:
>
> > inline
> >
> > On 6/3/16, 2:19 PM, "Vinit Mahedia"  wrote:
> >
> > >Justin,
> > >Yeah - as long as everything is on a single box (mesos-kafka scheduler,
> > mesos-master, zk etc.)
> > >things work just fine, which is what I meant by local setup.
> > >
> > >
> > >I did a local cluster setup as well, 3 vagrant machines, where it does
> > >not work. So it does not work at all
> > >if you have multi node setup (vagrant machines or bare metal).
> > >
> >
> > I do have two working clusters, but the mesos-kafka scheduler must run on
> > the active mesos-master leader, which may also be an indication of
> another
> > symptom that just *happens* to coincide with this.
> >
> > >
> > >others,
> > >
> > >Is there any alternative for getting kafka up and running on mesos
> other
> > than this -
> > >mesos/kafka  ?
> > >
> >
> > I thought about this for a while, but digging into the code, this is just
> > an extension of MesosFramework, which is core mesos functionality.
> >
> > We’re either missing something or have exposed a bug.
> >
> > Of course, a person could just run kafka brokers with marathon, but I
> > think this is worth the trouble and is fundamentally how things should be
> > done.
> >
> >
> > 
> >
> > P Please consider the environment before printing this e-mail
> >
> > The information in this electronic mail message is the sender's
> > confidential business and may be legally privileged. It is intended
> solely
> > for the addressee(s). Access to this internet electronic mail message by
> > anyone else is unauthorized. If you are not the intended recipient, any
> > disclosure, copying, distribution or any action taken or omitted to be
> > taken in reliance on it is prohibited and may be unlawful. The sender
> > believes that this E-mail and any attachments were free of any virus,
> worm,
> > Trojan horse, and/or malicious code when sent. This message and its
> > attachments could have been infected during transmission. By reading the
> > message and opening any attachments, the recipient accepts full
> > responsibility for taking protective and remedial action about viruses
> and
> > other defects. The sender's employer is not liable for any loss or damage
> > arising in any way.
> >
>
>
>
> --
> ~Vinit
>

Re: [MesosCon][Slides] Any slides sharing plan for MesosCon

[Artem Harutyunyan]

Hi Guangya,

You should see the slides if you go to individual talk pages, like this one
[0]
.
Some of the speakers have uploaded their slides to Sched.

Artem.

[0] -
http://mesosconna2016.sched.org/event/6jtl/containers-in-apache-mesos-present-and-future-jie-yu-tim-chen-mesosphere?iframe=yes=i:0;=yes=no

On Fri, Jun 3, 2016 at 8:42 PM, Guangya Liu  wrote:

> Unlike last year's MesosCon, I saw that the slides was not shared till now
> in http://events.linuxfoundation.org/events/mesoscon-north-america , any
> plan to share those slides?
>
> Thanks,
>
> Guangya
>

Re: Mesos HA does not work (Failed to recover registrar)

[Qian Zhang]

I deleted everything in the work dir (/var/lib/mesos/master), and tried
again, the same error still happened :-(


Thanks,
Qian Zhang

On Mon, Jun 6, 2016 at 3:03 AM, Jean Christophe “JC” Martin <
jch.mar...@gmail.com> wrote:

> Qian,
>
> Zookeeper should be able to reach a quorum with 2, no need to start 3
> simultaneously, but there is an issue with Zookeeper related to connection
> timeouts.
> https://issues.apache.org/jira/browse/ZOOKEEPER-2164
> In some circumstances, the timeout is higher than the sync timeout, which
> cause the leader election to fail.
> Try setting the parameter cnxtimeout in zookeeper (by default it’s 5000ms)
> to the value 500 (500ms). After doing this, leader election in ZK will be
> super fast even if a node is disconnected.
>
> JC
>
> > On Jun 4, 2016, at 4:34 PM, Qian Zhang  wrote:
> >
> > Thanks Vinod and Dick.
> >
> > I think my 3 ZK servers have formed a quorum, each of them has the
> > following config:
> >$ cat conf/zoo.cfg
> >server.1=192.168.122.132:2888:3888
> >server.2=192.168.122.225:2888:3888
> >server.3=192.168.122.171:2888:3888
> >autopurge.purgeInterval=6
> >autopurge.snapRetainCount=5
> >initLimit=10
> >syncLimit=5
> >maxClientCnxns=0
> >clientPort=2181
> >tickTime=2000
> >quorumListenOnAllIPs=true
> >dataDir=/home/stack/packages/zookeeper-3.4.8/snapshot
> >dataLogDir=/home/stack/packages/zookeeper-3.4.8/transactions
> >
> > And when I run "bin/zkServer.sh status" on each of them, I can see "Mode:
> > leader" for one, and "Mode: follower" for the other two.
> >
> > I have already tried to manually start 3 masters simultaneously, and here
> > is what I see in their log:
> > In 192.168.122.171(this is the first master I started):
> >I0605 07:12:49.418721  1187 detector.cpp:152] Detected a new leader:
> > (id='25')
> >I0605 07:12:49.419276  1186 group.cpp:698] Trying to get
> > '/mesos/log_replicas/24' in ZooKeeper
> >I0605 07:12:49.420013  1188 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> >I0605 07:12:49.423807  1188 zookeeper.cpp:259] A new leading master
> > (UPID=master@192.168.122.171:5050) is detected
> >I0605 07:12:49.423841 1186 network.hpp:461] ZooKeeper group PIDs: {
> > log-replica(1)@192.168.122.171:5050 }
> >I0605 07:12:49.424281 1187 master.cpp:1951] The newly elected leader
> > is master@192.168.122.171:5050 with id
> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
> >I0605 07:12:49.424895  1187 master.cpp:1964] Elected as the leading
> > master!
> >
> > In 192.168.122.225 (second master I started):
> >I0605 07:12:51.918702  2246 detector.cpp:152] Detected a new leader:
> > (id='25')
> >I0605 07:12:51.919983  2246 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> >I0605 07:12:51.921910  2249 network.hpp:461] ZooKeeper group PIDs: {
> > log-replica(1)@192.168.122.171:5050 }
> >I0605 07:12:51.925721 2252 replica.cpp:673] Replica in EMPTY status
> > received a broadcasted recover request from (6)@192.168.122.225:5050
> >I0605 07:12:51.927891  2246 zookeeper.cpp:259] A new leading master
> > (UPID=master@192.168.122.171:5050) is detected
> >I0605 07:12:51.928444 2246 master.cpp:1951] The newly elected leader
> > is master@192.168.122.171:5050 with id
> cdc459d4-a05f-4f99-9bf4-1ee9a91d139b
> >
> > In 192.168.122.132 (last master I started):
> > I0605 07:12:53.553949 16426 detector.cpp:152] Detected a new leader:
> > (id='25')
> > I0605 07:12:53.555179 16429 group.cpp:698] Trying to get
> > '/mesos/json.info_25' in ZooKeeper
> > I0605 07:12:53.560045 16428 zookeeper.cpp:259] A new leading master
> (UPID=
> > master@192.168.122.171:5050) is detected
> >
> > So right after I started these 3 masters, the first one (192.168.122.171)
> > was successfully elected as leader, but after 60s, 192.168.122.171 failed
> > with the error mentioned in my first mail, and then 192.168.122.225 was
> > elected as leader, but it failed with the same error too after another
> 60s,
> > and the same thing happened to the last one (192.168.122.132). So after
> > about 180s, all my 3 master were down.
> >
> > I tried both:
> >sudo ./bin/mesos-master.sh --zk=zk://127.0.0.1:2181/mesos --quorum=2
> > --work_dir=/var/lib/mesos/master
> > and
> >sudo ./bin/mesos-master.sh --zk=zk://192.168.122.132:2181,
> > 192.168.122.171:2181,192.168.122.225:2181/mesos --quorum=2
> > --work_dir=/var/lib/mesos/master
> > And I see the same error for both.
> >
> > 192.168.122.132, 192.168.122.225 and 192.168.122.171 are 3 VMs which are
> > running on a KVM hypervisor host.
> >
> >
> >
> >
> > Thanks,
> > Qian Zhang
> >
> > On Sun, Jun 5, 2016 at 3:47 AM, Dick Davies 
> wrote:
> >
> >> You told the master it needed a quorum of 2 and it's the only one
> >> online, so it's bombing out.
> >> That's the expected behaviour.
> >>
> >> You need to start at least 2 zookeepers before it 

Re: mesos git commit: Added documentation for access_sandboxes and access_mesos_logs acls.

[Neil Conway]

FYI, this commit should have included the changes produced by
re-running the `generate-endpoint.py` script.

Neil

On Wed, Jun 1, 2016 at 8:26 AM,   wrote:
> Repository: mesos
> Updated Branches:
>   refs/heads/master 5263a6211 -> 53b5164bb
>
>
> Added documentation for access_sandboxes and access_mesos_logs acls.
>
> Modifies the file `acls.proto` to take into consideration the added
> authorization actions `access_sandboxes` and `access_mesos_logs`.
>
> Review: https://reviews.apache.org/r/48048/
>
>
> Project: http://git-wip-us.apache.org/repos/asf/mesos/repo
> Commit: http://git-wip-us.apache.org/repos/asf/mesos/commit/53b5164b
> Tree: http://git-wip-us.apache.org/repos/asf/mesos/tree/53b5164b
> Diff: http://git-wip-us.apache.org/repos/asf/mesos/diff/53b5164b
>
> Branch: refs/heads/master
> Commit: 53b5164bb51ebe850dec5ab19b8382f5c4a59391
> Parents: 5263a62
> Author: Alexander Rojas 
> Authored: Tue May 31 23:20:50 2016 -0700
> Committer: Adam B 
> Committed: Tue May 31 23:24:55 2016 -0700
>
> --
>  docs/authorization.md |  2 ++
>  src/files/files.cpp   | 34 +++---
>  2 files changed, 33 insertions(+), 3 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/docs/authorization.md
> --
> diff --git a/docs/authorization.md b/docs/authorization.md
> index 0e58b9b..189b70d 100644
> --- a/docs/authorization.md
> +++ b/docs/authorization.md
> @@ -131,6 +131,8 @@ entries, each representing an authorizable action:
>  |`view_framework`|UNIX user of whom executors can be 
> viewed.|`Framework_Info` which can be viewed.|Filtering http endpoints.|
>  |`view_executor`|UNIX user of whom executors can be viewed.|`Executor_Info` 
> and `Framework_Info` which can be viewed.|Filtering http endpoints.|
>  |`view_task`|UNIX user of whom tasks can be viewed.|(`Task` or `Task_Info`) 
> and `Framework_Info` which can be viewed.|Filtering http endpoints.|
> +|`access_sandboxes`|Operator username.|Operating system user whose 
> executor/task sandboxes can be accessed.|Access task sandboxes.|
> +|`access_mesos_logs`|Operator username.|Implicitly given. A user should only 
> use types ANY and NONE to allow/deny access to the log.|Access Mesos logs.|
>
>  ### Examples
>
>
> http://git-wip-us.apache.org/repos/asf/mesos/blob/53b5164b/src/files/files.cpp
> --
> diff --git a/src/files/files.cpp b/src/files/files.cpp
> index 873664d..094a00c 100644
> --- a/src/files/files.cpp
> +++ b/src/files/files.cpp
> @@ -57,6 +57,7 @@
>  using namespace process;
>
>  using process::AUTHENTICATION;
> +using process::AUTHORIZATION;
>  using process::DESCRIPTION;
>  using process::HELP;
>  using process::TLDR;
> @@ -295,7 +296,16 @@ const string FilesProcess::BROWSE_HELP = HELP(
>  "Query parameters:",
>  "",
>  ">path=VALUE  The path of directory to browse."),
> -AUTHENTICATION(true));
> +AUTHENTICATION(true),
> +AUTHORIZATION(
> +"Browsing files requires that the request principal is ",
> +"authorized to do so for the target virtual file path.",
> +"",
> +"Authorizers may categorize different virtual paths into",
> +"different ACLs, e.g. logs in one and task sandboxes in",
> +"another.",
> +"",
> +"See authorization documentation for details."));
>
>
>  Future FilesProcess::authorize(
> @@ -409,7 +419,16 @@ const string FilesProcess::READ_HELP = HELP(
>  ">offset=VALUEValue added to base address to obtain "
>  "a second address",
>  ">length=VALUELength of file to read."),
> -AUTHENTICATION(true));
> +AUTHENTICATION(true),
> +AUTHORIZATION(
> +"Reading files requires that the request principal is ",
> +"authorized to do so for the target virtual file path.",
> +"",
> +"Authorizers may categorize different virtual paths into",
> +"different ACLs, e.g. logs in one and task sandboxes in",
> +"another.",
> +"",
> +"See authorization documentation for details."));
>
>
>  Future FilesProcess::read(
> @@ -585,7 +604,16 @@ const string FilesProcess::DOWNLOAD_HELP = HELP(
>  "Query parameters:",
>  "",
>  ">path=VALUE  The path of directory to browse."),
> -AUTHENTICATION(true));
> +AUTHENTICATION(true),
> +AUTHORIZATION(
> +"Downloading files requires that the request principal is ",
> +"authorized to do so for the target virtual file path.",
> +"",
> +"Authorizers may categorize different virtual paths into",
> +"different ACLs, e.g. 

Re: Mesos Coverity Scan

[Jörg Schad]

There is an issue from the coverity scan preventing us to build/check Mesos
correctly (see answer from coverity team below).
I will keep you posted on the progress here.


"This is a known issue which required a fix by devs in the upcoming 8.1
release. This should be integrated into SCAN over the next few weeks.

Thanks, M."

On Sun, Jun 5, 2016 at 10:20 PM, Benjamin Mahler  wrote:

> +jörg
>
> On Fri, May 20, 2016 at 1:40 PM, Benjamin Mahler 
> wrote:
>
> > Any update on getting the coverity scan up and running?
> >
> > It used to send us new defects as commits land, and that helped us catch
> a
> > number of bugs, so it would be great to see it revived!
> >
> > On Thu, Mar 31, 2016 at 12:36 AM, Jörg Schad 
> wrote:
> >
> > > Hi,
> > > just a short update on why our Mesos Coverity Scan (
> > > https://scan.coverity.com/projects/mesos) is failing at the moment.
> > > I will keep you updated once the issue is fixed.
> > >
> > > Jörg
> > >
> > >
> > > -- Forwarded message --
> > > From: Mel Llaguno
> > > Date: Wed, Mar 30, 2016 at 10:50 PM
> > > Subject: Mesos project failures in SCAN
> > > To: "jo...@mesosphere.io" 
> > >
> > >
> > > Joerg,
> > >
> > > We discovered a bug in our path handling logic that has prevented Mesos
> > > from having its defects stored. This fix will be available in the
> > upcoming
> > > 8.1 release of our tools for SCAN. I¹ll keep you in the loop.
> > >
> > > Thanks, M.
> > >
> >
>

Re: WebUI authentication in 1.0.0-rc1

[Evers Benno]

Hi,

thanks for the pointer. For people having the same problem, it seems
that you have to actually provide six new ACL rules to restore the
previous behaviour:

get_endpoints, view_frameworks, view_tasks, view_executors,
access_sandboxes, and access_mesos_logs.

On 03.06.2016 21:59, Michael Park wrote:
> Hello, I'm not exactly sure about whether the behavior is undesired or not.
> 
> But I think the ACL that you're missing is `GetEndpoint`:
> https://github.com/apache/mesos/blob/master/include/mesos/authorizer/acls.proto#L183-L190
> 
> Hope that helps,
> 
> MPark
> 
> On 3 June 2016 at 12:36, Evers Benno  wrote:
> 
>>
>> I just tried building and running the 1.0.0-rc1, and it seems that the
>> web UI is broken due to /metrics/snapshot returning a 403. (There's a
>> popup continously displaying "Failed to connect to
>> mesos-master.example.org:5050!"
>>
>> I'm running mesos-master with options `--no-authenticate_http
>> --acls={"permissive": "false", [...]}`, so I'm not completely sure if
>> this behaviour is as desired or not. (although its certainly unexpected)
>>
>> Regardless, I looked around for a while, but I couldn't figure out what
>> to add to the ACL to restore unauthorized viewing access for everyone?
>>
>> Best regards,
>> Benno
>>
> 

Rack awareness support for Mesos

[Du, Fan]

Hi, Mesos folks

I've been thinking about Mesos rack awareness support for a while,
it's a common interest for lots of data center applications to provide data 
locality,
fault tolerance and better task placement. Create MESOS-5545 to track the story,
and here is the initial design doc [1] to support rack awareness in Mesos.

Looking forward to hear any comments from end user and other developers,
Thanks!

[1]: 
https://docs.google.com/document/d/1rql_LZSwtQzBPALnk0qCLsmxcT3-zB7X7aJp-H3xxyE/edit?usp=sharing