Re: creating a mesos cluster with many nodes without public ips

>Now the problem is I have many other machines in my lab, which does not >have public ip addresses. How can I connect them to the Mesos master? Hi, @Pankaj Currently Mesos agent(slave) must have a public ip which could access by Mesos master. On Thu, Jul 14, 2016 at 4:52 AM, Pankaj Saha wrote:

[GitHub] mesos pull request #140: Added Lijun Tang as contributor

GitHub user hercule24 opened a pull request: https://github.com/apache/mesos/pull/140 Added Lijun Tang as contributor You can merge this pull request into a Git repository by running: $ git pull https://github.com/hercule24/mesos add_as_new_contributor_branch Alternatively yo

Re: Metrics for custom modules

Hi Joseph, That sounds great! Let me test this out. Any gotcha that I should be careful of? (internal locking, performance, conflict, etc etc). Thanks. On Wed, Jul 13, 2016 at 5:46 PM, Joseph Wu wrote: > As long as you're using libprocess to write your modules, you can add your > metrics via

Re: Metrics for custom modules

As long as you're using libprocess to write your modules, you can add your metrics via `process::metrics::add(...)`. Those will be exposed via the same old `/metrics/snapshot` endpoint. On Wed, Jul 13, 2016 at 5:39 PM, Zhitao Li wrote: > Hi, > > I'm not sure whether this has been mentioned, but

Metrics for custom modules

Hi, I'm not sure whether this has been mentioned, but is it possible to reuse Mesos's metric system for custom modules? For context, we are planning to turn on some agent-side modules at many machines, but we face the question of how we'll monitor their behavior: we can reinvent some wheels to ex

creating a mesos cluster with many nodes without public ips

Hello Devs, I have a running Mesos master node with a public IP on a KVM based Virtual machine on the Cloud, to which I can connect other agents across the network. I have one machine in my lab which I have public ip and I can connect it to the Mesos master. I have used below commands to start mast

Fwd: Notification: Community Meeting @ Thu Jul 14, 2016 10pm - 11pm (Apache Mesos)

-- Forwarded message -- From: Google Calendar Date: 13 July 2016 at 21:59 Subject: Notification: Community Meeting @ Thu Jul 14, 2016 10pm - 11pm (Apache Mesos) To: Michael Park more details »

Re: Validate lamba function in `Flags::add` for required parameters

Thanks for bringing this up, Klaus - in this case, I think that extra argument appears simply to match the desired function overload. Over time, the overloads for `FlagsBase::add` have multiplied considerably; It looks like we have about 20 now :-) I think it would be really nice to clean these up

Validate lamba function in `Flags::add` for required parameters

Hi team, When I updating the patch for MESOS-5123, I found the validate lamba function for in `Flags::add` for required parameters is different with optional parameters. Does any know why? The coding style is inconsistent, it took times to fin

Re: [Replicated Log] Enable Mesos to use etcd for replicated_log

Great summary, thx! On Mon, Jul 11, 2016 at 5:44 PM, Jay JN Guo wrote: > > Shuai, > > I think you are right. AFAIK, replicated_log interacts with zk in only > following two ways: > > 1) replicated_log creates znode and maintain 'membership' via > zookeeper::Group. It actually stores pid under zk

Re: Registering and framework failover

Ah, right -- yes, at the moment you need to look at error strings to decide whether to retry with a new framework ID, unfortunately. IMO we should introduce error codes or enums to make this process more reliable, but no one has done so yet: https://issues.apache.org/jira/browse/MESOS-4548 https:/

Re: Registering and framework failover

Let me try to clarify: The problem is that I don't get to decide manually if the framwork should try to take a new id or re-use the old one, but it needs to be decided programmatically, by an algorithm. Afaik it's not possible to get the time when the framework disconnected from mesos, so it's no

Re: Registering and framework failover

On Wed, Jul 13, 2016 at 2:44 PM, Evers Benno wrote: > imagine the following situation: I am a framework with failover timeout > of 1 hour, and 59 minutes and 55 seconds after shutting down I want to > register with the master again. > > If my registration attempt arrives at the master within the t

Registering and framework failover

Hi all, imagine the following situation: I am a framework with failover timeout of 1 hour, and 59 minutes and 55 seconds after shutting down I want to register with the master again. If my registration attempt arrives at the master within the time limit everything will be fine and I even get back

Re: Disabling the --registry_strict flag in 1.0

Hi Jie, On Wed, Jul 13, 2016 at 12:11 AM, Jie Yu wrote: > Does this mean that we'll have to cut another 1.0 RC just for that? I'd think so. > If we were to cut another RC (e.g., due to bugs, which is likely), I would > be happy to include the patch that disables the flag in the new RC. But if >

Re: getting added to contributors

Hi Artem, Sounds good -- one or the other seems fine, but requiring both seems a bit onerous. Neil On Tue, Jul 12, 2016 at 9:14 PM, Artem Harutyunyan wrote: > Hi Neil, > > It's either that or an email (which is what the 'traditional' way is). The > reason for requiring this step is that ASF man