Filesystem isolator test fail

On my build setup (using vagrant ubuntu), I am seeing filesystem isolator test fail with error message: E1107 05:24:47.878077 336 slave.cpp:3449] Container '9e31b321-bbc7-4914-b8d6-8a14aeb31985' for executor '162fa75a-18c5-4424-b0ff-6064279ac1e4' of framework

Re: Filesystem isolator test fail

I think it maybe caused by your slave flag is incorrect. On Sat, Nov 7, 2015 at 1:45 PM, Jie Yu wrote: > Can you create a ticket with full verbose logging. Which test are you > running? Which version are you using? > > Thanks, > - Jie > > On Fri, Nov 6, 2015 at 9:27 PM,

Re: Filesystem isolator test fail

Can you create a ticket with full verbose logging. Which test are you running? Which version are you using? Thanks, - Jie On Fri, Nov 6, 2015 at 9:27 PM, Vaibhav Khanduja wrote: > On my build setup (using vagrant ubuntu), I am seeing filesystem isolator > test fail

Better error reporting in Mesos

Error reporting in Mesos is based on Stout’s Error class and a variety of other classes, such as ErrnoError and WindowsError, that derive from Error. One goal of these classes is to simplify the construction and storage of error message strings. As an example, the ErrnoError constructor

Mesos is helping OpenStack Container Deployment

Just FYI, the OpenStack Kolla Team [1] is forming a small team trying to investigate if Mesos could be used as an orchestration engine in place of Ansible [2], Mesos plus Marathon might be the solution. [1] https://github.com/openstack/kolla [2] http://markmail.org/thread/vg6xkavfpp6c4odr

Re: Finish Oversubscription before 0.26.0?

Cool! So we now have a major feature to announce with this release. Thanks for all the good work on this! Bernd > On Nov 5, 2015, at 8:11 PM, Niklas Nielsen wrote: > > Nope - go ahead and close > > On Thu, Nov 5, 2015 at 10:24 AM, Jie Yu

Re: Mesos Style Guideline Adjustments

I think jaggedness in the example you provide comes mainly from the fact that the second comment has multiple logical blocks. I have formatted both comments at 70 and at 80, here is the outcome: http://pastebin.com/nRQB0nCD While the first comment indeed looks better when wrapped at 70, I can't

Re: Backticks in comments

+1 Make it so. On Wed, Nov 4, 2015 at 7:31 AM, haosdent wrote: > +1 Backticks used in markdown widely. > > On Wed, Nov 4, 2015 at 11:03 PM, Bernd Mathiske > wrote: > > > +1 > > > > > On Nov 2, 2015, at 8:34 PM, Isabel Jimenez < > >

Re: [jira] [Comment Edited] (MESOS-2079) IO.Write test is flaky on OS X 10.10.

I have multiple questions here 1. Why do we use pipes at all? or is SIGPIPE raised also when writing into sockets? which leads me to: 2. Do we use it only in test cases or is there something actively using pipes? SIGPIPE itself is a weird signal, since a failed call to `write` returns -1 and

Re: Finish Oversubscription before 0.26.0?

> we've resolved 134 issues And committed 325 patches: $ git log --oneline 0.25.0..HEAD |wc -l 325 On Fri, Nov 6, 2015 at 10:38 AM, Marco Massenzio wrote: > I guess that when you're used to trash the opponents scoring 5 goals per > game, just winning by 2 or 3 goals may

Re: Better error reporting in Mesos

On a related note (and in full agreement with Michael and Alex) I have always felt not terribly at ease with our current practice of *not* logging at the point of error - relying instead on returning an Error() object instead. I have now witnessed a large number of instances, when debugging

Re: Better error reporting in Mesos

Hi Marco, On Fri, Nov 6, 2015 at 10:57 AM, Marco Massenzio wrote: > So, in addition to what Michael suggests, and in line with Alex's > exhortation to have "excellent core error reporting facilities," I would > also like to propose that we consider adopting a pattern I've

Re: Mesos Style Guideline Adjustments

As far as setting a soft limit goes, I think there are several different style guides and it basically boils down to personal preferences as well. The Linux `fmt` command wraps by 75 columns by default; others use 72 or as extreme as 60 columns. Having said that, it's nice to have tools that

Re: Mesos Style Guideline Adjustments

I raise this because there is a ton of value in keeping our codebase as readable as possible. Having had to navigate and maintain the code base for the past few years, this _is_ a "real issue" that deserves the contributors spending their mental resources on. I realize this seems very subtle, but

Re: Mesos Style Guideline Adjustments

@ben Is "jaggedness" the only *formatting* influence on the readability of the comments? If so, would it be possible to make a simple github.io page where we can paste comments, and they get formatted for minimal jaggedness based on some simple math? This would help provide consistency between

Re: Mesos Style Guideline Adjustments

+benh I seem to recall benh having something in emacs that formatted his comments nicely, which I think formed the basis for thinking about jaggedness and wrapping at 70 vs 80. On Fri, Nov 6, 2015 at 11:26 AM, Joris Van Remoortere wrote: > @ben Is "jaggedness" the only

Re: Finish Oversubscription before 0.26.0?

Scratch that. We already announced this with Mesos 0.23. Only the epic never got closed. And we merely improved the feature since 0.23. So, no exciting new features in 0.26.0 AFAIK. > On Nov 6, 2015, at 11:16 AM, Bernd Mathiske wrote: > > Cool! So we now have a major

Re: Backticks in comments

Thanks for the input y'all, sounds like we have a general consensus for backticks in comments to enclose code excerpts and object names. I'll submit a patch to change the style guide and make it official. Cheers, Greg On Fri, Nov 6, 2015 at 4:46 AM, Alexander Rojas

Re: Mesos Style Guideline Adjustments

Hi, just to echo Alexander’s point, for newbies like me being able to delegate formatting decisions to tools as much as possible frees up a lot of mental resources for tackling the real issues. Cheers, Benjamin ps. Also looking forward to an updated and expanded clang-format config. > On

Re: [jira] [Updated] (MESOS-3645) Implement stout/os/windows/stat.hpp

Hi Alex, When you want to bulk edit issues (for example unset target version), there is an option in JIRA to "bulk edit and not send an email notification". I would recommend to use that option (in the future) to reduce the noise on the mailing list. Thanks, On Thu, Nov 5, 2015 at 10:16 PM,

Re: Mesos is helping OpenStack Container Deployment

Great! On Fri, Nov 6, 2015 at 9:00 AM, tommy xiao wrote: > +1 > > 2015-11-06 17:59 GMT+08:00 Guangya Liu : > > > Just FYI, the OpenStack Kolla Team [1] is forming a small team trying to > > investigate if Mesos could be used as an orchestration engine in

Re: [jira] [Updated] (MESOS-3645) Implement stout/os/windows/stat.hpp

Ah. I actually had no idea. Thanks! On Fri, Nov 6, 2015 at 9:12 AM, Vinod Kone wrote: > Hi Alex, > > When you want to bulk edit issues (for example unset target version), there > is an option in JIRA to "bulk edit and not send an email notification". I > would recommend to

Re: Finish Oversubscription before 0.26.0?

I guess that when you're used to trash the opponents scoring 5 goals per game, just winning by 2 or 3 goals may feel like you have underachieved :) A very rough 2-minute JQL query , however, reveals that we've resolved 134 issues

Re: [jira] [Comment Edited] (MESOS-2079) IO.Write test is flaky on OS X 10.10.

To answer your questions: We use pipes when we need to communicate across the process boundary after a fork. Look for Subprocess::IO::Pipe for examples. There is plenty of code using pipes. Sockets aren't an issue as one can avoid SIGPIPE across OS X (SO_NOSIGPIPE) and Linux (MSG_NOSIGNAL). I'm

Re: Better error reporting in Mesos

On Fri, Nov 6, 2015 at 11:24 AM, Neil Conway wrote: > Hi Marco, > > On Fri, Nov 6, 2015 at 10:57 AM, Marco Massenzio > wrote: > > So, in addition to what Michael suggests, and in line with Alex's > > exhortation to have "excellent core error reporting

Re: Backticks in comments

+1 for backticks! > On 02 Nov 2015, at 19:32, Greg Mann wrote: > > Hey folks! > I wanted to bring up a style issue that I noticed recently. In some > comments in the codebase, backticks are used to quote code excerpts and > object names, while in other comments, single

Re: Better error reporting in Mesos

I also like the idea of having better error reports. On that side, I always liked the design of boost system_error where one has categories of errors with a set of error codes (integer) where each of them have a specific string associated and which can be complemented with extra text. > On 06

Re: Mesos Style Guideline Adjustments

I think one of the main reasons we move to having 80 as the limit for both code and comments is the ability it gives us to use tools (e.g. clang-format) to enforce formatting rules, so personally I rather have us putting effort towards that goal. On that note, the developer branch of

Re: Better error reporting in Mesos

On Fri, Nov 6, 2015 at 12:44 PM, Marco Massenzio wrote: > I may be wrong here, but adding (filename, line_nr) to the Error() object > is performance-impact and may need to be disabled in Production > environments I don't think that will be the case: passing __FILE__ and

Re: Better error reporting in Mesos

Thanks for the proposal Michael. This has come up in discussions before and I think it's really valuable, so it's nice to see folks thinking about this. Some things to consider: Don't forget 'Failure' which is unfortunately not unified with 'Error'. How does this affect error message composition

Re: Better error reporting in Mesos

On Fri, Nov 6, 2015 at 12:54 PM, Neil Conway wrote: > On Fri, Nov 6, 2015 at 12:44 PM, Marco Massenzio > wrote: > > I may be wrong here, but adding (filename, line_nr) to the Error() object > > is performance-impact and may need to be disabled in

Re: Better error reporting in Mesos

I think having recently been through the libprocess “continuations” and callbacks, we do lack a pattern that logs errors that have full context. For example, we don’t have a pattern of logging at “onFailed’/“onDiscarded” sites at each layer of the call stack. What this leads to is a top level

Re: MESOS-3545: Investigate restoring tasks/executors after machine reboot.

Any reason that this doesn't mention the executor failing during the steady state? I assume that the desire here is more generally to restart executors according to a policy, without having the round-trip back to the scheduler which may not be successful in many circumstances. Also, any reason

Re: Better error reporting in Mesos

In general, I think a good answer to my question is for the place that is reporting or unboxing the error to aggregate data into an error struct that holds things like the "error stack" (and other semantics about the log, including perhaps error codes), and then let whoever is logging, reporting