Re: Configure error when try to build mesos from source on ubuntu

[Marco Massenzio]

As a follow up,  for those who may not need Java or Python support in their
build, you can use --disable-java and --disable-python flags; this is how I
usually run it:

mkdir build && cd build
../configure --prefix /my/path/to/local --disable-java --disable-python
make -j 10 V=0

(I use the --prefix so that the generated libraries during the make install
step won't "pollute" my system's /usr/local/bin).

You'll miss the build of the Java/Python protobuf, and probably other
stuff, but it's usually good enough to experiment with C++ frameworks,
features, etc.

YMMV


-- 
*Marco Massenzio*
http://codetrips.com

On Sat, Aug 6, 2016 at 9:54 AM, Yu Wei <yu20...@hotmail.com> wrote:

> Yes, you're right. My java_home is not correct.
>
> Now the problem is fixed.
>
>
> Thanks very much.
>
>
> Jared, (韦煜）
> Software developer
> Interested in open source software, big data, Linux
>
> 
> From: haosdent <haosd...@gmail.com>
> Sent: Sunday, August 7, 2016 12:39:09 AM
> To: dev
> Subject: Re: Configure error when try to build mesos from source on ubuntu
>
> Hi, @Yu Yei Mesos requires JDK not only JRE. Please follow
> https://github.com/apache/mesos/blob/master/docs/
> getting-started.md#ubuntu-1404
> to getting start
>
> ```
> # Install the latest OpenJDK.
> $ sudo apt-get install -y openjdk-7-jdk
> ```
>
> On Sun, Aug 7, 2016 at 12:30 AM, Yu Wei <yu20...@hotmail.com> wrote:
>
> > Hi guys,
> >
> >
> > I tried to build mesos 1.0.0 from source on Ubuntu.
> >
> > I met following problem when tried to configure.
> >
> > checking for curl_global_init in -lcurl... yes
> > configure: error: failed to determine linker flags for using Java (bad
> > JAVA_HOME or missing support for your architecture?)
> >
> >
> > My JAVA_HOME is actually set to  "/usr/lib/jvm/java-8-oracle/jre".
> >
> >
> > Any hints about this issue?
> >
> >
> > Thx,
> >
> >
> > Jared, (??)
> > Software developer
> > Interested in open source software, big data, Linux
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Anonymous modules

[Marco Massenzio]

Thanks, Kapil!

-- 
*Marco Massenzio*
http://codetrips.com

On Tue, Aug 9, 2016 at 2:10 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> It hasn't been removed, but was moved around a bit:
> https://github.com/apache/mesos/blob/master/src/master/main.cpp#L334
>
>
>
> On Tue, Aug 9, 2016 at 5:07 PM, Marco Massenzio <m.massen...@gmail.com>
> wrote:
>
>> Hi folks,
>>
>> I've recently updated my repo to the 1.0.0 release and noticed that the
>> code in main.cpp that used to run the anonymous modules is now gone.
>>
>> Before I embark on a wild goose chase to find it, could someone please let
>> me know if they are still supported?
>> (if they aren't I have clearly missed the memo - sorry about that!)
>>
>> Thanks in advance for any help.
>> --
>> *Marco Massenzio*
>> http://codetrips.com
>>
>
>

Anonymous modules

[Marco Massenzio]

Hi folks,

I've recently updated my repo to the 1.0.0 release and noticed that the
code in main.cpp that used to run the anonymous modules is now gone.

Before I embark on a wild goose chase to find it, could someone please let
me know if they are still supported?
(if they aren't I have clearly missed the memo - sorry about that!)

Thanks in advance for any help.
-- 
*Marco Massenzio*
http://codetrips.com

Re: MESOS-2516: Shepherd wanted

[Marco Massenzio]

On Sat, May 14, 2016 at 12:22 PM, José Guilherme Vanz <
guilherme@gmail.com> wrote:

> I'm very new in the community and I do not know all the issues the
> community already faced. My advance apologies if I'm saying bullshit...
>
> If is always difficult to find I shepherd, change the approach can be a
> good ideia. Maybe remove this burocracy of a shepherd and keep just the
> review board and reviews.


​You would just remove the issue by one step, adding the frustration that
you have now invested the time in fixing the issue, but no one really cares
enough to give a review.
​


> Once a new patch is uploaded the
> commiters/reviewers should review and give their feedback. All the history
> will be in the Jira and review board.
>

​What you are saying is entirely correct and not b**t; but the issue is not
about "finding a shepherd," but rather around broadening community
participation and transparency around priorities.

Neither, paradoxically, seems to be a priority here - especially when 90%+
of committers now belong to the same commercial organization.
​
​AFAIK most of the organizations who use Mesos in Production now have their
own private forks, maintaining their own set of patches, which we can't get
committed upstream, for varied and, mostly, opaque reasons.  Needless to
say, it's a huge hassle​ and makes people wonder whether we'd be better off
with a different scheduler...


> On Fri, 13 May 2016 at 14:45 Cong Wang  wrote:
>
> > On Thu, May 12, 2016 at 8:54 PM, José Guilherme Vanz
> >  wrote:
> > > Even I did not find a shepherd, I've uploaded a first version of the
> > patch
> > > in the review board.
> >
> > You are not alone. This is the biggest problem of this community which
> > people here refuse to see, especially when we are not in Mesospshere. ;)
> >
>

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

[Marco Massenzio]

Hi,

sorry, I have not kept up with all the new endpoints :)
If there is already an endpoint (/redirect ?) that essentially addresses
the issue raised by MESOS-3841
 (https://issues.apache.org/jira/browse/MESOS-3841) then I'd suggest to
close it and add a note.

(I just saw it and thought it would have been useful, and fun to fix).

-- 
*Marco Massenzio*
http://codetrips.com

On Sat, Apr 30, 2016 at 9:24 PM, haosdent <haosd...@gmail.com> wrote:

> Oh, @Marco. Thank you very much for your reply, vinodkone shepherd this
> and it have already submitted after other kindly guys reviews.
>
> For MESOS-3841, it should be resolved now because could get the leading
> master by "/redirect" endpoint. Do you have any concerns about it? I would
> like to solve your concerns.
>
> On Sun, May 1, 2016 at 12:12 PM, Marco Massenzio <m.massen...@gmail.com>
> wrote:
>
>> @haosdent - thanks for doing this, very useful indeed!
>>
>> On a related issue [0], I'd like to that one on:
>>
>> - can anyone comment if that's a good idea/bad idea; and
>> - would anyone be willing to shepherd it?
>>
>> Thanks!
>>
>> [0] Master HTTP API support to get the leader (
>> https://issues.apache.org/jira/browse/MESOS-3841)
>>
>> --
>> *Marco Massenzio*
>> http://codetrips.com
>>
>> On Tue, Apr 19, 2016 at 12:34 AM, haosdent <haosd...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> We intend to introduce a breaking change[1] in the http endpoints
>>> without the deprecation cycle.
>>> For below http endpoints, when user request to a master which is not a
>>> leader,
>>> user would get a 307 redirect(TEMPORARY_REDIRECT) to the leader master.
>>>
>>> * /create-volumes
>>> * /destroy-volumes
>>> * /frameworks
>>> * /reserve
>>> * /slaves
>>> * /quota
>>> * /weights
>>> * /state
>>> * /state.json
>>> * /state-summary
>>> * /tasks
>>> * /tasks.json
>>> * /roles
>>> * /roles.json
>>> * /teardown
>>> * /maintenance/schedule
>>> * /maintenance/status
>>> * /machine/down
>>> * /machine/up
>>> * /unreserve
>>>
>>> For other endpoints in master, the behaviour is not change.
>>>
>>> If your existing framework/tool relied on the old behaviour, I suggest
>>> to add a logic to handle 307 redirect response.
>>> Please let me know if you have any queries/concerns. Any comments will
>>> be appreciated.
>>>
>>> Links:
>>> [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
>>>
>>> --
>>> Best Regards,
>>> Haosdent Huang
>>>
>>
>>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader

[Marco Massenzio]

@haosdent - thanks for doing this, very useful indeed!

On a related issue [0], I'd like to that one on:

- can anyone comment if that's a good idea/bad idea; and
- would anyone be willing to shepherd it?

Thanks!

[0] Master HTTP API support to get the leader (
https://issues.apache.org/jira/browse/MESOS-3841)

-- 
*Marco Massenzio*
http://codetrips.com

On Tue, Apr 19, 2016 at 12:34 AM, haosdent <haosd...@gmail.com> wrote:

> Hi All,
>
> We intend to introduce a breaking change[1] in the http endpoints without
> the deprecation cycle.
> For below http endpoints, when user request to a master which is not a
> leader,
> user would get a 307 redirect(TEMPORARY_REDIRECT) to the leader master.
>
> * /create-volumes
> * /destroy-volumes
> * /frameworks
> * /reserve
> * /slaves
> * /quota
> * /weights
> * /state
> * /state.json
> * /state-summary
> * /tasks
> * /tasks.json
> * /roles
> * /roles.json
> * /teardown
> * /maintenance/schedule
> * /maintenance/status
> * /machine/down
> * /machine/up
> * /unreserve
>
> For other endpoints in master, the behaviour is not change.
>
> If your existing framework/tool relied on the old behaviour, I suggest to
> add a logic to handle 307 redirect response.
> Please let me know if you have any queries/concerns. Any comments will be
> appreciated.
>
> Links:
> [1]  Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1865
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Reorganize 3rdparty directory

[Marco Massenzio]

>
> Overall, the changes are extremely small. We (apparently) did a pretty
> good job of making the CMake configuration scripts modular and
> consumable by arbitrary projects


ah, the warm, fuzzy feeling that one experiences when all the hard work of
abstracting stuff pays off :-)
well done, Alex!

A quick question for you (as you recall, I have great stakes in - but
minimal understanding of - cmake) - which targets should be expected to
work for Cmake?
I had to add a few (minor) fixes to make CLion fully understand Mesos (it
still has a few "bogus" errors, but it's by and large, greatly usable - and
beats Eclipse CDT any day).

Also, please let me know whether there's anything you'd like me to try out
and report back.

Thanks!

-- 
*Marco Massenzio*
http://codetrips.com

On Fri, Feb 26, 2016 at 11:44 AM, Alex Clemmer <clemmer.alexan...@gmail.com>
wrote:

> Ah, I see now that I coudl have done better by splitting the patch
> into two patches -- one where we move everything, and one where we
> change the cmake files.
>
> THe important parts of the patch are:
>
> * Adding the contents of `3rdparty/libprocess/3rdparty/CMakeLists.txt`
> -> `3rdparty/CMakeLists.txt`; makes since, because we're merging the
> two 3rdparty folders, so we only need one CMakeLists.txt. We just dump
> the contents unchanged into the other one.
> * `3rdparty/libprocess/cmake/Process3rdpartyConfigure.cmake` changing some
> paths
> * `3rdparty/libprocess/CMakeLists.txt` moving a call to `include`.
>
> And that's about it. Everything else is just moving.
>
> On Fri, Feb 26, 2016 at 11:36 AM, Alex Clemmer
> <clemmer.alexan...@gmail.com> wrote:
> > Folks:
> >
> > Took about 30 minutes to put together a prototype of the great
> > `3rdparty` flattening. Please see the (extremely preliminary)
> > review[1] or my working branch[2] for a really close approximation of
> > the number of changes to the CMake build system we'd need to support
> > this flattening.
> >
> > Overall, the changes are extremely small. We (apparently) did a pretty
> > good job of making the CMake configuration scripts modular and
> > consumable by arbitrary projects, so the changes are mostly things
> > like "move the config `include` call over there instead of being over
> > there" and "change a handful of path variables to reflect the new dir
> > structure". (I hope, btw, that it doesn't seem arrogant to say this,
> > but I think it is justified given the relatively minor changes in the
> > actual CMake code.)
> >
> > Feel free to remix/take/throw away any subset of this. I don't need
> > any credit for it in the final patch if someone marches off in that
> > direction. :)
> >
> > [1] https://reviews.apache.org/r/44099/
> > [2] https://github.com/hausdorff/mesos/commits/prototype_flattened_3rd
> >
> > On Thu, Feb 18, 2016 at 12:22 PM, Kevin Klues <klue...@gmail.com> wrote:
> >> I am also a fan of git submodules in the long term, but avoiding them
> >> in the short term.  We should get things organized as we want them
> >> first, and then start thinking about pulling libprocess/stout out into
> >> submodules later (while also preserving their history!)
> >>
> >> I disagree with moving libprocess and stout up to the same level as
> >> src/. If we want to make sure they don't bleed into Mesos proper, we
> >> really should treat them the same as any other 3rdparty code that we
> >> depend on.  This will become more relevant when/if we move them into
> >> submodules.
> >>
> >> Given all that, the only real challenge with flattening our 3rdparty
> >> dependencies into a single folder should be the changes we have to
> >> make to our configure.ac and Makefile.am scripts to know where to look
> >> for their dependencies now.  In the end these should be URLs to
> >> versioned tarballs that we host somewhere (or git repos that we can
> >> have forked and tagged with specific versions).  In the short term
> >> these can just be relative paths in the mesos tree though.
> >>
> >> On Tue, Feb 16, 2016 at 1:26 PM, Kapil Arya <ka...@mesosphere.io>
> wrote:
> >>> Thanks for bringing it up Alexander!
> >>>
> >>> I don't have a strong opinion wrt git submodules since I don't have
> >>> much experience with them personally. Having said that, I would like
> >>> to go conservative on this one (baby steps :-) ).
> >>>
> >>> Further, I do understand that moving libprocess and stout directories
> >>> will be painful for people who already have several

Re: Inconsistent naming of support scripts

[Marco Massenzio]

+10 for consistency
+1 for hyphens (less carpal-tunnel :)

-- 
*Marco Massenzio*
http://codetrips.com

On Thu, Feb 11, 2016 at 2:58 PM, Michael Park <mp...@apache.org> wrote:

> +1 for consistency, +1 for hyphens for executables.
>
> On 11 February 2016 at 14:25, Kevin Klues <klue...@gmail.com> wrote:
>
> > I typically think of files having dashes as binaries or scripts that
> > are runnable, whereas files with underscores are meant as source or
> > otherwise supplementary to the binary produced (e.g. a supplementary
> > python library that the main python program imports).  I'm  not sure
> > where I inherited this convention from, but it's always been the way
> > I've done things.
> >
> > As far as our code base goes, we seem to use this convention as well
> > with our mesos-master.sh. mesos-slave.sh, etc. binaries.
> >
> > On Thu, Feb 11, 2016 at 2:17 PM, Vinod Kone <vinodk...@apache.org>
> wrote:
> > > Why hyphens? Most of the files in our repo use underscores. I would
> like
> > us
> > > to be consistent on how we name files in the repo.
> > >
> > > On Thu, Feb 11, 2016 at 1:40 PM, Kevin Klues <klue...@gmail.com>
> wrote:
> > >
> > >> I prefer hyphens as well
> > >>
> > >> On Thu, Feb 11, 2016 at 1:28 PM, Jojy Varghese <j...@mesosphere.io>
> > wrote:
> > >> > hyphen++. Is google friendly apparently.  Also less keys to press :)
> > >> >
> > >> > -Jojy
> > >> >
> > >> >
> > >> >
> > >> >> On Feb 11, 2016, at 12:43 PM, Greg Mann <g...@mesosphere.io>
> wrote:
> > >> >>
> > >> >> +1
> > >> >>
> > >> >> On Thu, Feb 11, 2016 at 11:41 AM, Vinod Kone <vinodk...@apache.org
> >
> > >> wrote:
> > >> >>
> > >> >>> Some the scripts in the "support" directory have dashes ("-") in
> > their
> > >> >>> names (e.g., apply-review.sh, apply-reviews.py), whereas some have
> > >> >>> underscores ("_") (e.g., docker_build.sh, mesos_split.py).
> > >> >>>
> > >> >>> This is really confusing and we should stick with one style. I
> > propose
> > >> to
> > >> >>> change all them to use underscores. I will make sure the CI jobs
> are
> > >> >>> updated accordingly.
> > >> >>>
> > >> >>> Any objections?
> > >> >>>
> > >> >>> Thanks,
> > >> >>> Vinod
> > >> >>>
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> ~Kevin
> > >>
> >
> >
> >
> > --
> > ~Kevin
> >
>

Re: Reorganize 3rdparty directory

[Marco Massenzio]

This is a great initiative and something I wanted to do since the first day
I did `git clone` for Mesos :)
Happy to help wherever I can, Kapil - just say the word!

In my opinion, we should take full advantage of git submodules and move
stout/libprocess out into their own repositories (which, incidentally,
already exist [0, 1]) and move all the binaries (*.tar.gz) out of our repo:
I never quite understood why we're carrying along zookeeper and protobuf
(just to mention two), which I'm sure both Apache and Google can take good
care of (and we just install as part of the build process - or whatever).

I've recently been using git submodules and they're pretty awesome, also
allowing other teams who may want to use either library the opportunity to
do so (and contribute back - without having to be part of Mesos proper).

So, totally +1 to this idea.

[0] https://github.com/3rdparty/stout
[1] https://github.com/3rdparty/libprocess

-- 
*Marco Massenzio*
http://codetrips.com

On Tue, Feb 9, 2016 at 4:14 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> Hi All,
>
> TLDR: Move everything from 3rdparty/libprocess/3rdparty/* into 3rdparty/.
> (Optionally) Move libprocess/stout to the top-level directory.
>
> I wanted to start some discussion around reorganizing stuff inside
> "3rdparty". I apologize for the length of the email, please bear with me.
>
> Traditionally, 3rdparty has been used to hold all Mesos dependencies
> (zookeeper, libprocess, protobuf, stout, etc.). Further,
> libprocess/3rdparty was to hold all libprocess dependencies (which may in
> turn be Mesos dependencies as well).
>
> As I understand, the original motivation was to emphasize that libprocess
> is an independent project which depends on "stout", which in turn is also
> an independent project.
>
> However, in the current code base, we don't strictly follow the 3rdparty
> structure. For example, stout has a dependency on picojson and
> google-protobuf, but we don't put these two packages inside
> 3rdparty/libprocess/3rdparty/stout/3rdparty/.
>
> In light of these anomalies, I want to propose that we flatten out the
> 3rdparty directory and put all packages (libprocess, stout, protobuf,
> picojson, zookeeper, etc.) at the same level in 3rdparty. We can still use
> "--with-XYZ=..." to the full extent as needed.
>
> To take it a step further, I want to propose that we bring libprocess and
> stout out of 3rdparty/ and move them at the top level (i.e., make them
> peers of src/). That way, all code in 3rdparty/ is stuff from "third"
> parties and is used only when "--with-bundled" is defined (by default).
> This hierarchy will still allow us to keep libprocess and stout as separate
> independent projects.
>
> The motivation for this proposal came when dealing with 3rdparty
> dependencies for module development. A module developer needs access to
> protobuf, picojson, glog, etc., and for that matter, the exact versions of
> these packages that Mesos was compiled with.
>
> We want to solve this problem by installing module-specific 3rdparty
> dependencies into "${pkglibdir}/3rdparty" as part of "make install" (if
> configured with something like "--enable-install-module-dependencies").
> (There is a discussion going on in a separate thread).
>
> Further, as of today, when we install Mesos using "make install", we
> install stout headers in "${prefix}/include/stout". However, stout has
> dependencies on picojson[1] and google-protobuf headers which may not be
> present on the machine. This leaves stout, and in turn libprocess and Mesos
> headers, fairly broken. I understand that this issue is somewhat orthogonal
> to the main issue being discussed in this mail, but I wanted to put it out
> since it's related.
>
> Any thoughts, comments, concerns are most welcome!
>
> Best,
> Kapil
>
>
> [1]: Picojson issue was resolved as part of
> https://reviews.apache.org/r/41424/ which installs picojson.h into the
> include-dir.
>

Re: build error

[Marco Massenzio]

Worth noting that this is only true if you want to install in the "default"
install location (/usr/local) - you can change that using --prefix during
the configure phase (before running `make`):

cd build
../configure --prefix /home/bob/dev/local (... other flags)
make && make install

This will create (if necessary) that directory and place all .so files in
$PREFIX/lib (most notably, our hero libmesos.so :) and all header files in
$PREFIX/include.

Personally, that's my preferred option, as I don't risk messing up my
system, and also allows me to have multiple versions of the libraries, if I
so wish.

-- 
*Marco Massenzio*
http://codetrips.com

On Sun, Feb 7, 2016 at 10:39 PM, haosdent <haosd...@gmail.com> wrote:

> "make install" have to use sudo.
>
> On Mon, Feb 8, 2016 at 1:43 PM, Abhishek Dasgupta <
> a10gu...@linux.vnet.ibm.com> wrote:
>
> > Hi,
> > Did you run make install with sudo ?? It appears that error is
> "Permission
> > denied" error. Must have been resolved if you run make install with sudo.
> >
> >
> > On Monday 08 February 2016 10:57 AM, Disha Singh wrote:
> >
> >> A few lines in the end of make check command were :
> >>
> >> -*--
> >>
> >> [--] 22 tests from ContentType/SchedulerTest (17276 ms total)
> >>
> >> [--] Global test environment tear-down
> >> [==] 920 tests from 117 test cases ran. (652156 ms total)
> >> [  PASSED  ] 920 tests.
> >>
> >>YOU HAVE 9 DISABLED TESTS
> >>
> >> make[3]: Leaving directory `/home/disha/Desktop/mesos/build/src'
> >> make[2]: Leaving directory `/home/disha/Desktop/mesos/build/src'
> >> make[1]: Leaving directory `/home/disha/Desktop/mesos/build/src'
> >>
> >> *---
> >>
> >> After i run make install I get :
> >>
> >> --
> >>
> >> Making install in .
> >> make[1]: Entering directory `/home/disha/Desktop/mesos/build'
> >> make[2]: Entering directory `/home/disha/Desktop/mesos/build'
> >> make[2]: Nothing to be done for `install-exec-am'.
> >>   /bin/mkdir -p '/usr/local/lib/pkgconfig'
> >> /bin/mkdir: cannot create directory ‘/usr/local/lib/pkgconfig’:
> Permission
> >> denied
> >> make[2]: *** [install-pkgconfigDATA] Error 1
> >> make[2]: Leaving directory `/home/disha/Desktop/mesos/build'
> >> make[1]: *** [install-am] Error 2
> >> make[1]: Leaving directory `/home/disha/Desktop/mesos/build'
> >> make: *** [install-recursive] Error 1
> >>
> >> --
> >>
> >> Sorry, for delay in reply.
> >> Thanks for helping . :)
> >>
> >> On Sat, Feb 6, 2016 at 7:27 PM, Klaus Ma <klaus1982...@gmail.com>
> wrote:
> >>
> >> What error did you get?
> >>>
> >>> 
> >>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> >>> Platform OpenSource Technology, STG, IBM GCG
> >>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >>>
> >>> On Sat, Feb 6, 2016 at 6:18 PM, Disha Singh <directionsta...@gmail.com
> >
> >>> wrote:
> >>>
> >>> It worked fine ,but then some test cases failed even when I didn't
> touch
> >>>> any files, I am just trying to build mesos the way it is. Is it
> >>>> something
> >>>> that is supposed to happen? I guess no. :(
> >>>>
> >>>> On Fri, Jan 29, 2016 at 5:53 AM, Klaus Ma <klaus1982...@gmail.com>
> >>>>
> >>> wrote:
> >>>
> >>>> If no requirement on java/python, you can disable them as Vinod said
> >>>>> (`../configure --disable-java`); it'll also reduce build time :).
> >>>>>
> >>>>> 
> >>>>> Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> >>>>> Platform OpenSource Technology, STG, IBM GCG
> >>>>> +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >>>>>
> >>>>> On Fri, Jan 29, 2016 at 4:18 AM, Vinod Kone <vinodk...@apache.org>
> >>>>>
> >>>> wrote:
> >>>>
> >>>>> On Thu, Jan 28, 2016 at 11:55 AM, Disha Singh <
> >>>>>>
> >>>>> directionsta...@gmail.com
> >>>>
> >>>>> wrote:
> >>>>>>
> >>>>>> I am also unable to upgrade maven2 to maven3.
> >>>>>>>
> >>>>>>> Have you tried asking on the maven user list? You would probably
> get
> >>>>>>
> >>>>> better
> >>>>>
> >>>>>> help regarding maven upgrade there.
> >>>>>>
> >>>>>> If you are not interested in maven/java bindings, you can try
> >>>>>>
> >>>>> building
> >>>
> >>>> mesos with --disable-java configure option.
> >>>>>>
> >>>>>>
> > --
> >   Regards,
> >
> >
> >
> ---
> >   Abhishek Dasgupta
> >   Linux Software Developer - Linux Technology Centre
> >   IBM Systems Lab,
> >   IBM India Pvt. Ltd.
> >   Embassy Golf Link, D Block
> >   Koramongala - Off Indiranagar Ring Road
> >   Bangalore - 560 071
> >   Mobile: +91-8884107981
> >
> >
> ---
> >
> >
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Anonymous Modules "runtime context"

[Marco Massenzio]

Hello, folks.

Now that 0.27 is out of the way, I'm wondering whether I could ping (again)
about this Issue[1] and the associated code review[2] - also, in the spirit
of recent emails, comments from "more experienced contributors" would be
much appreciated too.

Thanks!

-- 
*Marco Massenzio*
http://codetrips.com

On Mon, Jan 4, 2016 at 12:19 PM, Marco Massenzio <m.massen...@gmail.com>
wrote:

> Happy New Year, everyone!
>
> During the break, I've been playing with a toy anon module[0] mostly for
> "learning" purposes.
>
> In doing so, I realized it would be useful, as a developer, to get access
> to even a "minimal" runtime context and filed MESOS-4253[1].
> (there was also a TODO from benh in the respective main.cpp of both
> master/slave).
>
> I've submitted a review chain[2], which can be seen as a "proof of
> concept," and would really be grateful if:
>
> - someone volunteered to be a shepherd for MESOS-4253
>   (in particular, I'd like to discuss the approach, and especially whether
> just passing the Flags is sufficient, or there is something else that may
> be of interest);
>
> - someone could cast a quick critical glance on r/41760 and provide
> feedback;
>
> - finally (no pun intended), I'd like to have conversation around whether
> we should also introduce a `finalize()` method too (again, there is a TODO
> about this as well).
> (I think we should, but can be convinced otherwise)
>
> Thanks in advance!
>
> [0] https://github.com/massenz/execute-module
> [1] https://issues.apache.org/jira/browse/MESOS-4253
> [2] https://reviews.apache.org/r/41760/
> --
> *Marco Massenzio*
> http://codetrips.com
>

Re: .gitignore-template

[Marco Massenzio]

On Fri, Jan 29, 2016 at 12:21 AM, Alexander Rojas <alexan...@mesosphere.io>
wrote:

> It certainly is not unwittingly unless you are one of those who do `git
> yolo` and we should really discourage such dangerous way of writing patches.


​The "unwittingly" was referred to modifying a file that is *actually*
under source control, without actually wanting to do so.

.gitignore is not under source control - it is, in fact, "gitignored" (I
think it's the first line?) and, yet, "editing" it (note the quotes) causes
one's changes to appear in the patch.


Once you do git status you will notice there is something wrong with the
> template.
>
> ​yup -
I think the current term for such a situation is a "WAT" :)
​


> That being said, +1 to add this to the documentation. These caveats should
> be mentioned for newcomers.
>

​Fully agree, thanks.
​


>
> > On 28 Jan 2016, at 17:06, Marco Massenzio <m.massen...@gmail.com> wrote:
> >
> > On Thu, Jan 28, 2016 at 3:18 AM, Michael Park <mp...@apache.org> wrote:
> >
> >> This has been done here:
> >>
> https://github.com/apache/mesos/commit/16c62e5965f304ba59f26f4dbe0bcdfaded7c5ae
> >>
> >
> > ​Unless I'm missing something fundamental here, this means that anyone
> who
> > decides to add some pattern to the /.gitignore file (assuming they
> > don't realize it's a symlink and just go `vim .gitignore`) will add those
> > changes
> > (unwittingly) to `support/gitignore` - changes that will end up in the
> > patch.
> >
> > I would recommend we add appropriate documentation in the "getting
> started"
> > or "contributing to mesos" guides, as this may catch folks new to the
> > project off-guard.
> > ​
> >
> >
> >>
> >>
> >> On 20 January 2016 at 21:02, Marco Massenzio <m.massen...@gmail.com>
> >> wrote:
> >>
> >>> +1 for consistency
> >>>
> >>> Just a quick note to point out that if you _symlink_ .gitignore, then
> any
> >>> changes folks make to that file (to customize to their needs, eg,
> ignore
> >>> IDE-specific files etc.) would unwittingly become diffs to
> >>> .gitignore_template.
> >>>
> >>> A possible alternative may be to _copy_ .gitignore_template to
> .gitignore,
> >>> so that local changes stay that way (as we already ignore .gitignore).
> >>> The obvious downside is that changes to the _template do not get
> reflected
> >>> to the .gitignore copy; but those are rare enough that we can easily
> >>> address them by dropping an email to this list, perhaps?
> >>>
> >>> (and, yes, using a global ~/.gitignore is a great strategy, but there
> may
> >>> be cases in which it may not be possible/desirable)
> >>>
> >>> I'm easy either way and don't mind whichever we choose; just pointing
> out
> >>> a
> >>> possible issue.
> >>>
> >>> --
> >>> *Marco Massenzio*
> >>>
> >>> http://codetrips.com
> >>>
> >>> On Wed, Jan 20, 2016 at 8:20 PM, Avinash Sridharan <
> avin...@mesosphere.io
> >>>>
> >>> wrote:
> >>>
> >>>> +1 MPark
> >>>>
> >>>> Thanks Kevin for the tip. Found it useful !!
> >>>>
> >>>> On Wed, Jan 20, 2016 at 3:48 PM, Kevin Klues <klue...@gmail.com>
> wrote:
> >>>>
> >>>>> +1 for Consistency!
> >>>>>
> >>>>> As a side note, I add custom .gitignore stuff in a global .gitignore
> >>>>> file I install at ~/.gitignore.  This is useful for ignoring things
> >>>>> specific to editor temporary files (e.g. *.swo in vim), etc.
> >>>>>
> >>>>> you can make git aware of it via:
> >>>>> $ git config --global core.excludesfile ~/.gitignore
> >>>>>
> >>>>> On Wed, Jan 20, 2016 at 3:45 PM, Michael Park <mp...@apache.org>
> >>> wrote:
> >>>>>> We have a few other default templates such as `support/clang-format`
> >>>> and
> >>>>>> `support/reviewboardrc`, and `bootstrap` symlinks them to
> >>>> `.clang-format`
> >>>>>> and `.reviewboardrc` respectively.
> >>>>>>
> >>>>>> To keep this pattern consistent, I would like to move the
> >>>>>> `.gitignore-template` template to `support/gitignore` and have
> >>>>> `bootstrap`
> >>>>>> symlink it to `.gitignore`.
> >>>>>>
> >>>>>> Please let me know if you're opposed to this change.
> >>>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> MPark.
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ~Kevin
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Avinash Sridharan, Mesosphere
> >>>> +1 (323) 702 5245
> >>>>
> >>>
> >>
> >>
>
>

Re: [VOTE] Release Apache Mesos 0.27.0 (rc2)

[Marco Massenzio]

Thanks, buddy - I keep forgetting that one!
(one assumes --all would, well, take care of that too :)

Have a great weekend!

-- 
*Marco Massenzio*
http://codetrips.com

On Fri, Jan 29, 2016 at 7:06 PM, Vinod Kone <vinodk...@gmail.com> wrote:

> Git fetch --tags
>
> @vinodkone
>
> On Jan 29, 2016, at 7:00 PM, Marco Massenzio <m.massen...@gmail.com>
> wrote:
>
> Is there a 0.27.0-rc2 branch cut?
>
> $ git fetch --all
> Fetching origin
>
> $ git co 0.27.0-rc2
> error: pathspec '0.27.0-rc2' did not match any file(s) known to git.
>
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Wed, Jan 27, 2016 at 11:12 PM, Michael Park <mp...@apache.org> wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 0.27.0.
>>
>> 0.27.0 includes the following:
>>
>> 
>> We added major features such as Implicit Roles, Quota, Multiple Disks and
>> more.
>>
>> We also added major bug fixes such as performance improvements to
>> state.json requests and GLOG.
>>
>> The CHANGELOG for the release is available at:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc2
>>
>> 
>>
>> The candidate for Mesos 0.27.0 release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz
>>
>> The tag to be voted on is 0.27.0-rc2:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc2
>>
>> The MD5 checksum of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.asc
>>
>> The PGP key used to sign the release is here:
>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>
>> The JAR is up in Maven in a staging repository here:
>> https://repository.apache.org/content/repositories/orgapachemesos-1100
>>
>> Please vote on releasing this package as Apache Mesos 0.27.0!
>>
>> The vote is open until Sat Jan 30 23:59:59 PST 2016 and passes if a
>> majority of at least 3 +1 PMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Mesos 0.27.0
>> [ ] -1 Do not release this package because ...
>>
>> Thanks,
>>
>> Tim, Kapil, MPark
>>
>
>

Re: [VOTE] Release Apache Mesos 0.27.0 (rc2)

[Marco Massenzio]

On Fri, Jan 29, 2016 at 7:00 PM, Marco Massenzio <m.massen...@gmail.com>
wrote:

> Is there a 0.27.0-rc2 branch cut?
>
> $ git fetch --all
> Fetching origin
>
> $ git co 0.27.0-rc2
> error: pathspec '0.27.0-rc2' did not match any file(s) known to git.
>
> ​well, or a tag, for that matter...

$ git tag | grep 27
0.27.0-rc1
​


>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Wed, Jan 27, 2016 at 11:12 PM, Michael Park <mp...@apache.org> wrote:
>
>> Hi all,
>>
>> Please vote on releasing the following candidate as Apache Mesos 0.27.0.
>>
>> 0.27.0 includes the following:
>>
>> 
>> We added major features such as Implicit Roles, Quota, Multiple Disks and
>> more.
>>
>> We also added major bug fixes such as performance improvements to
>> state.json requests and GLOG.
>>
>> The CHANGELOG for the release is available at:
>>
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc2
>>
>> 
>>
>> The candidate for Mesos 0.27.0 release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz
>>
>> The tag to be voted on is 0.27.0-rc2:
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc2
>>
>> The MD5 checksum of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.md5
>>
>> The signature of the tarball can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.asc
>>
>> The PGP key used to sign the release is here:
>> https://dist.apache.org/repos/dist/release/mesos/KEYS
>>
>> The JAR is up in Maven in a staging repository here:
>> https://repository.apache.org/content/repositories/orgapachemesos-1100
>>
>> Please vote on releasing this package as Apache Mesos 0.27.0!
>>
>> The vote is open until Sat Jan 30 23:59:59 PST 2016 and passes if a
>> majority of at least 3 +1 PMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Mesos 0.27.0
>> [ ] -1 Do not release this package because ...
>>
>> Thanks,
>>
>> Tim, Kapil, MPark
>>
>
>

Re: [VOTE] Release Apache Mesos 0.27.0 (rc2)

[Marco Massenzio]

Is there a 0.27.0-rc2 branch cut?

$ git fetch --all
Fetching origin

$ git co 0.27.0-rc2
error: pathspec '0.27.0-rc2' did not match any file(s) known to git.


-- 
*Marco Massenzio*
http://codetrips.com

On Wed, Jan 27, 2016 at 11:12 PM, Michael Park <mp...@apache.org> wrote:

> Hi all,
>
> Please vote on releasing the following candidate as Apache Mesos 0.27.0.
>
> 0.27.0 includes the following:
>
> 
> We added major features such as Implicit Roles, Quota, Multiple Disks and
> more.
>
> We also added major bug fixes such as performance improvements to
> state.json requests and GLOG.
>
> The CHANGELOG for the release is available at:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc2
>
> 
>
> The candidate for Mesos 0.27.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz
>
> The tag to be voted on is 0.27.0-rc2:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc2
>
> The MD5 checksum of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.md5
>
> The signature of the tarball can be found at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.asc
>
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1100
>
> Please vote on releasing this package as Apache Mesos 0.27.0!
>
> The vote is open until Sat Jan 30 23:59:59 PST 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
> [ ] +1 Release this package as Apache Mesos 0.27.0
> [ ] -1 Do not release this package because ...
>
> Thanks,
>
> Tim, Kapil, MPark
>

Re: .gitignore-template

[Marco Massenzio]

On Thu, Jan 28, 2016 at 3:18 AM, Michael Park <mp...@apache.org> wrote:

> This has been done here:
> https://github.com/apache/mesos/commit/16c62e5965f304ba59f26f4dbe0bcdfaded7c5ae
>

​Unless I'm missing something fundamental here, this means that anyone who
decides to add some pattern to the /.gitignore file (assuming they
don't realize it's a symlink and just go `vim .gitignore`) will add those
changes
(unwittingly) to `support/gitignore` - changes that will end up in the
patch.

I would recommend we add appropriate documentation in the "getting started"
or "contributing to mesos" guides, as this may catch folks new to the
project off-guard.
​


>
>
> On 20 January 2016 at 21:02, Marco Massenzio <m.massen...@gmail.com>
> wrote:
>
>> +1 for consistency
>>
>> Just a quick note to point out that if you _symlink_ .gitignore, then any
>> changes folks make to that file (to customize to their needs, eg, ignore
>> IDE-specific files etc.) would unwittingly become diffs to
>> .gitignore_template.
>>
>> A possible alternative may be to _copy_ .gitignore_template to .gitignore,
>> so that local changes stay that way (as we already ignore .gitignore).
>> The obvious downside is that changes to the _template do not get reflected
>> to the .gitignore copy; but those are rare enough that we can easily
>> address them by dropping an email to this list, perhaps?
>>
>> (and, yes, using a global ~/.gitignore is a great strategy, but there may
>> be cases in which it may not be possible/desirable)
>>
>> I'm easy either way and don't mind whichever we choose; just pointing out
>> a
>> possible issue.
>>
>> --
>> *Marco Massenzio*
>>
>> http://codetrips.com
>>
>> On Wed, Jan 20, 2016 at 8:20 PM, Avinash Sridharan <avin...@mesosphere.io
>> >
>> wrote:
>>
>> > +1 MPark
>> >
>> > Thanks Kevin for the tip. Found it useful !!
>> >
>> > On Wed, Jan 20, 2016 at 3:48 PM, Kevin Klues <klue...@gmail.com> wrote:
>> >
>> > > +1 for Consistency!
>> > >
>> > > As a side note, I add custom .gitignore stuff in a global .gitignore
>> > > file I install at ~/.gitignore.  This is useful for ignoring things
>> > > specific to editor temporary files (e.g. *.swo in vim), etc.
>> > >
>> > > you can make git aware of it via:
>> > > $ git config --global core.excludesfile ~/.gitignore
>> > >
>> > > On Wed, Jan 20, 2016 at 3:45 PM, Michael Park <mp...@apache.org>
>> wrote:
>> > > > We have a few other default templates such as `support/clang-format`
>> > and
>> > > > `support/reviewboardrc`, and `bootstrap` symlinks them to
>> > `.clang-format`
>> > > > and `.reviewboardrc` respectively.
>> > > >
>> > > > To keep this pattern consistent, I would like to move the
>> > > > `.gitignore-template` template to `support/gitignore` and have
>> > > `bootstrap`
>> > > > symlink it to `.gitignore`.
>> > > >
>> > > > Please let me know if you're opposed to this change.
>> > > >
>> > > > Thanks!
>> > > >
>> > > > MPark.
>> > >
>> > >
>> > >
>> > > --
>> > > ~Kevin
>> > >
>> >
>> >
>> >
>> > --
>> > Avinash Sridharan, Mesosphere
>> > +1 (323) 702 5245
>> >
>>
>
>

Re: JIRA Shepherds

[Marco Massenzio]

Having been on both sides of the fence, so to speak, I can certainly
sympathize with the plight of the committers, especially now that the Mesos
contributors community is growing so fast!

A great problem to have, I guess...

May I also suggest however that also we have some sort of "SLA" on the
Shepherd's part of looking at the code within a reasonable timeframe of the
review posted?  Or at least, an agreed timeline?

Also, I'm quite curious to know what are the criteria for choosing which
projects/Jiras are prioritized for shepherding?

Thanks!

-- 
*Marco Massenzio*
http://codetrips.com

On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
joris.van.remoort...@gmail.com> wrote:

> Hello Mesos developers,
>
> You may have noticed some churn in Jira recently around the shepherd
> assignment. Specifically, we have unassigned the shepherds for a bunch of
> projects. We did this in order to get a better sense of which projects are
> being actively shepherded versus having gone stale, and to identify for
> which projects we need to find a new shepherd who has sufficient time to
> dedicate to it.
>
> This is not a statement that the un-assigned tickets are not important,
> rather, we want to ensure that the people working on them have a shepherd
> with sufficient resources.
>
> We ask that you communicate (and agree!) with your shepherd before
> assigning them in Jira, so that they are not surprised when you reviews
> start getting posted.
>
> The benefit for the developer community should be that it will be more
> clear when working on a ticket whether there are sufficient resources in
> the community to iterate on it in a timely manner.
>
> Joris
>

Re: .gitignore-template

[Marco Massenzio]

+1 for consistency

Just a quick note to point out that if you _symlink_ .gitignore, then any
changes folks make to that file (to customize to their needs, eg, ignore
IDE-specific files etc.) would unwittingly become diffs to
.gitignore_template.

A possible alternative may be to _copy_ .gitignore_template to .gitignore,
so that local changes stay that way (as we already ignore .gitignore).
The obvious downside is that changes to the _template do not get reflected
to the .gitignore copy; but those are rare enough that we can easily
address them by dropping an email to this list, perhaps?

(and, yes, using a global ~/.gitignore is a great strategy, but there may
be cases in which it may not be possible/desirable)

I'm easy either way and don't mind whichever we choose; just pointing out a
possible issue.

-- 
*Marco Massenzio*
http://codetrips.com

On Wed, Jan 20, 2016 at 8:20 PM, Avinash Sridharan <avin...@mesosphere.io>
wrote:

> +1 MPark
>
> Thanks Kevin for the tip. Found it useful !!
>
> On Wed, Jan 20, 2016 at 3:48 PM, Kevin Klues <klue...@gmail.com> wrote:
>
> > +1 for Consistency!
> >
> > As a side note, I add custom .gitignore stuff in a global .gitignore
> > file I install at ~/.gitignore.  This is useful for ignoring things
> > specific to editor temporary files (e.g. *.swo in vim), etc.
> >
> > you can make git aware of it via:
> > $ git config --global core.excludesfile ~/.gitignore
> >
> > On Wed, Jan 20, 2016 at 3:45 PM, Michael Park <mp...@apache.org> wrote:
> > > We have a few other default templates such as `support/clang-format`
> and
> > > `support/reviewboardrc`, and `bootstrap` symlinks them to
> `.clang-format`
> > > and `.reviewboardrc` respectively.
> > >
> > > To keep this pattern consistent, I would like to move the
> > > `.gitignore-template` template to `support/gitignore` and have
> > `bootstrap`
> > > symlink it to `.gitignore`.
> > >
> > > Please let me know if you're opposed to this change.
> > >
> > > Thanks!
> > >
> > > MPark.
> >
> >
> >
> > --
> > ~Kevin
> >
>
>
>
> --
> Avinash Sridharan, Mesosphere
> +1 (323) 702 5245
>

Re: Install some 3rdparty packages needed for building Mesos modules

[Marco Massenzio]

Great thinking, Kapil!
(I'm one who got the headache :)

However, having recently gone through the effort of having to figure out it
all, my +1 goes for *good documentation* of what is necessary.

When installing stuff / magic happening behind the scenes, it is always
difficult to ensure it works on all "supported" platforms (and let's not
even go into non-supported ones) and we would also run the risk that future
changes may inadvertently break it.

Bear also in mind that folks (who may not be using the --prefix) may be
"surprised" to find incompatible/unexpected versions of glog/protobuf/etc.
in the /usr/local system dir.

We could also provide "exemplary scripts" that automate (most of) the
tedious work and example build files, alongside documentation.
If folks agree that this is a desirable alternative, I'm happy to help out
- as mentioned, I've recently been through this, so memory is still fresh.

My 2c.

-- 
*Marco Massenzio*
http://codetrips.com

On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya <ka...@mesosphere.io> wrote:

> On Tue, Jan 19, 2016 at 11:58 PM, James Peach <jor...@gmail.com> wrote:
> >
> >> On Jan 19, 2016, at 2:03 PM, Kapil Arya <ka...@mesosphere.io> wrote:
> >>
> >> Hi All,
> >>
> >> I wanted to get your opinion on installing the 3rdparty packages glog,
> >> protobuf, boost and picojson[1] when installing Mesos itself. These
> >> packages are required to build Mesos modules.
> >
> > An alternative approach could be to hide these headers so they are
> internal to Mesos and not incidentally required by innocent modules. IIRC
> this should be fairly easy for picojson, but (much) harder for glog,
> protobuf and boost.
>
> That's a lot of work and super hard to maintain IMHO :(.
>
> >> Currently, a module write has to manually install these 3rdparty
> >> packages, either system-wide or locally, and update the compilation
> >> flags such as CPPFLAGS to point to the installation which is
> >> error-prone. Further, one might have a system-wide installation with
> >> the wrong package version, causing even more headache.
> >
> > If you are looking at this, could you please also look at these:
> > https://issues.apache.org/jira/browse/MESOS-2537
> > https://issues.apache.org/jira/browse/MESOS-4096
> >
> > MESOS-2537 provides consistent behaviour for building against optionally
> bundled dependencies (and fixes the --enable-foo semantics).
>
> I'll take a look at this one.
>
> > MESOS-4096 makes it impossible to run stout tests against a protobuf
> that is not version 2.5.0.
>
> At some point, AlexR and I tried to work on it, but with the stout
> directory structure, it got harder to fix then it seemed at first.
>
> >
> >> The proposal here is to install these 3rdparty packages when
> >> installing Mesos. To avoid any conflicts with system-wide or local
> >> installation, we can install them as follows:
> >>
> >> ${PREFIX}/include/mesos/3rdparty -- for header files
> >> ${PREFIX}//mesos/3rdparty -- for library files (LIBDIR can be
> >> lib or lib64 depending upon the installation)
> >>
> >> where PREFIX refers to the `--prefix` flag for Mesos configure script.
> >>
> >> We would then update `mesos.pc` with the correct flags so that a
> >> module write can simply use `pkg-config` to get all the required
> >> flags.
> >>
> >> I have created an issue
> >> https://issues.apache.org/jira/browse/MESOS-4434 to track this.
> >>
> >> Best,
> >> Kapil
> >>
> >>
> >> [1]: picojson is currently installed in ${PREFIX}/include. See
> >> https://issues.apache.org/jira/browse/MESOS-3909
> >
>

Re: Operator HTTP endpoints

[Marco Massenzio]

+1 for Lukas's suggestion to have `force` be a query argument (eg,
``?force=true``) and the body respect the ``Content-Type`` header.

(although I was part of the conversation of adding the ``force`` flag to
the SUBSCRIBE message, I forget the exact details of that one - @Vinod may
be able to chime in).

Thanks for getting the conversation started!

-- 
*Marco Massenzio*
http://codetrips.com

On Thu, Jan 14, 2016 at 11:09 AM, Alex Rukletsov <a...@mesosphere.com>
wrote:

> Folks,
>
> I would like to gather your opinions about a concern related to operator
> HTTP endpoints. From one side we agreed that for simplicity and consistency
> we should bake all request data in a single JSON. From the other side, some
> parameters, like a force flag, do not really belong to request JSON (as
> pointed out by some SRE guys in comment to MESOS-3914 [1]). The force flag
> is not really related to the request itself, but more to the way the
> request should be processed.
>
> To my knowledge, currently we use the force flag in two places:
>   * Subscribe call in framework API.
>   * Quota set request.
>
> Currently we have the 'force' field in JSON both cases.
>
> I would like us to agree on the way we write endpoints and clean-up
> existing ones *before* we release Mesos 1.0. Looking forward to your
> feedback.
>
> AlexR
>
> [1] https://issues.apache.org/jira/browse/MESOS-3914
>

Re: Anonymous Modules "runtime context"

[Marco Massenzio]

@haosdent / @james:

Thanks for your comments, also feel free to chime in on the Jira.
Kapil just confirmed he's happy to shepherd, so we're good to go.

As for adding more "stuff" - I do agree, `Flags` is a bit on the "bare
minimum" but also I wanted to avoid stuffing this method with "too much
information."

We can probably add more (I was thinking a pointer to the just-created
instance of the 'Master' or 'Slave' class, may come in handy?) so I'll be
looking forward to hear what folks have to suggest.

Thanks!



-- 
*Marco Massenzio*
http://codetrips.com

On Mon, Jan 11, 2016 at 11:52 AM, James Peach <jor...@gmail.com> wrote:

>
> > On Jan 8, 2016, at 9:43 PM, Marco Massenzio <m.massen...@gmail.com>
> wrote:
> >
> > Hey folks,
> >
> > any takers?
> > I'd really like to have an initial conversation about MESOS-4253,
>
> I think the concept is useful, though I'm not sure that just getting Flags
> is enough. For example, I think it is reasonable for a module to store
> state in the same place the agent does (ie $work_dir/meta/slaves/latest)
> and the Flags would not be enough for that. I bet other people can come up
> with lots of similar examples.
>
> > anyone
> > willing to shepherd this one?
> >
> > Many thanks!
> >
> > --
> > *Marco Massenzio*
> > http://codetrips.com
> >
> > On Mon, Jan 4, 2016 at 12:19 PM, Marco Massenzio <m.massen...@gmail.com>
> > wrote:
> >
> >> Happy New Year, everyone!
> >>
> >> During the break, I've been playing with a toy anon module[0] mostly for
> >> "learning" purposes.
> >>
> >> In doing so, I realized it would be useful, as a developer, to get
> access
> >> to even a "minimal" runtime context and filed MESOS-4253[1].
> >> (there was also a TODO from benh in the respective main.cpp of both
> >> master/slave).
> >>
> >> I've submitted a review chain[2], which can be seen as a "proof of
> >> concept," and would really be grateful if:
> >>
> >> - someone volunteered to be a shepherd for MESOS-4253
> >>  (in particular, I'd like to discuss the approach, and especially
> whether
> >> just passing the Flags is sufficient, or there is something else that
> may
> >> be of interest);
> >>
> >> - someone could cast a quick critical glance on r/41760 and provide
> >> feedback;
> >>
> >> - finally (no pun intended), I'd like to have conversation around
> whether
> >> we should also introduce a `finalize()` method too (again, there is a
> TODO
> >> about this as well).
> >> (I think we should, but can be convinced otherwise)
> >>
> >> Thanks in advance!
> >>
> >> [0] https://github.com/massenz/execute-module
> >> [1] https://issues.apache.org/jira/browse/MESOS-4253
> >> [2] https://reviews.apache.org/r/41760/
> >> --
> >> *Marco Massenzio*
> >> http://codetrips.com
> >>
>
>

Re: [MESOS-1865] Redirect to the leader master when current master is not a leader.

[Marco Massenzio]

+1
(my two cent is that the “correct” approach from an operations viewpoint is to 
first query for the leader, then ask the leader; shortcoming identified by Ben 
obvious, but possibly the lesser of the two evils - and probably unavoidable in 
a distributed systems without atomic transactions - which I don’t think anyone 
on this list would advocate for?)

Thanks to the Benjamin(s) for (finally) giving a name to something I have 
encountered often :)
(I used to informally call it “the A-B problems” - your naming is definitely 
more compelling!)

> On Jan 8, 2016, at 12:29 PM, Benjamin Mahler  wrote:
> 
> Some feedback on this ticket: it focuses on the solution rather than the
> problem. We generally want to avoid this, I guess it's been coined 'The XY
> Problem' (thanks Benjamin Bannier). In this case it turns out that there
> are actually 2 distinct problems that the user is facing:
> 
> (1) Passive masters return information in some endpoints that can be
> interpreted as incorrect. A passive master does not know the list of tasks,
> for example, and so returning an empty list is less accurate than
> expressing that no response is possible.
> 
> (2) It is difficult to reliably obtain cluster state through the existing
> endpoints. This one is less clear to me than the first problem. Here we
> have to think through how we want users to be hitting state endpoints. Do
> they hit all the masters and take the first valid response? Do they first
> ask for the leader, then query the leader? Both of these have races (the
> first case has an issue that the requests are not atomic, you may receive
> two valid responses ; the second case the leader information may become
> stale before the second request). Do we add redirects? Even redirects have
> issues, there may be multiple redirects, there may be a redirect to a
> master that is unable to redirect further (and so we haven't really solved
> the race difficulties with redirects).
> 
> The point is, it looks like we can easily solve (1), but (2) warrants more
> thought and will be easier to assess with the problem well understood.
> 
> On Wed, Jan 6, 2016 at 12:52 PM, Diogo Gomes  wrote:
> 
>> Hi, Adam and Haosdent
>> 
>> 
>> Resurrecting this issue, https://issues.apache.org/jira/browse/MESOS-1865,
>> I would like to make a +1 for this change, which apparently became cold but
>> I think is very relevant and we had enough time to be prepared for a change
>> like this, right?
>> 
>> 
>> If necessary, can I help with something?
>> 
>> 
>> Diogo Gomes
>> 
>> 
>> 
>> 
>> 

Re: Anonymous Modules "runtime context"

[Marco Massenzio]

Hey folks,

any takers?
I'd really like to have an initial conversation about MESOS-4253, anyone
willing to shepherd this one?

Many thanks!

-- 
*Marco Massenzio*
http://codetrips.com

On Mon, Jan 4, 2016 at 12:19 PM, Marco Massenzio <m.massen...@gmail.com>
wrote:

> Happy New Year, everyone!
>
> During the break, I've been playing with a toy anon module[0] mostly for
> "learning" purposes.
>
> In doing so, I realized it would be useful, as a developer, to get access
> to even a "minimal" runtime context and filed MESOS-4253[1].
> (there was also a TODO from benh in the respective main.cpp of both
> master/slave).
>
> I've submitted a review chain[2], which can be seen as a "proof of
> concept," and would really be grateful if:
>
> - someone volunteered to be a shepherd for MESOS-4253
>   (in particular, I'd like to discuss the approach, and especially whether
> just passing the Flags is sufficient, or there is something else that may
> be of interest);
>
> - someone could cast a quick critical glance on r/41760 and provide
> feedback;
>
> - finally (no pun intended), I'd like to have conversation around whether
> we should also introduce a `finalize()` method too (again, there is a TODO
> about this as well).
> (I think we should, but can be convinced otherwise)
>
> Thanks in advance!
>
> [0] https://github.com/massenz/execute-module
> [1] https://issues.apache.org/jira/browse/MESOS-4253
> [2] https://reviews.apache.org/r/41760/
> --
> *Marco Massenzio*
> http://codetrips.com
>

Anonymous Modules "runtime context"

[Marco Massenzio]

Happy New Year, everyone!

During the break, I've been playing with a toy anon module[0] mostly for
"learning" purposes.

In doing so, I realized it would be useful, as a developer, to get access
to even a "minimal" runtime context and filed MESOS-4253[1].
(there was also a TODO from benh in the respective main.cpp of both
master/slave).

I've submitted a review chain[2], which can be seen as a "proof of
concept," and would really be grateful if:

- someone volunteered to be a shepherd for MESOS-4253
  (in particular, I'd like to discuss the approach, and especially whether
just passing the Flags is sufficient, or there is something else that may
be of interest);

- someone could cast a quick critical glance on r/41760 and provide
feedback;

- finally (no pun intended), I'd like to have conversation around whether
we should also introduce a `finalize()` method too (again, there is a TODO
about this as well).
(I think we should, but can be convinced otherwise)

Thanks in advance!

[0] https://github.com/massenz/execute-module
[1] https://issues.apache.org/jira/browse/MESOS-4253
[2] https://reviews.apache.org/r/41760/
-- 
*Marco Massenzio*
http://codetrips.com

Re: Anyone successfully setup CLION with mesos?

[Marco Massenzio]

IIRC don't "import" it, just "open" the folder.
I may be wrong there - I'll give it another shot on a "clean" Mac and let
you know what I find.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Fri, Nov 27, 2015 at 7:25 AM, Shiyao Ma <i...@introo.me> wrote:

> I still cannot set it up with CLION.
>
> I am on osx10.11.
>
> Here is what I do,
>
> git clone the latest mesos repo.
>
> open clion and import it, (using the CMakeList.txt in the repo)
>
> it looks like all the code under src/ are not considered project sources.
>
> In this screenshot, http://snag.gy/PsDGn.jpg  files and folders are dark
> (indicating they are not project files).
>
>
>
> Regards.
>

Re: Anyone successfully setup CLION with mesos?

[Marco Massenzio]

I did set it up with CLion - it's not perfect (still a few "false
positives" on compile errors and it gets confused in places) but it's
definitely better than the best I was able to achieve with Eclipse (see my
blog link below for details on that one).

I can't exactly remember what I did to make it all work, but I think you
can just point it to the CMakeList.txt top-level file, then CLion will do
the rest and figure it out - Alex will correct me, but last time I tried, I
was only able to use it up to the `stouttests` target, I'm sure a lot more
work now.

At any rate, code navigation, auto-completion, etc. work just fine.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Wed, Nov 25, 2015 at 10:41 PM, Alex Clemmer <clemmer.alexan...@gmail.com>
wrote:

> CMake support is not quite mature yet. I think we're at least a couple
> months out before it's really ready to rely on, but I'm quite happy to
> hear about your bugs! Feel free to file them against me (I'm
> `hausdorff` on the JIRA), and I'll make sure they get routed properly.
>
> On Wed, Nov 25, 2015 at 8:22 PM, haosdent <haosd...@gmail.com> wrote:
> > I set up success for it. Because Mesos have cmake support now. Import it
> as
> > a cmake project.
> >
> > On Thu, Nov 26, 2015 at 12:21 PM, Shiyao Ma <i...@introo.me> wrote:
> >
> >> Hi,
> >>
> >> I'd like to browse the mesos code with abilities such as  jump to
> >> definitions, etc.
> >>
> >> Ctags and Youcompleteme fall short here.
> >>
> >> So I think CLION might be a good way to go, so anybody managed to do
> that
> >> with CLion?
> >>
> >> What's the setup ?
> >>
> >>
> >> Thanks.
> >>
> >>
> >> shiyao
> >>
> >
> >
> >
> > --
> > Best Regards,
> > Haosdent Huang
>
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>

Re: Initial leader election

[Marco Massenzio]

A quick glance of the logs doesn't show anything that stands out, apart
from:

--zk_session_timeout="10secs"

which seems to lead to:

Nov 23 16:50:13 node1 mesos-master[17501]: I1123 16:50:13.594151 17521
recover.cpp:111] Unable to finish the recover protocol in 10secs,
retrying

That is the default value, but maybe your setup may need longer than that
(it is possible that the time it takes for all master nodes to come up and
reach quorum may be the issue).

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Wed, Nov 25, 2015 at 3:06 AM, Guilherme Moro <guilherme.m...@ammeon.com>
wrote:

> https://issues.apache.org/jira/browse/MESOS-4010
>
> On 24 November 2015 at 13:55, Klaus Ma <klaus1982...@gmail.com> wrote:
>
> > I'd suggest to open a JIRA to trace issue; I think you can append
> > master.log & slave.log for owner reference.
> >
> > 
> > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> >
> > On Tue, Nov 24, 2015 at 8:45 PM, Guilherme Moro <
> guilherme.m...@ammeon.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > I'm having a problem while trying to create the initial cluster, no
> > leader
> > > is elected.
> > > For a start, let me explain my setup:
> > > 3 nodes
> > > 3 zookeepers
> > > 3 mesos-master services, configured as initctl services and controlled
> by
> > > puppet, RPM's installed are from the RHEL repository at mesosphere
> > > (installed through puppet as well), running on RHEL 6.6
> > > Quorum is set to 2, as expected, all the remaining configs were double
> > > checked and appears to be correct.
> > > Most of times I can get the cluster to bootstrap after rebooting the
> > nodes
> > > (sometimes more than once).
> > > The whole thing resembles a bit
> > > https://issues.apache.org/jira/browse/MESOS-2148 and
> > > https://issues.apache.org/jira/browse/MESOS-2014
> > >
> > > Even when I get the master elected, sometimes another couple of reboots
> > or
> > > restarts of the services are needed to get all the slave nodes added
> > (they
> > > are the same nodes as the masters).
> > >
> > > I can quite easily reproduce this behavior, if someone cares to look at
> > > logs tell me exactly what to collect and what logging flags I should
> > > enable.
> > >
> > > So, should I maybe open a bug or is there any trick to bootstrap the
> > > cluster that I'm losing here.
> > >
> > > Regards,
> > >
> > > Guilherme Moro
> > >
> > > --
> > > This email and any files transmitted with it are confidential and
> > intended
> > > solely for the use of the individual or entity to whom they are
> > addressed.
> > > If you have received this email in error please notify the system
> > manager.
> > > This message contains confidential information and is intended only for
> > the
> > > individual named. If you are not the named addressee you should not
> > > disseminate, distribute or copy this e-mail.
> > >
> > >
> >
>
> --
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail.
>
>

Re: Configuration file?

[Marco Massenzio]

On Tue, Nov 24, 2015 at 10:45 AM, Adam Avilla <a...@avil.la> wrote:

> Is there any way to support HUP reloading of config with this design
> paradigm?


Can you please elaborate what do you mean by "support HUP reloading"?
I don't suppose anyone really runs Mesos in production inside a terminal?

At any rate, being a facade, this will support exactly what Mesos supports
(and, currently, no, it does not support dynamic configuration reload).


> Is HUPing mesos even possible / helpful? From an end user
> perspective it sounds useful, but I am not sure if even possible for mesos
> to accomplish safely.
>

If you are running Mesos in multi-Master configuration (using, eg,
Zookeeper) yes, it is safe to re-start the process, so long as you always
maintain a --quorum of servers running.
In fact, that's the recommended way to do a Mesos cluster upgrade.

But, again, I don't really think this is what you meant by "HUPing Mesos"?
(I mean, if you `kill -1 ` this seems to just terminate Master - at
least on OSX)



> On Nov 24, 2015 10:04 AM, "haosdent" <haosd...@gmail.com> wrote:
>
> > Use YAML sounds great. Suppose I am a framework developer, use a widely
> > used format would be helpful. Because framework maybe written by
> different
> > programming languages, if use some rare formats, I have to write some
> code
> > to parse the configuration file when I want to get some fields from it.
> >
> > On Wed, Nov 25, 2015 at 1:57 AM, Tomek Janiszewski <jani...@gmail.com>
> > wrote:
> >
> > > Hi all
> > >
> > > It looks simple for the first sight. Marco, I can work on it.
> > >
> > > -
> > > Tomek
> > >
> > > wt., 24 lis 2015, 17:49 Marco Massenzio użytkownik <
> ma...@mesosphere.io>
> > > napisał:
> > >
> > > > Thank you for asking :)
> > > >
> > > > The idea is pretty simple (and not even original, it's the "Facade
> > > > pattern"): essentially we would define a YAML syntax for the various
> > > > configuration flags that Mesos ({Master, Agent}) define, possibly
> > > grouping
> > > > them by "topic" and then write a few python classes, that read in the
> > > YAML
> > > > configuration and emit a set of flags that reflect the caller intent,
> > > then
> > > > invoke the appropriate ./bin/mesos-{master,slave}.sh script.
> > > >
> > > > (variation on the theme for installed packages)
> > > >
> > > > E.g.:
> > > >
> > > > # Configuration /opt/mesos/config-master.yml
> > > >
> > > > ip: 192.168.1.101
> > > >
> > > > zk:
> > > >   url: zk://192.168.1.220:2181
> > > >   quorum: 3
> > > >
> > > > directories:
> > > >   work: /var/run/mesos
> > > >   log: /var/log/mesos/master.log
> > > >
> > > > Execute with:
> > > >
> > > >   ./mesos-wrapper.py --run master --config
> /opt/mesos/config-master.yml
> > > > --no-ssl \
> > > >  [other script-specific options]
> > > >
> > > > would generate something along the lines of:
> > > >
> > > >   /opt/mesos/bin/mesos-master.sh --ip=192.168.1.101 \
> > > > --zk=zk://192.168.1.220:2181 --quorum=3 \
> > > > --work_dir=/var/run/mesos --log_dir=/var/log/mesos/master.log
> > > >
> > > > (example greatly contrived and probably pointless, but hopefully
> gives
> > > you
> > > > the idea).
> > > >
> > > > The point is that leveraging Python and the existing YAML libraries,
> > this
> > > > would be pretty quick to implement, would leave Mesos per se
> completely
> > > > untouched, and would be easy to maintain (add/remove flags as needed;
> > > > enforce deprecation cycles; etc.)
> > > >
> > > > There's probably a ton of detail I'm missing, but you get the point.
> > > >
> > > > Cheers,
> > > > M.
> > > >
> > > > On Tuesday, November 24, 2015, tommy xiao <xia...@gmail.com> wrote:
> > > >
> > > > > how to do that? Marco
> > > > >
> > > > > 2015-11-24 3:54 GMT+08:00 Marco Massenzio <ma...@mesosphere.io
> > > > > <javascript:;>>:
> > > > >
> > > > > > I was thinking along the same lines, with a slightly more
> "modern"
> > > > >

Re: Configuration file?

[Marco Massenzio]

ah, ok - sorry, I do use Ngnix, but a bit like a caveman :)

we (as in, Mesosphere) recommend that Mesos (master/agents) are run under
supervision (either systemd or upstart or supervisord or your favorite
supervisor) so that when the process gets killed (by accident / bug /
planned restart) the supervisor will restart it (as the case may be, with
the new configuration).

Maybe that is the best paradigm then. Use HA setup with Zookeeper and

roll config to one master, restart, wash, rinse, repeat?


yup!
look, ma', no downtime :)


--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Tue, Nov 24, 2015 at 8:20 PM, Adam Avilla <a...@avil.la> wrote:

> On Tue, Nov 24, 2015 at 3:15 PM, Marco Massenzio <ma...@mesosphere.io>
> wrote:
>
> > On Tue, Nov 24, 2015 at 10:45 AM, Adam Avilla <a...@avil.la> wrote:
> >
> > > Is there any way to support HUP reloading of config with this design
> > > paradigm?
> >
> >
> > Can you please elaborate what do you mean by "support HUP reloading"?
> > I don't suppose anyone really runs Mesos in production inside a terminal?
> >
>
> I mean like how webservers and other systems work. NGINX is an example of
> the paradigm:
>
> http://nginx.org/en/docs/control.html
>
> you will see HUP spawns new workers with new config, gracefully shutting
> down old workers.
>
> Use case is config management system copies new configs to masters, HUP
> to reload, no downtime. Maybe this is already possible? If so, excuse my
> ignorance :$.
>
>
> > > Is HUPing mesos even possible / helpful? From an end user
> > > perspective it sounds useful, but I am not sure if even possible for
> > mesos
> > > to accomplish safely.
> > >
> >
> > If you are running Mesos in multi-Master configuration (using, eg,
> > Zookeeper) yes, it is safe to re-start the process, so long as you always
> > maintain a --quorum of servers running.
> > In fact, that's the recommended way to do a Mesos cluster upgrade.
> >
> > But, again, I don't really think this is what you meant by "HUPing
> Mesos"?
> > (I mean, if you `kill -1 ` this seems to just terminate Master - at
> > least on OSX)
> >
>
> Maybe that is the best paradigm then. Use HA setup with Zookeeper and
> roll config to one master, restart, wash, rinse, repeat?
>

Re: Configuration file?

[Marco Massenzio]

I was thinking along the same lines, with a slightly more "modern" approach
:)

My idea was to write a thin Python layer that reads a configuration YAML
file (possibly with "override" flags) and then invokes mesos-{master,slave}
with the appropriate flags.

By using YAML, we would also gain the ability to have more intuitive
syntax; grouping flags by function; and make it extensible.

Any takers who may want to work together on this one?

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Mon, Nov 23, 2015 at 11:18 AM, Vinod Kone <vinodk...@gmail.com> wrote:

> We had this discussion a long while ago and the argument was that we
> already have a configuration file of sorts. It is a bash script with one
> flag per line that sets the environment. Is this not sufficient?
>
> Example:
>
> config.sh
> 
> MESOS_WORK_DIR="/var/run/mesos"
> MESOS_QUORUM=2
>
> $ source config.sh
> $ ./bin/mesos-master.sh
>
>
>
> On Mon, Nov 23, 2015 at 10:19 AM, Jojy Varghese <j...@mesosphere.io>
> wrote:
>
> > Thanks for bringing this topic up Alex. I have been thinking about the
> same
> > and was wondering if we can have subsystem specific flags and some scheme
> > where there can be a namespace instead of a flat space. And as alex
> > suggested, a configuration to represent this?
> >
> > -jojy
> > On Mon, Nov 23, 2015 at 9:32 AM tommy xiao <xia...@gmail.com> wrote:
> >
> > > please file a issue to tracking this proposal
> > >
> > > 2015-11-23 21:53 GMT+08:00 Klaus Ma <klaus1982...@gmail.com>:
> > >
> > > > +1, that's helpful :).
> > > >
> > > > For the detail of implementing such as auto re-load, I think we can
> let
> > > > owner/shepherd to decide :).
> > > >
> > > > 
> > > > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > > > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > > > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> > > >
> > > > On Mon, Nov 23, 2015 at 9:40 PM, Adam Avilla <a...@avil.la> wrote:
> > > >
> > > > > +1 I think it would be helpful.
> > > > >
> > > > > This may be orthogonal / feature creep, but would it be possible to
> > > have
> > > > > the config file be able to be safely reloaded with a HUP or
> > appropriate
> > > > > signal?
> > > > >
> > > > > On Mon, Nov 23, 2015 at 5:32 AM, Guangya Liu <gyliu...@gmail.com>
> > > wrote:
> > > > >
> > > > > > +1000, introducing a new configuration file for mesos master and
> > > slave
> > > > > can
> > > > > > help end user take the configuration file as the source of all
> > flags.
> > > > > >
> > > > > > The OpenStack is also using same way to manage all of the flags,
> it
> > > is
> > > > > > putting all flags into a configuration file and the configuration
> > > file
> > > > > > including all flag examples. Most of the flags are disabled by
> > > default
> > > > > and
> > > > > > the end user can just enable those flags based on his
> requirement.
> > > > > >
> > > > > > Also the flags in the configuration file can be classified to
> > > different
> > > > > > groups for a better management, and mesos can also follow this to
> > > > > classify
> > > > > > those flags to different groups, such as ACL, Cluster, framework
> > etc.
> > > > > >
> > > > > >
> > > > > > On Mon, Nov 23, 2015 at 9:08 PM, Alexander Rojas <
> > > > > alexan...@mesosphere.io>
> > > > > > wrote:
> > > > > >
> > > > > > > Hey guys,
> > > > > > >
> > > > > > > Over the time I’ve been involved in Mesos I’ve seen that we
> went
> > > > from a
> > > > > > > handful of flags to around 42 supported flags in the master. At
> > > this
> > > > > > point
> > > > > > > I’m wondering if perhaps we should support a configuration file
> > in
> > > > > > > conjunction (or instead of) with all the command flags.
> > > > > > >
> > > > > > > My intuition is that it will make it easier for operators as
> well
> > > as
> > > > > for
> > > > > > > debuggers to be able to replicate configurations easier.
> > > > > > >
> > > > > > > Any comments on this idea?
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > /adam
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Deshi Xiao
> > > Twitter: xds2000
> > > E-mail: xiaods(AT)gmail.com
> > >
> >
>

Re: Release / deprecation policy

[Marco Massenzio]

Thanks, Neil, for getting the ball rolling on the matter.

Absolutely in favor of extending the deprecation cycle of features to make
framework developers' and operators' lives easier.

However,
-1 for extending compatibility up to N - 6

1) this prevents us to innovate and introduce functionality as quickly as
we still believe is necessary at this stage of development;

2) it makes release testing explode combinatorially (it's already bad
enough as it is right now).
as you correctly noted.

Please note those are two different problems that we'd be addressing here,
and I don't really think that #2 has been really an issue so far (but, yes,
of course, it might in the future).

Hence,
+1
in providing tooling to make cluster upgrades easier to automate.

Thanks!

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Mon, Nov 16, 2015 at 9:24 PM, Neil Conway <neil.con...@gmail.com> wrote:

> Folks,
>
> In the last community sync, we briefly discussed Mesos release policy.
> In particular, we talked about the current cadence of ~monthly
> releases and how that relates to (a) deprecation periods (b) support
> for running a "mixed version" cluster.
>
> As I understand it, the current policy is as follows:
>
> * To remove functionality, it should first be deprecated in one
> release and can then be removed in the next.
> * Mixed cluster versions are supported going back one release: e.g.,
> 0.25 masters and slaves must support communicating with 0.24 masters
> and slaves.
>
> Given that Mesos 1.0 is on the not-to-distant horizon (at which point
> we'll have different guarantees about API stability), I think we can
> revisit adopting a formal release policy at that point. In the
> interim, are there any pressing problems we need to address?
>
> Deprecation:
> ==
>
> Removing deprecated functionality after one release makes sense when
> releases were made relatively infrequently, but with a monthly release
> cycle, this seems like an unreasonable rate of change to expect from
> authors of frameworks and tools.
>
> Proposal: After marking functionality as deprecated (e.g., in the
> documentation and "upgrade guide"), we should wait for at least 6
> monthly releases before removing it. So functionality that has been
> deprecated in 0.26 can be safely removed in 0.32.
>
> Mixed Cluster Versions:
> ==
>
> We could adopt the same rule as above (if any two releases are made
> within six months of one another, they must be compatible), or else we
> could keep the same compatibility policy we have now (single release).
> I'm not sure the right answer here: keeping the current policy will
> make upgrading from, say, 0.26 to 0.32 somewhat painful, but (a) that
> can be ameliorated with deployment tooling (b) if we change to a 6-12
> month compatibility period, it will make testing the full
> compatibility matrix pretty difficult.
>
> Comments welcome!
>
> Neil
>

Re: Sheperd wanted for new contributor

[Marco Massenzio]

Hey Felix,

it's great to hear that you want to start contributing to Mesos!
As pointed out in the "starter" guidelines [0] we recommend folks that are
new to contributing to Apache Mesos, to "warm up" by picking one of the
jiras that are labeled with the "Newbie" tag[1].

That way you can familiarize with our code style, using ReviewBoard (for
example, submitting a PR was a bit of a non-starter) and, generally, making
life easier for the shepherd.

In the meantime, I've added you to the Contributors group in Jira, so you
can now assign tasks to yourself (but before you do so, make sure you
understand what the implications are).

Thanks and welcome to our community!

[0] http://mesos.apache.org/documentation/latest/submitting-a-patch/
[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20mesos%20and%20labels%20in%20(newbie)%20and%20status%20%3D%20Accepted%20and%20assignee%20is%20EMPTY

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Wed, Nov 11, 2015 at 9:59 PM, Bechstein, Felix <felix.bechst...@otto.de>
wrote:

> Hi,
> I'd like to work on MESOS-3307 "Configurable size of completed task /
> framework history" [1]. Can someone be the sheperd?
> I created accounts for jira and review with username "flx".
> I'd like to discuss my changes. There is already PR on github [2].
> Thanks.
> Regards,
> Felix
> [1]: https://issues.apache.org/jira/browse/MESOS-3307
> [2]: https://github.com/apache/mesos/pull/82

Re: Add JIRA ticket# to `TODO`s in comments

[Marco Massenzio]

-1
for mandatory adding MESOS- to TODO.

it makes it more cumbersome to add TODOs and, I fear, would discourage
people from adding those.
For example in a "chain", TODOs may be short-lived enough that adding a
Jira would only add noise.

I'm not even sure that (optionally) adding the Jira to the TODO will add
much value (in fact, it may make our backlog even more "noisy" than it
currently is) but I am willing to experiment with this and see how it goes.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Wed, Nov 11, 2015 at 8:40 AM, Alex Rukletsov <a...@mesosphere.com> wrote:

> I think we should encourage people to follow this pattern, but not making
> this obligatory.
>
> I may be wrong, but I feel that sometimes we use `TODO`s as food for
> thought, not for something that should or will necessarily be implemented
> soon. A `TODO` may provide additional context to the implementation from
> the perspective, how the code or related feature may evolve in the future.
> However, that original vision may change over time, so it's not always
> reasonable to create a ticket.
>
> On Wed, Nov 11, 2015 at 4:57 PM, Kapil Arya <ka...@mesosphere.io> wrote:
>
> > Hi Ben,
> >
> > On Wed, Nov 11, 2015 at 8:33 AM, Benjamin Mahler <
> > benjamin.mah...@gmail.com>
> > wrote:
> >
> > > Kapil would you mind clarifying what is being proposed here? Folks are
> > > already free to include a reference to a ticket when writing a comment
> > or a
> > > TODO, so is the suggestion here to require it for TODOs? Or to add a
> > syntax
> > > for this? If it's the latter, what does the syntax achieve?
> > >
> >
> > The proposal is two fold:
> >
> > A. Make it mandatory to include a JIRA ticket number with the TODO.
> >
> > B. Add a syntax for this and for that we need some consensus. I proposed
> > two options in the initial email:
> > 1. TODO(:MESOS-XXX)
> > 2. TODO(MESOS-XXX)
> >
> > I personally prefer the second option, since the `REPORTER' is already
> > covered as part of the Jira ticket.
> >
> > Kapil
> >
> >
> > > On Wed, Nov 11, 2015 at 4:29 AM, Klaus Ma <klaus1982...@gmail.com>
> > wrote:
> > >
> > > > +1, JIRA will include more discussion and we can close it when it has
> > > been
> > > > improved.
> > > >
> > > > 
> > > > Da (Klaus), Ma (马达) | PMP® | Advisory Software Engineer
> > > > Platform Symphony/DCOS Development & Support, STG, IBM GCG
> > > > +86-10-8245 4084 | klaus1982...@gmail.com | http://k82.me
> > > >
> > > > On Wed, Nov 11, 2015 at 5:11 PM, Alexander Rojas <
> > > alexan...@mesosphere.io>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > This also provides a way of removing TODO’s since they are
> traceable.
> > > If
> > > > > you look in the code, there are TODO’s which are no relevant
> anymore
> > or
> > > > > probably cannot be understood from their actual context.
> > > > >
> > > > > > On 08 Nov 2015, at 05:50, Kapil Arya <ka...@mesosphere.io>
> wrote:
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > I wanted to bring up a style issue related to the TODO tag in
> > > > comments. I
> > > > > > have filed a Jira ticket (
> > > > > https://issues.apache.org/jira/browse/MESOS-3850)
> > > > > > with the following description:
> > > > > >
> > > > > > Currently, we have a TODO() tags to
> > note
> > > > > stuff
> > > > > > has "should be"/"has to be" done in future. While this provides
> us
> > > with
> > > > > > some notion of accounting, it's not enough.
> > > > > >
> > > > > > The author listed in the TODO comment should be considered the
> > > > > "Reporter",
> > > > > > but not necessarily the "Assignee". Further, since the stuff
> > "should
> > > > > > be"/"has to be" done, why not have a Jira issue tracking it?
> > > > > >
> > > > > > We can use TODO(MESOS-XXX) or TODO(:MESOS-XXX) or
> > something
> > > > > > similar. Finally, we might wan to consider adding this to the
> style
> > > > guide
> > > > > > to make it a soft/hard requirement.
> > > > > >
> > > > > >
> > > > > > Are there any opinions/suggestions on this one?
> > > > > >
> > > > > > Best,
> > > > > > Kapil
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: JSON::Protobuf => JSON::protobuf

[Marco Massenzio]

Awesome!

Thanks, Klaus Ma and Michael!

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Sat, Nov 7, 2015 at 10:13 PM, Michael Park <mcyp...@gmail.com> wrote:

> Hello,
>
> This is an announcement that we have changed *JSON::Protobuf* to
> *JSON::protobuf*. Previously, we had a *JSON::Protobuf* class which had an
> implicit conversion operator to *JSON::Object*. We now have
> *JSON::protobuf* which
> is an overloaded function which converts *google::protobuf::Message *to
> *JSON::Object*, and *google::protobuf::RepeatedPtrField* to
> *JSON::Array*
> .
>
> Thanks to *Klaus Ma* for following through with these patches!
>
> MPark.
>

Re: Better error reporting in Mesos

[Marco Massenzio]

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
user-reported failures/errors, when we had to "grep" the codebase for the
error message and find the actual call point that way, as the logs would
not provide a sufficiently clear indication as to *where* the error
actually occurred.

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 seen
elsewhere:

if (errorOccurred) {
  string msg = "Dude, something went wrong!";
  LOG(ERROR) << msg;
  return Error(msg);
}

or a variation thereof.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Fri, Nov 6, 2015 at 4:55 AM, Alexander Rojas <alexan...@mesosphere.io>
wrote:

> 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 Nov 2015, at 09:29, Michael Hopcroft <m...@hopcroft.org> wrote:
> >
> > 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
> > automatically incorporates std::string(strerror(errno)) into its error
> > message.
> >
> >
> > Stout catches exceptions and converts them into Try  and Result
> > objects which are used as polymorphic return values that can express
> either
> > an error condition or a proper return value. One consequence of catching
> > exceptions is that call stacks from throw sites and error sites are lost.
> > This makes it harder to debug production environment crashes post hoc.
> >
> >
> > One way to improve debugability would be to add more information about
> the
> > error site to the error message. This could be done by convention, but it
> > seems that the vast majority of the error messages in Mesos currently
> don’t
> > include much information about the site that originally generated an
> error.
> >
> >
> > Because much of the code in Mesos uses Error and ErrnoError, we have an
> > opportunity to add diagnostic information automatically with only a small
> > amount of churn. What we’d need to do is provide Error creation macros
> that
> > would pass the source file name and line number to the constructors of
> the
> > various Error classes.
> >
> >
> > Concretely this would involve
> >
> >
> >   - class Error
> >  - Rename declaration and definition to ErrorImpl (or ErrorBase).
> This
> >  change is not error prone.
> >  - Rename references to class’ type. These changes are mostly limited
> >  to result.hpp and try.hpp.
> >  - Don’t rename calls to constructor. These will now just invoke the
> >  macro.
> >  - Modify the constructor to take a line number and source filename
> in
> >  addition to a message.
> >  - Define a macro called Error(message) that has the same prototype
> as
> >  the original Error constructor. This macro would invoke
> >  ErrorImpl::ErrorImpl, passing the current line number and source
> filename
> >  along with the user-provided message. The macro would make use
> > of __FILE__
> >  and __LINE__, which are predefined in gcc and Visual Studio.
> >   - class ErrnoError, WindowsError.
> >  - Similar pattern as above.
> >
> > *Pros.*
> >
> >
> >   - Codebase is more debuggable in production environment because the
> vast
> >   majority of error sites will document the file name and line number in
> the
> >   error message.
> >   - Most error sites don’t require a code change.
> >
> > *Cons.*
> >
> >
> >   - Introduces a macro. In general, we’d like to move away from macros
> >   wherever possible.
> >   - Discourages subclassing of Error because each subclass would need its
> >   own special macro to call its constructor. A brief search of the code
> base
> >   seems to indicate that Mesos programmers don’t tend to declare
> subclasses
>

Re: Finish Oversubscription before 0.26.0?

[Marco Massenzio]

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
<https://issues.apache.org/jira/issues/?filter=12333947>, however, reveals
that we've resolved 134 issues (bugs/features/fixes, big and small) in the
last 30 days or so (I took 10/9 as the cutoff date, when we started the
voting process for the 0.25 RC - YMMV).

So, even though there are no "new and exciting" new features, I still think
we've done a pretty good job!

Thanks, everyone, for being awesome.

Random Fact - contrary to what one may think, "project = Mesos and status
was Resolved DURING("2015-10-09", now())" does not do what you think it
should...



--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Fri, Nov 6, 2015 at 7:07 AM, Bernd Mathiske <be...@mesosphere.io> wrote:

> 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 <be...@mesosphere.io> wrote:
>
> 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 <n...@qni.dk> wrote:
>
> Nope - go ahead and close
>
> On Thu, Nov 5, 2015 at 10:24 AM, Jie Yu <j...@twitter.com> wrote:
>
>> I would say the MVP is done. Of course, there'll be some followup
>> improvement to the feature, and all the remaining issues are within that
>> category. I am fine resolving this epic. Any one has any objection?
>>
>> - Jie
>>
>> On Thu, Nov 5, 2015 at 10:18 AM, Bernd Mathiske <be...@mesosphere.io>
>> wrote:
>>
>>> All who worked on MESOS-354,
>>>
>>> What’s the status of the Oversubscription epic? Can we already call it a
>>> feature in 0.26? Shall we wait a few days to finish it? Will it slip into
>>> 0.27?
>>>
>>> I see only 6 unresolved tickets and lots of resolved ones here:
>>>
>>> https://issues.apache.org/jira/browse/MESOS-354
>>>
>>> (Could you please assign someone to this ticket as overall responsible
>>> epic master?)
>>>
>>> Bernd
>>>
>>>
>>
>
>
> --
> Niklas
>
>
>
>

Re: Better error reporting in Mesos

[Marco Massenzio]

On Fri, Nov 6, 2015 at 11:24 AM, Neil Conway <neil.con...@gmail.com> wrote:

> Hi Marco,
>
> On Fri, Nov 6, 2015 at 10:57 AM, Marco Massenzio <ma...@mesosphere.io>
> 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 seen
> > elsewhere:
> >
> > if (errorOccurred) {
> >   string msg = "Dude, something went wrong!";
> >   LOG(ERROR) << msg;
> >   return Error(msg);
> > }
> >
> > or a variation thereof.
>
> I'd like to understand what you see as the advantage of doing this *in
> addition to* adding line number + source file information to the Error
> object itself. i.e., if the Error carries around information about the
> context in which it was constructed, this would seem to avoid the need
> to grep for error strings.
>

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 (again, not sure, this is certainly what we do with loggers
like log4j, etc.).
Having a trail of logs (even with, possibly, incomplete information)
definitely helps in narrowing down the scope of diagnosis of issues in
large clusters, especially when the folks doing the first-level debugging
may not be necessarily familiar with the codebase.


> My concern with the pattern you suggested is that (a) it adds logic at
> every site where we're generating errors,


there is no logic added - you still need to check for errors when returning
the Error() object
all I was suggesting to add was the LOG(ERROR); nothing else.


> and (b) not every place
> where we construct an Error will have enough context about what went
> wrong to be able to report the problem accurately.
>

Absolutely - but it adds another "signal", especially when chasing
not-easy-to-reproduce issues.

Re: Better error reporting in Mesos

[Marco Massenzio]

On Fri, Nov 6, 2015 at 12:54 PM, Neil Conway <neil.con...@gmail.com> wrote:

> On Fri, Nov 6, 2015 at 12:44 PM, Marco Massenzio <ma...@mesosphere.io>
> 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 __LINE__
> just means passing two additional (constant-valued) parameters to a
> function call, so the performance impact should be very modest.
>
>
Excellent, then - in which case, this all SGTM.

Re: New Cloud Foundry Framework - Mesos & CloudFoundry Integration

[Marco Massenzio]

Hey Deepak,

that's really exciting, great stuff!

As Alex correctly pointed out, though, if we understand this correctly,
your work is around a Mesos Framework, is that right?
(what does the framework does?)

If that's the case, it would not be part of the Mesos codebase proper, but
should instead be released independently (ideally, following the Apache 2
license framework) - if that's the case, I'm definitely not an expert, but
there are folks here that would be happy and fully capable to help!

Thanks for doing the work and sharing it: that's awesome.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Thu, Nov 5, 2015 at 12:27 PM, Alex Clemmer <clemmer.alexan...@gmail.com>
wrote:

> The contribution documentation for the Mesos codebase is here:
> http://mesos.apache.org/documentation/latest/submitting-a-patch/
> That said, it is not clear (to me at least) what you mean. It sounds like
> you've written a framework. Is that right? If so, the it seems like it
> might not fit in the scope of the core Mesos code base.
>
> Sent from Outlook
>
> _
> From: Deepak Vij (A) <deepak@huawei.com>
> Sent: Thursday, November 5, 2015 12:04
> Subject: New Cloud Foundry Framework - Mesos & CloudFoundry Integration
> To:  <dev@mesos.apache.org>
>
>
> Hi folks, I just joined the Apache Mesos mailing list. I wanted to reach
> out to the community regarding the new CloudFoundry/Mesos framework we have
> developed in our Santa Clara Lab. We would like to contribute this work to
> the Mesos open source community. I am pretty sure that this contribution
> would be quite valuable for the community. Please let me know the process
> for contributing our work to the community. Thanks.
>
> Regards,
> Deepak K. Vij
> (Telecom Software Strategist, Huawei Software Lab, Santa Clara)
>

Re: Backticks in comments

[Marco Massenzio]

+1

I much favor using backticks everywhere for consistency, since (as you
correctly pointed out) our Doxygen style requires that.
Hopefully, over time, we will have the whole codebase consistent again
(also an invite to folks, if you touch the code, to update comments
accordingly).

BTW - unfortunately, Jira's markdown does not support backticks IIRC, but
{{ }} to demarcate 'fixed font' in paragraphs (and {code} or {noformat}
blocks for code snippets).

(RB uses "generally-accepted" markdown, though, so that's good!)

Thanks for raising awareness about this, Greg!

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Mon, Nov 2, 2015 at 10:38 AM, Alex Clemmer <clemmer.alexan...@gmail.com>
wrote:

> +1. Additional note is that this is now the de facto syntax for code
> snippets on the rest of our tools, too, including RB and JIRA.
>
> On Mon, Nov 2, 2015 at 10:32 AM, Greg Mann <g...@mesosphere.io> 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 quotes are used. This
> doesn't
> > seem to be documented in our style guide (nor in Google's), and I think
> it
> > would be a good idea to establish a policy on this and document it, so
> that
> > we can avoid wasted review cycles related to this in the future.
> >
> > It's likely that the backtick convention began because Doxygen will
> render
> > backtick-enclosed text in monospace, and for this reason I would propose
> > that we consistently use backticks to quote code excerpts and object
> names
> > in comments from now on. What does everyone else think?
> >
> > Cheers,
> > Greg
>
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>

Re: RFC: license headers interfere with doxygen documentation (MESOS-3581)

[Marco Massenzio]

+1
(and thanks for flagging this!)

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Tue, Oct 20, 2015 at 12:14 PM, Joris Van Remoortere <jo...@mesosphere.io>
wrote:

> +1 for (a).
>
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Tue, Oct 20, 2015 at 3:02 PM, Benjamin Mahler <
> benjamin.mah...@gmail.com>
> wrote:
>
> > +1 for (a), in this case the wide sweep only touches the license
> comments,
> > so it won't be disruptive to history.
> >
> > On Tue, Oct 20, 2015 at 11:59 AM, James Peach <jor...@gmail.com> wrote:
> >
> > >
> > > > On Oct 20, 2015, at 8:55 AM, Bernd Mathiske <be...@mesosphere.io>
> > wrote:
> > > >
> > > > All, is changing every source code file prohibitive or not?
> > > >
> > > >> On Oct 20, 2015, at 10:01 AM, Benjamin Bannier <
> > > benjamin.bann...@mesosphere.io> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> I would like to ask for input on how we plan to fix (both short- and
> > > longterm) the interference of the license headers and Doxygen
> > documentation
> > > (https://issues.apache.org/jira/browse/MESOS-3581).
> > > >>
> > > >> Currently, and in line with the respective guidelines, license
> blocks
> > > are wrapped in Javadoc-style comments which are also used for Doxygen
> > > documentation. This leads to Doxygen interpreting license headers as
> > > documentation for whatever entity follows them in the code, and heavily
> > > clutters the generated documentation (see e.g.
> > > http://mesos.apache.org/api/latest/c++/annotated.html). Given that
> > > considerable effort is done to improve the documentation this
> > unfortunate.
> > > >>
> > > >> * * *
> > > >>
> > > >> For a TLDR; of the Jira issue, there are two ways to fix this:
> > > >>
> > > >> (a) change *all* license headers to be wrapped in e.g. `/* .. */`,
> > also
> > > update the coding guidelines, or
> > > >> (b) perform some preprocessor-like magic in the Doxygen layer.
> > > >>
> > > >> Option (a) is very noise but obvious and stable; option (b) OTOH
> > > employs a simple but stupid text replacement under the covers codified
> in
> > > the Doxygen config; it might produce some artifacts and be surprising
> > since
> > > the code Doxygen sees will be different from what is in the source.
> > > >>
> > > >> I personally believe option (a) is superior for purely technical
> > reasons
> > >
> > > +1 for (a); there's no value in showing license headers to doxygen or
> > > tooling workarounds
> > >
> > > >> with option (b) a possible temporary workaround.
> > > >>
> > > >>
> > > >> To make sure that the generated documentation shows actual
> > > documentation content in overviews like
> > > http://mesos.apache.org/api/latest/c++/annotated.html and elsewhere we
> > > should fix this. Please comment in the Jira issue (
> > > https://issues.apache.org/jira/browse/MESOS-3581) your input on how
> you
> > > think this should be fixed (short- and longterm).
> > > >>
> > > >>
> > > >> Cheers,
> > > >>
> > > >> Benjamin
> > > >
> > >
> > >
> >
>

Re: Community Sync Interval

[Marco Massenzio]

Alex - everyone is welcome to join, we usually send an email to this
mailing list a day or two prior to the event with the agenda and a link to
the livestream and the hangout.

I don't think there is "a form" as such (or, if there is one, I don't know
where it is :) ).

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Sun, Oct 18, 2015 at 6:32 PM, Alex Clemmer <clemmer.alexan...@gmail.com>
wrote:

> (Sorry, just out of ignorance: is anyone allowed to come to the
> community sync? I googled around and it looks like the answer is yes,
> but I don't see a living schedule anywhere... If the answer is indeed
> yes, is there a form where I can sign up for the calendar invite?)
>
> On Fri, Oct 16, 2015 at 5:37 PM, Christopher M Luciano
> <cmluci...@us.ibm.com> wrote:
> > +1 weekly
> >
> >  On Oct 16, 2015, 12:38:31 PM, "Marco Massenzio" <ma...@mesosphere.io>
> wrote:
> >  Just to clarify, I'd been assuming rotating times when I gave my +1 for
> >  bi-weekly.
> >  Having said that, I don't feel too strongly about it - the positive
> thing
> >  about weekly meetings is that we can skip one every other for those who
> >  "like it bi-weekly" :) (the other way, instead, not being possible!)
> >  Thanks!
> >  --
> >  *Marco Massenzio*
> >  Distributed Systems Engineer
> >  http://codetrips.com
> >  On Fri, Oct 16, 2015 at 3:35 PM, Diana J Arroyo  wrote:
> >  > +1 for weekly.
> >  >
> >  > Best Regards,
> >  > Diana Arroyo
> >  > darr...@us.ibm.com
> >  >
> >  > [image: Inactive hide details for tommy xiao ---10/16/2015 07:20:13
> >  > AM---+1 for bi-weekly. 2015-10-16 17:36 GMT+08:00 Bernd Mathiske >
> xiao ---10/16/2015 07:20:13 AM---+1 for bi-weekly. 2015-10-16 17:36
> >  > GMT+08:00 Bernd Mathiske :
> >  >
> >  > From: tommy xiao
> >  > To: dev@mesos.apache.org
> >  > Date: 10/16/2015 07:20 AM
> >  > Subject: Re: Community Sync Interval
> >  > --
> >  >
> >  >
> >  >
> >  > +1 for bi-weekly.
> >  >
> >  > 2015-10-16 17:36 GMT+08:00 Bernd Mathiske :
> >  >
> >  > > +1 for bi-weekly and I have been assuming rotating times in the
> first
> >  > > place, as I suspect many others as well.
> >  > >
> >  > > (9am and 3pm are not very far apart. Probably better to go for 8am
> and
> >  > 5pm
> >  > > or something like that.)
> >  > >
> >  > > > On Oct 16, 2015, at 11:08 AM, haosdent  wrote:
> >  > > >
> >  > > > If we rotating times, weekly reasonable. I think 9am and
> 9pm(Pacific)
> >  > OK
> >  > > > for UTC+8.
> >  > > >
> >  > > > +1 weekly, with rotating times. And do we need confirm host
> places?
> >  > > >
> >  > > > On Fri, Oct 16, 2015 at 4:45 PM, Adam Bordelon
> >  > > wrote:
> >  > > >
> >  > > >> Wow, split crowd. Keep in mind that we also want to adjust the
> times
> >  > to
> >  > > >> better accommodate people in different time zones. This could
> mean
> >  > > >> something like 9am, 3pm, 9pm, 3pm (Pacific). If we do one of
> these a
> >  > > week,
> >  > > >> then we end up with bi-weekly 3pm meetings, for those on the west
> >  > coast
> >  > > >> that don't want to wake up early or stay up late. And we can
> still
> >  > > include
> >  > > >> Europe and Asia with the early/late meetings, so they get to
> attend at
> >  > > >> least one a month, hopefully with at least a one committer
> present.
> >  > > >> Nobody's expected to attend every meeting, but those who crave
> weekly
> >  > > >> meetings have a chance.
> >  > > >>
> >  > > >> +1 weekly, with rotating times. Let's decide soon, so we can get
> it on
> >  > > the
> >  > > >> calendar!
> >  > > >>
> >  > > >> On Thu, Oct 15, 2015 at 8:22 PM, Klaus Ma  wrote:
> >  > > >>
> >  > > >>> +1 for weekly
> >  > > >>>
> >  > > >>> Agree with a shorter weekly meeting to sync up, make progress
> step by
> >  > > >> step
> >  > > >>>
> >  > > >>>
> >  > > >>> On 2015年10月16日 10:49, Yong Qiao Wang wrote:

Re: Community Sync Interval

[Marco Massenzio]

+1 bi-weekly

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Thu, Oct 15, 2015 at 7:49 PM, Yong Qiao Wang <yq...@cn.ibm.com> wrote:

> +1 for bi-weekly.
>
> Regards!
>
> Yong Qiao Wang（王勇桥）
>
>
>
> From:   Jojy Varghese <j...@mesosphere.io>
> To: dev@mesos.apache.org
> Date:   16/10/2015 09:01
> Subject:Re: Community Sync Interval
>
>
>
> +1 bi-weekly
>
>
> > On Oct 15, 2015, at 5:42 PM, Isabel Jimenez
> <contact.isabeljime...@gmail.com> wrote:
> >
> > +1 for bi-weekly
> >
> > On Thu, Oct 15, 2015 at 4:18 PM, Alex Rukletsov <a...@mesosphere.com>
> wrote:
> >
> >> +1 for bi-weekly.
> >>
> >> On Fri, Oct 16, 2015 at 12:50 AM, Elizabeth Lingg
> <elizab...@mesosphere.io
> >>>
> >> wrote:
> >>
> >>> +1 Weekly
> >>>
> >>> -Elizabeth
> >>>
> >>> On Thursday, October 15, 2015, Greg Mann <g...@mesosphere.io> wrote:
> >>>
> >>>> I agree with Daniel, +1 for weekly and we can re-evaluate in a bit to
> >> see
> >>>> how people are liking it.
> >>>>
> >>>> On Thu, Oct 15, 2015 at 3:33 PM, Guangya Liu <gyliu...@gmail.com
> >>>> <javascript:;>> wrote:
> >>>>
> >>>>> +1 for bi-weekly
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Guangya
> >>>>>
> >>>>> On Fri, Oct 16, 2015 at 6:08 AM, Daniel Mercer <
> >> dmer...@fantoccini.com
> >>>> <javascript:;>>
> >>>>> wrote:
> >>>>>
> >>>>>> +1 for weekly -- if this results in diminishing returns we can
> >> always
> >>>>> reset
> >>>>>> to biweekly.
> >>>>>>
> >>>>>> On Thu, Oct 15, 2015 at 2:44 PM, Kapil Arya <ka...@mesosphere.io
> >>>> <javascript:;>> wrote:
> >>>>>>
> >>>>>>> +1 for bi-weekly.
> >>>>>>>
> >>>>>>> On Thu, Oct 15, 2015 at 4:40 PM, Jan Schlicht <j...@mesosphere.io
> >>>> <javascript:;>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> +1 for weekly.
> >>>>>>>>
> >>>>>>>> On Thu, Oct 15, 2015 at 1:36 PM, Artem Harutyunyan <
> >>>>>> ar...@mesosphere.io <javascript:;>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> +1 for weekly.
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 15, 2015 at 10:41 AM, haosdent <
> >> haosd...@gmail.com
> >>>> <javascript:;>>
> >>>>>> wrote:
> >>>>>>>>>> +1 for bi-weekly
> >>>>>>>>>>
> >>>>>>>>>> On Fri, Oct 16, 2015 at 1:19 AM, Michael Park <
> >>>> mcyp...@gmail.com <javascript:;>
> >>>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> We discussed whether the community syncs should be weekly
> >> or
> >>>>>>> bi-weekly
> >>>>>>>>>>> (once every 2 weeks).
> >>>>>>>>>>>
> >>>>>>>>>>> There were differing opinions on the subject during the
> >>>>> community
> >>>>>>> sync
> >>>>>>>>>>> today.
> >>>>>>>>>>>
> >>>>>>>>>>> An argument for weekly: meetings can be shorter and
> >> missing
> >>> a
> >>>>>>> meeting
> >>>>>>>>> won't
> >>>>>>>>>>> be as big a deal as missing a longer meeting.
> >>>>>>>>>>>
> >>>>>>>>>>> An argument for bi-weekly: there are many people involved
> >> in
> >>>>> these
> >>>>>>>>>>> meetings, we should keep it infrequent so that it reduces
> >>>>> people's
> >>>>>>>> time
> >>>>>>>>>>> commitments.
> >>>>>>>>>>>
> >>>>>>>>>>> This email is intended to capture your +1s or other ideas
> >>> you
> >>>>>> might
> >>>>>>>>> have!
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> MPark.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Best Regards,
> >>>>>>>>>> Haosdent Huang
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> *Jan Schlicht*
> >>>>>>>> Distributed Systems Engineer, Mesosphere
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
>
>
>

Re: Proposal: moving Mesos website to project codebase

[Marco Massenzio]

@Jonathon: absolutely right, mate, you guys totally blew us away with was 
possible in just one day of coding!

Again congrats on a well-deserved win!



—
Sent from my iPhone, which is not as good as you'd hope to fix trypos n abbrvtn.

On Fri, Oct 9, 2015 at 10:34 PM, Jonathon Rossi <j...@jonorossi.com>
wrote:

> Adam, I wasn't aware of
> https://github.com/mesosphere/mesos-website-container, no none of us tried
> building the site in a docker container, but I'm happy to take a look at
> that at some point soon. That repo doesn't have a LICENSE file, I'd be keen
> to move the Dockerfile into the site directory of the mesos repo so it is
> more discoverable and gets maintained as it is a pretty common use case,
> thoughts?
> Marco, maybe I'm sticking my nose where it doesn't belong, but at the
> beginning of the day both Dave and I independently wanted to work to
> improve the documentation, and with Dave's shepherding we were able to do
> much more than I expected. I don't think any of us expected the level of
> feedback or the number of votes we got to be one of the winning teams.
> On Sat, Oct 10, 2015 at 6:48 AM, Marco Massenzio <ma...@mesosphere.io>
> wrote:
>> For community's sake, it's clear now in hindsight that Dave did not do this
>> because he cared at all about the site - all he was after was his personal
>> glory and the material benefits of a brand new Apple Watch :D
>>
>> Congrats to the team that won the MesosCon Europe Hackathon: well deserved!
>>
>> *Marco Massenzio*
>>
>> *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*
>>
>> On Fri, Oct 9, 2015 at 7:33 PM, Adam Bordelon <a...@mesosphere.io> wrote:
>>
>> > +1 to allowing ReviewBoard/Github to manage website patches.
>> >
>> > It'll require fixing up
>> > https://github.com/mesosphere/mesos-website-container to support the new
>> > git-based model, but it should actually be simpler in the end. Dave, did
>> > anybody try building the website in a Docker container like the
>> > above-mentioned? I really don't want to install ruby/middleman/etc. on my
>> > laptop.
>> >
>> > On Fri, Oct 9, 2015 at 10:50 AM, Kapil Arya <ka...@mesosphere.io> wrote:
>> >
>> > > +1
>> > >
>> > > On Fri, Oct 9, 2015 at 1:02 PM, Niklas Nielsen <nik...@mesosphere.io>
>> > > wrote:
>> > >
>> > > > +1
>> > > >
>> > > > On 9 October 2015 at 09:50, Yan Xu <y...@jxu.me> wrote:
>> > > >
>> > > > > +1 for making it easier for contributors to understand the website
>> > code
>> > > > and
>> > > > > collaboratively maintain it!
>> > > > >
>> > > > > --
>> > > > > Jiang Yan Xu <y...@jxu.me> @xujyan <http://twitter.com/xujyan>
>> > > > >
>> > > > > On Fri, Oct 9, 2015 at 5:21 PM, Paul Brett
>> > <pbr...@twitter.com.invalid
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > +1
>> > > > > >
>> > > > > > On Fri, Oct 9, 2015 at 8:59 AM, haosdent <haosd...@gmail.com>
>> > wrote:
>> > > > > >
>> > > > > > > +1!
>> > > > > > > On Oct 9, 2015 10:37 PM, "Kevin Sweeney" <kevi...@apache.org>
>> > > wrote:
>> > > > > > >
>> > > > > > > > +1!
>> > > > > > > >
>> > > > > > > > On Fri, Oct 9, 2015 at 3:35 PM Marco Massenzio <
>> > > > ma...@mesosphere.io>
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > +1
>> > > > > > > > >
>> > > > > > > > > Dave - great stuff!
>> > > > > > > > >
>> > > > > > > > > *Marco Massenzio*
>> > > > > > > > >
>> > > > > > > > > *Distributed Systems Engineerhttp://codetrips.com <
>> > > > > > > http://codetrips.com
>> > > > > > > > >*
>> > > > > > > > >
>> > > > > > > > > On Fri, Oct 9, 2015 at 3:05 PM, Dave Lester <
>> > > d...@davelester.org
>> > > > >
>> > > > > > > wrote:
>> > > > > > >

Re: apply-reviews.py

[Marco Massenzio]

Depending on how sophisticated one wants to get, we could abstract away common 
behavior in a class and have the scripts use the functionality. 




You know, you can write well-designed OO code in Python too ;-)




Happy to help where I can. 



—
Sent from my iPhone, which is not as good as you'd hope to fix trypos n abbrvtn.

On Fri, Oct 9, 2015 at 11:59 PM, Artem Harutyunyan 
wrote:

> Maybe we can think of stripping verify_reviews.py down and making it
> concentrate just on the verification part and call into
> apply-reviews.py for fetching reviews. Another alternative would be to
> merry the two together (like you're suggesting, and Adam mentioned it
> too at some point).
> I personally would like to keep the two separate, but I curious to see
> what other folks think.
> Cheers,
> Artem.
> On Fri, Oct 9, 2015 at 10:03 AM, Cody Maloney  wrote:
>> Is this going to be combined with the logic to do the same thing in
>> https://github.com/apache/mesos/blob/master/support/verify_reviews.py which
>> is used for the Jenkins Mesos CI? They are doing about the same thing now
>> in "download a whole set of reviews in order". Be nice to just have one.
>>
>> On Thu, Oct 8, 2015 at 1:53 PM Artem Harutyunyan 
>> wrote:
>>
>>> Thanks, Adam! Just created
>>> https://issues.apache.org/jira/browse/MESOS-3625.
>>>
>>> Cheers,
>>> Artem.
>>>
>>> On Thu, Oct 8, 2015 at 1:25 PM, Adam Bordelon  wrote:
>>> > Hi Artem, thanks for your work on improving the commit process.
>>> >
>>> > I have used the '-g' feature for github PRs in the past, and we should
>>> > continue to support that model, so that new Mesos contributors don't have
>>> > to create new RB accounts and learn a new process just for quick
>>> > documentation changes, etc.
>>> >
>>> > As a side note, now that the Myriad incubator project has migrated to
>>> > Apache git and we can no longer merge PRs directly, we were hoping to
>>> take
>>> > advantage of a tool like apply-reviews to apply our PR patches. It looks
>>> > like apply-reviews.sh only specifies 'mesos' in the GITHUB_URL/API_URL.
>>> > Would apply-reviews.py be just as easy to reuse for another project (i.e.
>>> > Myriad)?
>>> >
>>> > On Thu, Oct 8, 2015 at 11:38 AM, Artem Harutyunyan 
>>> > wrote:
>>> >
>>> >> Folks,
>>> >>
>>> >> The current implementation of apply-review.sh does not allow applying
>>> >> a chain of reviews. It has been a major inconvenience for a lot of us,
>>> >> so I have put together a python script that makes it possible to apply
>>> >> a chain of reviews (the corresponding JIRA is at [0]). The version of
>>> >> the script that uses apply-review.sh internally is posted at [1]. A
>>> >> followup review that removes that dependency is available at [2].
>>> >>
>>> >> I would like to invite everyone to try it out and tell me what you
>>> >> think about it. Also, as we discussed during the last community sync,
>>> >> we'd like to retire apply-review.sh, so I was wondering whether anyone
>>> >> is still using that script with github. If so, I will go ahead and add
>>> >> support for '-g' in the new script.
>>> >>
>>> >> Cheers,
>>> >> Artem.
>>> >>
>>> >> [0] - https://issues.apache.org/jira/browse/MESOS-3468
>>> >> [1] - https://reviews.apache.org/r/38705/
>>> >> [2] - https://reviews.apache.org/r/38883/
>>> >>
>>>

Re: Proposal: moving Mesos website to project codebase

[Marco Massenzio]

+1

Dave - great stuff!

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Fri, Oct 9, 2015 at 3:05 PM, Dave Lester <d...@davelester.org> wrote:

> As part of the #MesosCon Europe hackathon, my team has been making
> improvements to the website. Among these changes, we'd like to propose
> changing where the website source files live by moving them to the main
> Mesos codebase. Our current progress / working branch of this is
> available on GitHub: https://github.com/fayusohenson/mesos/tree/site
>
> * What does this mean? *
> We've added a /site directory to the Mesos codebase, which includes the
> website source files. Today, these live in subversion. The rake file and
> other parts of building the website all work in this new environment,
> plus a number of related fixes (image linking, etc).
>
> For committers that are familiar with the current model for pushing the
> site live, this immediate change still requires us `svn commit` the
> /publish directory for the website (static files that are generated).
>
> * Why this change? *
> 1. Today we do not have an easy process for the community to contribute
> to the project website. By merging this with the Mesos codebase, it will
> be significantly easier to send a review or pull request.
> 2. It'll be easier for committers to manage the website, and check that
> documentation changes render on the website properly before committing.
> Because it's difficult to do today, this is often not checked. :(
> 3. It's a solid step toward an automated deployment of the website in
> the future: https://issues.apache.org/jira/browse/MESOS-1309
>
> * Who approves of this change? *
> As the Mesos website maintainer, I feel good about this change and its
> direction for the project. Before committing this change, I'd like
> community support that including this in the main Mesos codebase makes
> sense.
>
> Comments? Questions?
>
> Dave
>

Re: Proposing a deterministic simulation tool for Mesos master and allocator debugging and testing

[Marco Massenzio]

+1

Likewise, I think it's awesome, would love to be involved.

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Mon, Oct 5, 2015 at 10:50 AM, Neil Conway <neil.con...@gmail.com> wrote:

> On Sun, Oct 4, 2015 at 6:14 PM, Maged Michael <maged.mich...@gmail.com>
> wrote:
> > I'd appreciate feedback on a proposal for a simulation tool for debugging
> > and testing the Mesos master and allocator.
>
> Overall, this is awesome! I'd love to see Mesos improve in this area,
> and I'd be happy to help out where I can.
>
> > Simulations would--randomly but deterministically--explore the state
> space
> > of cloud configurations and check for invariant violations and collect
> > stats--in addition to those already in the Mesos master code.
>
> It would be useful to be able to (a) record a "trace" from a running
> (production) Mesos instance (b) replay that trace under the simulator,
> e.g., to explore the impact of changes to Mesos. For example, see
> Section 3.1 of the Borg paper [1].
>
> > * Automated transformation of Mesos source code for integration into the
> > simulator, to allow the simulator to use simulated time instead of real
> > time and to intercept libprocess-based inter-thread and inter-node
> > communication.
>
> Can you elaborate on how you see the source code transformation working?
>
> Because of the way in which Mesos uses processes and message passing,
> you can already control timeouts and inter-process communication in a
> fairly sophisticated way -- for example, see Clock::advance(),
> Clock::settle(), FUTURE_MESSAGE(), DROP_MESSAGE(), etc. Do you think
> it would be possible to implement the simulator in a way that
> leverages (and improves!) the existing facilities in libprocess,
> rather than building new functionality? For example, to control the
> way in which processes and events are interleaved, would it be
> possible to do this by hooking into the libprocess message dispatch
> logic, rather than doing a source code transformation?
>
> > Examples of problems to be detected:
> > * Liveness problems such as deadlock, livelock, starvation
> > * Safety problems such as oversubscription of resources, permanent loss
> of
> > resources or tasks, data corruption in general.
> > * Fairness problems such as sustained imbalance in allocation of
> resources
> > to frameworks.
> > * Performance problems such as high response time, low resource
> utilization.
>
> Validating that the system behaves correctly in the presence of
> network partitions would also be great.
>
> To clarify, it seems like you are primarily focused on finding
> bugs/problems in core Mesos, rather than in Mesos framework
> implementations. The latter would also be a very interesting project
> (e.g., as a framework author, we'd give you a tool that would push
> your scheduler/executor implementation through the entire state space
> of situations the framework would need to handle).
>
> Neil
>
> [1]
> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43438.pdf
>

Re: Problems with deprecation cycles for critical/hard to adapt dependencies

[Marco Massenzio]

Hi Zameer,

thanks for comments - I'd be happy to help the Aurora team upgrade to
support Mesos 0.24+
I'll follow up on the issue you pointed us to.

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Thu, Oct 1, 2015 at 10:29 AM, Zameer Manji <zma...@apache.org> wrote:

> +1 to Timothy's proposal.
>
> Here is a concrete example that can guide the policy. Aurora 0.9.0 was
> released in July 2015 and was built against Mesos 0.22. At the time, I
> don't think anyone was aware that 0.24 would come out in September 2015 and
> break compatibility with with 0.22 w.r.t JSON/Protobuf. This means folks
> who are using Aurora 0.9.0 in production can only upgrade to Mesos 0.23 at
> latest. Now the Aurora project is faced with a problem. Aurora is much
> smaller than the Mesos project and cannot keep up with the Mesos release
> cadence. However if we don't do something right now we will continue to
> prevent our users from upgrading their Mesos installations which may
> contain upgrades that they need. Note that if we do release 0.9.1 with an
> updated Mesos dependency, we might only be able to release against 0.23 so
> we don't break users who are running 0.22 in production.
>
> If anyone has ideas on what we should do here please comment on AURORA-1503
> <https://issues.apache.org/jira/browse/AURORA-1503>.
>
> On Wed, Sep 30, 2015 at 6:35 PM, Timothy Chen <tnac...@gmail.com> wrote:
>
> > I think besides changing to time based, we should provide a lot more
> > visibility of the features that we are starting to deprecate, and I think
> > each release we can also highlight the remaining releases/time each
> feature
> > remaining lifetime so users are reminded on each release the full list
> they
> > should be aware.
> >
> > Tim
> >
> > > On Sep 30, 2015, at 5:17 PM, Niklas Nielsen <nik...@mesosphere.io>
> > wrote:
> > >
> > > @vinod, ben, jie - Any thoughts on this?
> > >
> > > I am in favor of the time based deprecation as well and can come up
> with
> > a
> > > proposal, taken there are no objections.
> > >
> > > Niklas
> > >
> > > On 28 September 2015 at 21:09, James DeFelice <
> james.defel...@gmail.com>
> > > wrote:
> > >
> > >> +1 for time-based deprecation cycle of O(months)
> > >>
> > >>> On Mon, Sep 28, 2015 at 6:16 PM, Zameer Manji <zma...@apache.org>
> > wrote:
> > >>>
> > >>> Niklas,
> > >>>
> > >>> Thanks for starting this thread. I think Mesos can best move forward
> if
> > >> it
> > >>> switches from release based deprecation cycle to a time based
> > deprecation
> > >>> cycle. This means that APIs would be deprecated after a time period
> > (ie 4
> > >>> months) instead of at a specific release. This is the model that
> > Google's
> > >>> Guava library uses and I think it works really well. It ensures that
> > the
> > >>> ecosystem and community has sufficient time to react to deprecations
> > >> while
> > >>> still allowing them to move forward at a reasonable pace.
> > >>>
> > >>> On Mon, Sep 28, 2015 at 2:19 PM, Niklas Nielsen <
> nik...@mesosphere.io>
> > >>> wrote:
> > >>>
> > >>>> Hi everyone,
> > >>>>
> > >>>> With a (targeted) release cadence of *one month*, we should revisit
> > our
> > >>>> deprecation cycles of 3 releases (e.g. in version N, we warn. In
> > >> version
> > >>>> N+1, support both old and new API. In Version N+2, we break
> > >>> compatibility).
> > >>>> Sometimes we cannot do the first step, and we deprecate in version
> N+1
> > >>> and
> > >>>> thus in 2 releases. With the new cadence, that is no longer around
> two
> > >>>> quarters but two months which is too short for 3rd party tooling to
> > >>> adapt.
> > >>>>
> > >>>> Even though our release cycles have been longer than one month in
> the
> > >>> past,
> > >>>> we are running into issues with deprecation due to lack of outreach
> > >> (i.e.
> > >>>> our communication to framework and 3rd party tooling communities) or
> > >>>> because we are simply unaware on the internal dependencies they have
> > on
> > >>>> Mesos.
> > >>>>
> > >>>> We/I became aware of this, when we saw a planned deprecation of
> > >>> /state.json
> > >>>> in 0.26.0 (0.25.0 supports both). I suspect that _a lot_ of tools
> will
> > >>>> break because of this. This, on top of the problems we have run into
> > >>>> recently with the Zookeeper master info change from binary protobuf
> to
> > >>>> json.
> > >>>>
> > >>>> Even though we document this in our upgrade.md, the
> > >> visibility/knowledge
> > >>>> of
> > >>>> this document seem too low and we probably need to do more.
> > >>>>
> > >>>> Do you guys have thoughts/ideas on how we can address this?
> > >>>>
> > >>>> Cheers,
> > >>>> Niklas
> > >>>>
> > >>>> --
> > >>>> Zameer Manji
> > >>
> > >>
> > >>
> > >> --
> > >> James DeFelice
> > >> 585.241.9488 (voice)
> > >> 650.649.6071 (fax)
> > >>
> >
> > --
> > Zameer Manji
> >
> >
>

Fwd: [Breaking Change 0.24 & Upgrade path] ZooKeeper MasterInfo change.

[Marco Massenzio]

Folks:

as a reminder, please be aware that as of Mesos 0.24.0, as announced back
in June, Mesos Master will write its information (`MasterInfo`) to
ZooKeeper in JSON format (see below for details).

If your framework relied on parsing the info (either de-serializing the
Protocol Buffer or just looking for an "IP-like" string) this change will
be a breaking change.

Just to confirm (see also Vinod's comments below) any rolling upgrades
(i.e., clusters with 0.22+0.23 and 0.23+0.24) of Mesos will just work.

This was in conjunction with the HTTP API release and removing the need for
non-C++ developers to have to link with libmesos and have to deal with
Protocol Buffers.

An example of how to access the new format in Python can be found in [0]
and we're happy to help with other languages too.
Any questions, please just ask.

[0] http://github.com/massenz/zk-mesos

Marco Massenzio

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

-- Forwarded message --
From: Vinod Kone <vinodk...@gmail.com>
Date: Wed, Jun 24, 2015 at 4:17 PM
Subject: Re: [Breaking Change 0.24 & Upgrade path] ZooKeeper MasterInfo
change.
To: dev <dev@mesos.apache.org>


Just to clarify, any frameworks that are using the Mesos provided bindings
(aka libmesos.so) should not worry, as long as the version of the bindings
and version of the mesos master are not separated by more than 1 version.
In other words, you should be able to live upgrade a cluster from 0.23.0 to
0.24.0.

For framework schedulers that don't use the bindings (pesos, jesos etc), it
is prudent to add support for JSON formatted ZNODE to their master
detection code.

Thanks,

On Wed, Jun 24, 2015 at 4:10 PM, Marco Massenzio <ma...@mesosphere.io>
wrote:

> Folks,
>
> as heads-up, we are planning to convert the format of the MasterInfo
> information stored in ZooKeeper from the Protocol Buffer binary format to
> JSON - this is in conjunction with the HTTP API development, to allow
> frameworks *not* to depend on libmesos and other binary dependencies to
> interact with Mesos Master nodes.
>
> *NOTE* - there is no change in 0.23 (so any Master/Slave/Framework that is
> currently working in 0.22 *will continue to work* in 0.23 too) but as of
> Mesos 0.24, frameworks and other clients relying on the binary format will
> break.
>
> The details of the design are in this Google Doc:
>
>
https://docs.google.com/document/d/1i2pWJaIjnFYhuR-000NG-AC1rFKKrRh3Wn47Y2G6lRE/edit
>
> the actual work is detailed in MESOS-2340:
> https://issues.apache.org/jira/browse/MESOS-2340
>
> and the patch (and associated test) are here:
> https://reviews.apache.org/r/35571/
> https://reviews.apache.org/r/35815/
>
> *Marco Massenzio*
> *Distributed Systems Engineer*
>

Re: brew install mesos doesn't work for 0.24.0

[Marco Massenzio]

Looks like you may need to update/install XCode on your Mac, perhaps?

$ find / |grep svn_delta
...
/Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.0.dylib
/Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.dylib
/Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.0.dylib
/Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.dylib
...

(this is where my understanding of homebrew ends, I'm afraid)

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Mon, Sep 14, 2015 at 3:52 PM, Vinod Kone <vinodk...@apache.org> wrote:

> I'm trying to update the homebrew formula per the release guide
> <http://mesos.apache.org/documentation/latest/release-guide/>.
>
> But when following instructions from homebrew regarding testing the changes
> <
> https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md#how-to-open-a-homebrew-pull-request-and-get-it-merged
> >
> (all
> I changed was the version of Mesos and the sha) before sending a PR, I get
> the below error. Any ideas?
>
> ➜  twitter git:(vinod/0.24.0) ✗ brew install mesos && brew test mesos
>
> ==> Downloading
> https://www.apache.org/dyn/closer.cgi?path=mesos/0.24.0/mesos-0.24.0.tar.gz
>
> Already downloaded: /Library/Caches/Homebrew/mesos-0.24.0.tar.gz
>
> ==> Downloading
> https://pypi.python.org/packages/source/b/boto/boto-2.36.0.tar.gz
>
> Already downloaded: /Library/Caches/Homebrew/mesos--boto-2.36.0.tar.gz
>
> ==> python -c import setuptools... --no-user-cfg install
> --prefix=/opt/twitter/Cellar/mesos/0.24.0/libexec/boto
> --single-version-externally-managed --record=installed.txt
>
> ==> ./configure --disable-python --prefix=/opt/twitter/Cellar/mesos/0.24.0
> --disable-silent-rules --with-svn=/opt/twitter/opt/subversion
>
> ==> make
>
> ==> make install
>
> ==> ./configure --enable-python --prefix=/opt/twitter/Cellar/mesos/0.24.0
> --disable-silent-rules --with-svn=/opt/twitter/opt/subversion
>
> ==> python -c import setuptools... --no-user-cfg install
> --prefix=/opt/twitter/Cellar/mesos/0.24.0
> --single-version-externally-managed --record=installed.txt
>
> /usr/bin/clang++ -std=c++11 -stdlib=libc++ -DNDEBUG -g -fwrapv -Os -Wall
> -Wstrict-prototypes -Os -w -pipe -march=native -mmacosx-version-min=10.9
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/include
>
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/include/darwin
> -I/opt/twitter/opt/openssl/include -I/opt/twitter/opt/sqlite/include
> -I/opt/twitter/opt/readline/include -isystem/opt/twitter/include
> -F/opt/twitter/Frameworks -arch x86_64 -arch i386 -pipe
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/include
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/include
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/include/mesos
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/src
>
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/src/python/native/src/mesos/native
>
> -I/private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/3rdparty/libprocess/3rdparty/protobuf-2.5.0/src
>
> -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
> -c src/mesos/native/proxy_scheduler.cpp -o
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/proxy_scheduler.o
>
> /usr/bin/clang++ -bundle -undefined dynamic_lookup -arch x86_64 -arch i386
> -Wl,-F. -lsasl2 -lsvn_delta-1 -lsvn_subr-1 -lapr-1 -lcurl -lz -Os -w -pipe
> -march=native -mmacosx-version-min=10.9
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/include
>
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/include/darwin
> -I/opt/twitter/opt/openssl/include -I/opt/twitter/opt/sqlite/include
> -I/opt/twitter/opt/readline/include -isystem/opt/twitter/include
> -F/opt/twitter/Frameworks
>
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/mesos_executor_driver_impl.o
>
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/mesos_scheduler_driver_impl.o
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/module.o
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/proxy_executor.o
> build/temp.macosx-10.9-intel-2.7/src/mesos/native/proxy_scheduler.o
>
> /private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/src/.libs/libmesos_no_3rdparty.a
>
> /private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/3rdparty/libprocess/.libs/libprocess.a
>
> /private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/3rdparty/leveldb/libleveldb.a
>
> /private/tmp/mesos20150914-60557-1cy03t/mesos-0.24.0/3rdparty/zookeeper-3.4.5/src/c/.libs/libzookeeper_mt.a
>
> /private/tmp/mesos20150914-60

Re: brew install mesos doesn't work for 0.24.0

[Marco Massenzio]

Thanks, James.
I don't suppose, then, that simply doing:

LD_LIBRARYPATH=/opt/twitter:$LD_LIBRARYPATH

would solve the issue?


*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Mon, Sep 14, 2015 at 7:44 PM, James Peach <jor...@gmail.com> wrote:

>
> > On Sep 14, 2015, at 4:51 PM, Vinod Kone <vinodk...@gmail.com> wrote:
> >
> > I do fine libsvn_delta libs in my file system
> >
> > ➜  twitter git:(vinod/0.24.0) ✗ sudo find / -name "*svn_delta*"
> >
> > Password:
> >
> > /Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.0.dylib
> >
> > /Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.dylib
> >
> > /Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.0.dylib
> >
> > /Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.dylib
> >
> > /opt/twitter/Cellar/subversion/1.8.13/include/subversion-1/svn_delta.h
> >
> > /opt/twitter/Cellar/subversion/1.8.13/lib/libsvn_delta-1.0.dylib
> >
> > /opt/twitter/Cellar/subversion/1.8.13/lib/libsvn_delta-1.a
> >
> > /opt/twitter/Cellar/subversion/1.8.13/lib/libsvn_delta-1.dylib
> >
> > /opt/twitter/Cellar/subversion/1.8.9/include/subversion-1/svn_delta.h
> >
> > /opt/twitter/Cellar/subversion/1.8.9/lib/libsvn_delta-1.0.dylib
> >
> > /opt/twitter/Cellar/subversion/1.8.9/lib/libsvn_delta-1.a
> >
> > /opt/twitter/Cellar/subversion/1.8.9/lib/libsvn_delta-1.dylib
> >
> > /opt/twitter/lib/libsvn_delta-1.0.dylib
> >
> > /opt/twitter/lib/libsvn_delta-1.a
> >
> > /opt/twitter/lib/libsvn_delta-1.dylib
> >
> > But clang doesn't seem to find them. Also, I expected to see a "-L"
> > pointing to brew's subversion directory (based on configure.ac and
> config
> > params), but I don't?
>
> Homebrew's default is to install into /usr/local which is in the default
> toolchain search path (which is why it is the Homebrew default). There's
> nothing that will find it in /opt/twitter unless Mesos adds a
> --with-subversion autoconf option. Once you are successfully linking
> against the Homebrew version, there is a trap where you can get a mix of
> Homebrew and system svn libraries. I forget the exact path that hits this,
> but you'll know because the tests crash in svn code. The fix is to force
> all the Homebrew stuff to build against the Homebrew svn, not the system
> one (phew!).
>
> >
> > I see some related discussion on MESOS-2448
> > <https://issues.apache.org/jira/browse/MESOS-2448> and the related
> GitHub
> > PR, but the issues seem to have been fixed. cc @TimChen
> >
> >
> >
> > On Mon, Sep 14, 2015 at 4:01 PM, Marco Massenzio <ma...@mesosphere.io>
> > wrote:
> >
> >> Looks like you may need to update/install XCode on your Mac, perhaps?
> >>
> >> $ find / |grep svn_delta
> >> ...
> >>
> /Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.0.dylib
> >> /Applications/Xcode.app/Contents/Developer/usr/lib/libsvn_delta-1.dylib
> >> /Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.0.dylib
> >> /Library/Developer/CommandLineTools/usr/lib/libsvn_delta-1.dylib
> >> ...
> >>
> >> (this is where my understanding of homebrew ends, I'm afraid)
> >>
> >> *Marco Massenzio*
> >>
> >> *Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com
> >*
> >>
> >> On Mon, Sep 14, 2015 at 3:52 PM, Vinod Kone <vinodk...@apache.org>
> wrote:
> >>
> >>> I'm trying to update the homebrew formula per the release guide
> >>> <http://mesos.apache.org/documentation/latest/release-guide/>.
> >>>
> >>> But when following instructions from homebrew regarding testing the
> >> changes
> >>> <
> >>>
> >>
> https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md#how-to-open-a-homebrew-pull-request-and-get-it-merged
> >>>>
> >>> (all
> >>> I changed was the version of Mesos and the sha) before sending a PR, I
> >> get
> >>> the below error. Any ideas?
> >>>
> >>> ➜  twitter git:(vinod/0.24.0) ✗ brew install mesos && brew test mesos
> >>>
> >>> ==> Downloading
> >>>
> >>
> https://www.apache.org/dyn/closer.cgi?path=mesos/0.24.0/mesos-0.24.0.tar.gz
> >>>
> >>> Already downloaded: /Library/Caches/Homebr

Re: Mesos 0.25.0

[Marco Massenzio]

A minor nit...




Please use the "target" version for those you _would like_ to land in 0.25 
(with reasonably high degree of certainty by now ;-) hopefully) and "fix 
version" only when resolved. 


That should make constructing release notes less painstaking. 




Thanks!





—
Sent from my iPhone, which is not as good as you'd hope to fix trypos n abbrvtn.

On Wed, Sep 9, 2015 at 11:59 AM, Niklas Nielsen 
wrote:

> Hi folks,
> With 0.24.0 out the door, we need to start focus on 0.25.0.
> As to planning, we will aim to release by *October 5th (just before
> MesosCon EU)*. In order to test, fix and stabilize, we will try to tag a
> release by *September 23th*. That leaves us with two weeks to land the
> final patches for this release.
> Currently, we have the following issues going into the release:
> https://issues.apache.org/jira/issues/?jql=(fixVersion%20%3D%200.25.0%20OR%20%22Target%20Version%2Fs%22%20%3D%200.25.0)%20AND%20project%20%3D%20MESOS%20ORDER%20BY%20status%20DESC
> With currently 7 unresolved issues.
> Please tag your tickets you want in this release with 0.25.0 target or fix
> version and we will track the progress of the tickets up to the deadlines.
> Let us know if this doesn't make sense or if you have any objections.
> Cheers,
> Joris, Mpark and Niklas
> On 31 August 2015 at 11:34, Niklas Nielsen  wrote:
>>
>>
>> On 30 August 2015 at 16:00, Dave Lester  wrote:
>>
>>> Hi Niklas,
>>>
>>> Could you create a JIRA issue tracking this release? A great example
>>> would be what was created for the 0.22.0 release and promotes more
>>> transparency IMO about what is going in a release:
>>> https://issues.apache.org/jira/browse/MESOS-2248
>>>
>>> Additionally, can you add a link to that JIRA issue on the release
>>> planning wiki?
>>> https://cwiki.apache.org/confluence/pages/editpage.action?pageId=51812502
>>
>>
>> Thanks for bringing this up, Dave!
>>
>> I created a ticket and will track blockers/issues there.
>>
>> Nik
>>
>>
>>>
>>>
>>> Thanks,
>>> Dave
>>>
>>> On Fri, Aug 28, 2015, at 11:24 AM, Joris Van Remoortere wrote:
>>> > Hi Nik,
>>> >
>>> > I'd like to co-manage with you as I am invested in Maintenance
>>> Primitives
>>> > :-)
>>> >
>>> > Joris
>>> >
>>> > On Thu, Aug 27, 2015 at 9:25 PM, Michael Park 
>>> wrote:
>>> >
>>> > > Hey Niklas,
>>> > >
>>> > > As we discussed offline, I'm happy to co-manage or shadow this
>>> release.
>>> > >
>>> > > I would also like to add the beta follow-up features for persistence
>>> > > primitives (dynamic reservation + persistent volume):
>>> > >
>>> > >- Operator API
>>> > >- Authorization
>>> > >
>>> > > Thanks,
>>> > >
>>> > > MPark.
>>> > >
>>> > > On Thu, Aug 27, 2015 at 7:24 PM Niklas Nielsen 
>>> > > wrote:
>>> > >
>>> > > > Hi folks,
>>> > > >
>>> > > > While we have 0.24.0 in flight (voting and fixing is in progress),
>>> with a
>>> > > > release cadence of 1 month, we should consider to start thinking
>>> about
>>> > > > 0.25.0.
>>> > > >
>>> > > > I have cycles to release manage this one (and bring some of the
>>> newer
>>> > > > committers on for shadowing). If others want to take this on (or if
>>> > > people
>>> > > > have objections), feel free to jump in.
>>> > > >
>>> > > > Of larger items for the next release, we want to get (again, feel
>>> free to
>>> > > > add) are:
>>> > > >
>>> > > >  - Maintenance primitives in Alpha state
>>> > > >  - Networking plug-ability (demoed at MesosCon)
>>> > > >
>>> > > > We can wait until 0.24.0 lands, but we should be able to work on
>>> this in
>>> > > > parallel.
>>> > > >
>>> > > > Niklas
>>> > > >
>>> > >
>>>
>>
>>

Re: Mesos Style Guideline Adjustments

[Marco Massenzio]

+1




Thanks, Michael!



—
Sent from my iPhone, which is not as good as you'd hope to fix trypos n abbrvtn.

On Wed, Sep 9, 2015 at 6:23 PM, Michael Park <mcyp...@gmail.com> wrote:

> I've removed the 70 column restriction on comments from the style guide:
> https://github.com/apache/mesos/commit/f9c2604ea97b91f8a9ec3b2863317761679b1c86
> Also, based on the comments, it seems like we should allow 80 column
> comments but omit the sweeping change.
> Thanks,
> MPark.
> On Wed, Aug 12, 2015 at 6:13 PM Marco Massenzio <ma...@mesosphere.io> wrote:
>> On Wed, Aug 12, 2015 at 4:09 AM, Bernd Mathiske <be...@mesosphere.io>
>> wrote:
>>
>> > Like BenM,
>> >
>> > +1 on allowing 80 column comments
>> >
>> +1
>> (it really IS annoying having to keep an eye on the bottom column counter
>> when typing comments :)
>>
>>
>> > -1 on sweeping changes; incremental changes when touching old comments
>> > will do IMHO
>> >
>> > +1 on the -1? :)
>> Incremental changes are good and I doubt anyone will be "confused" by them.
>>
>>
>> > Bernd
>> >
>> > > On Aug 12, 2015, at 12:51 AM, Michael Park <mcyp...@gmail.com> wrote:
>> > >
>> > > Ben, thanks for your input!
>> > >
>> > > Another update on this topic: the patches around break before braces
>> for
>> > > *enum* style and overloaded operators have been committed.
>> > >
>> > > On Tue, Aug 11, 2015 at 6:23 PM Benjamin Mahler <
>> > benjamin.mah...@gmail.com>
>> > > wrote:
>> > >
>> > >> We already don't necessarily wrap at 70 characters (often we wrap
>> > before 70
>> > >> to reduce "jaggedness" or to make it look cleaner).
>> > >>
>> > >> So with the change to 80, this still makes all existing comments
>> valid.
>> > We
>> > >> can still encourage folks to write paragraphs in a way that is easy to
>> > >> digest for the reader. That is, I think we should still be trying not
>> to
>> > >> write jagged paragraphs of comments, it's just not a hard stylistic
>> > >> violation given we don't have an algorithm for this.
>> > >>
>> > >> So +1 to relaxing the hard 70 character rule, but -1 to sweeping
>> across
>> > all
>> > >> the comments or doing wrapping based only on line length rather than
>> > >> jaggedness going forward.
>> > >>
>> > >> On Sat, Aug 8, 2015 at 3:25 PM, Joris Van Remoortere <
>> > jo...@mesosphere.io>
>> > >> wrote:
>> > >>
>> > >>> I will volunteer to update all the comments to wrap at 80 if we agree
>> > to
>> > >>> keep the code base consistent.
>> > >>> Naturally that is also my vote ;-)
>> > >>> Joris
>> > >>>
>> > >>>> On Aug 8, 2015, at 1:40 PM, Michael Park <mcyp...@gmail.com> wrote:
>> > >>>>
>> > >>>> An update on this topic since we covered it at the community
>> developer
>> > >>> sync.
>> > >>>>
>> > >>>>  1. We will adopt *Mozilla*'s *BreakBeforeBraces* style as their
>> style
>> > >>> is
>> > >>>>  equivalent to ours. The only change this entails for our codebase
>> is
>> > >> to
>> > >>>>  consistently wrap the braces for *enum* definitions, as we're
>> > >> currently
>> > >>>>  inconsistent. I've taken on the work involved in this change:
>> > >>>> - stout: https://reviews.apache.org/r/37258
>> > >>>> - libprocess: https://reviews.apache.org/r/37259
>> > >>>> - mesos: https://reviews.apache.org/r/37260
>> > >>>> 2. We will drop the rule for adding spaces around overloaded
>> > >>>>  operators. We'll simply do a sweep of the codebase to update all of
>> > >>> them
>> > >>>>  consistently. Artem has kindly taken action on this already:
>> > >>>> - stout: https://reviews.apache.org/r/37018/
>> > >>>> - libprocess: https://reviews.apache.org/r/37017/
>> > >>>> - mesos: https://reviews.apache.org/r/37013/
>> > >>>> 3. We will drop the rule for wrapping comments at 70 characters.
>>

Re: [VOTE] Release Apache Mesos 0.24.0 (rc2)

[Marco Massenzio]

+1 (non-binding)

All tests (including ROOT) pass on Ubuntu 14.04
All tests pass on CentOS 7.1; ROOT tests cause 1 failure:

[  FAILED  ] 1 test, listed below:
[  FAILED  ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseRSS

$ cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)

This seems to be new[0], but possibly related to some limitation/setting of
my test machine (VirtualBox VM, running 2 CPUs on Ubuntu host).
Interestingly enough, I don't see the 4 failures as Vaibhav, but in my log
it shows *YOU HAVE 11 DISABLED TESTS* (he has 12).

[0] https://issues.apache.org/jira/issues/?filter=12333150

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Tue, Sep 1, 2015 at 5:45 PM, Vinod Kone <vinodk...@apache.org> wrote:

> Hi all,
>
>
> Please vote on releasing the following candidate as Apache Mesos 0.24.0.
>
>
> 0.24.0 includes the following:
>
>
> 
>
> Experimental support for v1 scheduler HTTP API!
>
> This release also wraps up support for fetcher.
>
> The CHANGELOG for the release is available at:
>
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.0-rc2
>
>
> 
>
>
> The candidate for Mesos 0.24.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc2/mesos-0.24.0.tar.gz
>
>
> The tag to be voted on is 0.24.0-rc2:
>
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.0-rc2
>
>
> The MD5 checksum of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc2/mesos-0.24.0.tar.gz.md5
>
>
> The signature of the tarball can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc2/mesos-0.24.0.tar.gz.asc
>
>
> The PGP key used to sign the release is here:
>
> https://dist.apache.org/repos/dist/release/mesos/KEYS
>
>
> The JAR is up in Maven in a staging repository here:
>
> https://repository.apache.org/content/repositories/orgapachemesos-1066
>
>
> Please vote on releasing this package as Apache Mesos 0.24.0!
>
>
> The vote is open until Fri Sep  4 17:33:05 PDT 2015 and passes if a
> majority of at least 3 +1 PMC votes are cast.
>
>
> [ ] +1 Release this package as Apache Mesos 0.24.0
>
> [ ] -1 Do not release this package because ...
>
>
> Thanks,
>
> Vinod
>

Re: Prepping for next release

[Marco Massenzio]

Uhm, that's a tricky one...
Considering that JDK6 was EOL'd in 2011[0] and even JDK7 is now officially
out of support from Oracle, I don't think this should be a major issue?

I'm also assuming that, if anyone really needs to use JDK6 they can build
from source, by simply running `mvn package` and replace the JAR?
(not terribly familiar with our build process, so no idea if that would
work at all).

[0] http://www.oracle.com/technetwork/java/eol-135779.html

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com <http://codetrips.com>*

On Tue, Sep 1, 2015 at 4:46 PM, Vinod Kone <vinodk...@apache.org> wrote:

> +user
>
> So looks like this issue is related to JDK6 and not my maven password
> settings.
>
> Related ASF ticket: https://issues.apache.org/jira/browse/BUILDS-85
>
> The reason it worked for me, when I tagged RC1, was because I also pointed
> my maven to use JDK7.
>
> So we have couple options here:
>
> #1) (Easy) Do same thing with RC2 as we did for RC1. This does mean the
> artifacts we upload to nexus will be compiled with JDK7. IIUC, if any JVM
> based frameworks are still on JDK6 they can't link in the new artifacts?
>
> #2) (Harder) As mentioned in the ticket, have maven compile Mesos jar with
> JDK6 but use JDK7 when uploading. Not sure how easy it is to adapt our
> Mesos build tool chain for this. Anyone has expertise in this area?
>
> Thoughts?
>
>
> On Tue, Aug 18, 2015 at 3:14 PM, Vinod Kone <vinodk...@apache.org> wrote:
>
> > I re-encrypted the maven passwords and that seemed to have done the
> trick.
> > Thanks Adam!
> >
> > On Tue, Aug 18, 2015 at 1:59 PM, Adam Bordelon <a...@mesosphere.io>
> wrote:
> >
> >> Update your ~/.m2/settings.xml?
> >> Also check that the output of `gpg --list-keys` and `--list-sigs`
> matches
> >> the keypair you expect
> >>
> >> On Tue, Aug 18, 2015 at 1:48 PM, Vinod Kone <vinodk...@apache.org>
> wrote:
> >>
> >> > I definitely had to create a new gpg key because my previous one
> >> expired! I
> >> > uploaded them id.apache and our SVN repo containing KEYS.
> >> >
> >> > Do I need to do anything specific for maven?
> >> >
> >> > On Tue, Aug 18, 2015 at 1:25 PM, Adam Bordelon <a...@mesosphere.io>
> >> wrote:
> >> >
> >> > > Haven't seen that one. Are you sure you've got your gpg key properly
> >> set
> >> > up
> >> > > with Maven?
> >> > >
> >> > > On Tue, Aug 18, 2015 at 1:13 PM, Vinod Kone <vinodk...@apache.org>
> >> > wrote:
> >> > >
> >> > > > I'm getting the following error when running ./support/tag.sh. Has
> >> any
> >> > of
> >> > > > the recent release managers seen this one before?
> >> > > >
> >> > > > [ERROR] Failed to execute goal
> >> > > > org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
> >> > (default-deploy)
> >> > > on
> >> > > > project mesos: Failed to deploy artifacts: Could not transfer
> >> artifact
> >> > > > org.apache.mesos:mesos:jar:0.24.0-rc1 from/to
> apache.releases.https
> >> (
> >> > > > https://repository.apache.org/service/local/staging/deploy/maven2
> ):
> >> > > > java.lang.RuntimeException: Could not generate DH keypair: Prime
> >> size
> >> > > must
> >> > > > be multiple of 64, and can only range from 512 to 1024 (inclusive)
> >> ->
> >> > > [Help
> >> > > > 1]
> >> > > >
> >> > > > On Mon, Aug 17, 2015 at 11:23 AM, Vinod Kone <
> vinodk...@apache.org>
> >> > > wrote:
> >> > > >
> >> > > > > Update:
> >> > > > >
> >> > > > > There are 3 outstanding tickets (all related to flaky tests),
> >> that we
> >> > > are
> >> > > > > trying to resolve. Any help fixing those (esp. MESOS-3050
> >> > > > > <https://issues.apache.org/jira/browse/MESOS-3050>) would be
> >> > > > appreciated!
> >> > > > >
> >> > > > > Planning to cut an RC as soon as they are fixed (assuming no new
> >> ones
> >> > > > crop
> >> > > > > up).
> >> > > > >
> >> > > > > Thanks,
> >> > > > >
> >> > > > &g

Re: How to enable logs when running UT cases

[Marco Massenzio]

Use ./bin/mesos-test.sh --verbose



—
Sent from Mailbox

On Mon, Aug 31, 2015 at 10:07 PM, Klaus Ma  wrote:

> Hi team,
> I’m working on MESOS-3070 (Master CHECK failure if a framework uses 
> duplicated task id); the fix was passed in Ubuntu 14.04 but failed at Mac OS, 
> so is there any parameter to enable logs when run UT cases? So I can check 
> what happened in Mac OS.
> I export MESOS_VERBOSE, but it seems not work :(.
> Regards,
> 
> Klaus Ma (马达), PMP®  | http://www.cguru.net

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

[Marco Massenzio]

+1 (non-binding)

All tests (including ROOT) pass on:
Ubuntu 14.04 (physical box)

All non-ROOT tests pass on:
CentOS 7 (VirtualBox VM)

Known issue (MESOS-3050) for ROOT tests on CentOS 7, non-blocker.

Thanks,

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com http://codetrips.com*

On Tue, Aug 18, 2015 at 3:26 PM, Vinod Kone vinodk...@apache.org wrote:

 0.24.0 includes the following:


 

 Experimental support for v1 scheduler HTTP API!

 This release also wraps up support for fetcher.


 The CHANGELOG for the release is available at:


 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.24.0-rc1


 


 The candidate for Mesos 0.24.0 release is available at:

 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz


 The tag to be voted on is 0.24.0-rc1:

 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.24.0-rc1


 The MD5 checksum of the tarball can be found at:


 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz.md5


 The signature of the tarball can be found at:


 https://dist.apache.org/repos/dist/dev/mesos/0.24.0-rc1/mesos-0.24.0.tar.gz.asc


 The PGP key used to sign the release is here:

 https://dist.apache.org/repos/dist/release/mesos/KEYS


 The JAR is up in Maven in a staging repository here:

 https://repository.apache.org/content/repositories/orgapachemesos-1064


 Please vote on releasing this package as Apache Mesos 0.24.0!


 The vote is open until Fri Aug 21 15:24:05 PDT 2015 and passes if a
 majority of at least 3 +1 PMC votes are cast.


 [ ] +1 Release this package as Apache Mesos 0.24.0

 [ ] -1 Do not release this package because ...


 Thanks,

 Vinod

Re: Lets stop using the CHECK macro in the test harness.

[Marco Massenzio]

+1

*Marco Massenzio*

*Distributed Systems Engineerhttp://codetrips.com http://codetrips.com*

On Fri, Aug 14, 2015 at 3:46 PM, Paul Brett pbr...@twitter.com.invalid
wrote:

 We are currently using the Google log CHECK macros (CHECK_SOME,
 CHECK_NOTNULL etc) in the test harness, usually to verify test setup.  When
 these checks fail, it causes the test harness to abort rather than simply
 move onto the next test. The abort prevents any subsequent tests from
 running, hiding errors and preventing the generation of the XML test
 report.

 I would like to propose that we eliminate the use of CHECK in the test
 harness and replace it with the appropriate Google test macros to fail the
 test case.
 ​  I​
  am not proposing that we change the use of CHECK outside the test harness
 (although CHECK calls in master and slave can also kill the test harness).

 For void functions, CHECK can
 ​ easily​
 be replaced with the corresponding ASSERT equivalent.

 For non-void function, ASSERT cannot be used because it does not return the
 correct data type and hence we need to use a combination of ADD_FAILURE()
 and return.

 For example:

 CHECK(foo)

 would become:

 if(!foo) {
 ADD_FAILURE();
 return anything;
 }

 If there is general agreement, I will raise tickets to update the Mesos
 testing patterns document and each of the test cases.

 ​Thanks
 ​

 -- Paul Brett

Re: Re-opening an issue (aka - Un-Resolving it)

[Marco Massenzio]

Progress!

Gavin fixed this for us and I've verified that it works - so, now
re-opening a Resolved issue, will put it back into a valid Resolution:
Unresolved, and it will correctly show up in the My Open Issues query.

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Aug 6, 2015 at 2:06 PM, Marco Massenzio ma...@mesosphere.io wrote:

 https://issues.apache.org/jira/browse/INFRA-10086
 (apparently, I'm not allowed to add Watchers on an INFRA ticket... weird!)

 *Marco Massenzio*
 *Distributed Systems Engineer*

 On Thu, Aug 6, 2015 at 2:00 PM, Marco Massenzio ma...@mesosphere.io
 wrote:


 On Wed, Aug 5, 2015 at 11:55 AM, Vinod Kone vinodk...@gmail.com wrote:

 Ah. That's confusing.

 It gets even more confusing

 ... even doing this, the outcome is unsatisfactory - apparently Jira
 has two classes of Unresolved Resolution - the one where the issue
 never was Resolved, and the one which is attained when following my
 suggested hack.
 So, if you hit the My Open Issues[0] query, you *still* don't get those
 issues, and they still show up struck through.

 If you use a hand-crafted query[1] you can see, if you add the Resolution
 column, that they all show Unresolved but the genuine ones have it in
 italic, the others in plain text: so I'm assuming Jira behind the scenes
 uses a different metadata set than it appears externally.

 [0] JQL: `assignee = currentUser() AND resolution = Unresolved ORDER BY
 updatedDate DESC`
 [1] JQL: `assignee = currentUser() AND status in (Accepted, Reviewable,
 Open, In Progress)`


 Is there no way we can fix the schema to not do this?
 I'm assuming you already asked INFRA?

 I haven't and I don't know.  I don't really think it has anything to do
 with our schema: this happened to me before at other places, both with
 on-prem and on-demand Jira.
 I'll file a ticket and see what they say, though.

 On a side note, is it possible to make the Shepherd field mandatory when
 a task transitions from Accepted -- Assigned? I think this will force
 users to find shepherds before they start working on an issue. Will also
 help shepherds guide what issues we want new contributors to focus on.


 I would suggest filing a ticket with INFRA (I don't know and don't have
 the necessary perms to try it out, unfortunately); we must be very clear
 that this should only apply to a *transition* (and I presume, you meant:
 Accepted -- In Progress) otherwise our backlog grooming (Open to
 Accepted) becomes too laborious.



 On Wed, Aug 5, 2015 at 11:34 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Dear all:
 
  When re-opening an issue (for whatever reason) moving it from its
 Resolved
  state (to either Open or In progress) Jira will *not* update the
  Resolution field back to Unresolved.
 
  This means that (a) you now have a confusing Open but Resolution:
 Fixed
  issue and (b) the issue link/display (eg, MESOS-1234) will appear with
 a
  misleading strike-through in Sprint and Kanban Boards.
 
  The solution is rather simple, albeit fiendishly unintuitive:
 
  1) Resolve (again) the issue;
  2) in the resolve dialog that pops up, choose Unresolved for its
  Resolution field;
  3) move it back to whatever state makes sense (Open, In Progress, etc.)
 
  Hope this helps!
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 

Re: Subscribe as Mesos contributor

[Marco Massenzio]

Hi YongQiao,

I've added you to the Contributors list, welcome to Apache Mesos!

Please make sure to sign up to Apache ReviewBoard too.

Looking forward to your contributions!

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Aug 6, 2015 at 11:19 PM, YongQiao Wang jamesyongq...@gmail.com
wrote:

 Hi,

 I want to contribute to Mesos, could you help to add me to the list of
 Mesos “contributors”?

 My JIRA account name is : JamesYongQiaoWang and mail is
 jamesyongq...@gmail.com

 Thanks!

Re: Re-opening an issue (aka - Un-Resolving it)

[Marco Massenzio]

On Wed, Aug 5, 2015 at 11:55 AM, Vinod Kone vinodk...@gmail.com wrote:

 Ah. That's confusing.

It gets even more confusing

... even doing this, the outcome is unsatisfactory - apparently Jira has
two classes of Unresolved Resolution - the one where the issue never
was Resolved, and the one which is attained when following my suggested
hack.
So, if you hit the My Open Issues[0] query, you *still* don't get those
issues, and they still show up struck through.

If you use a hand-crafted query[1] you can see, if you add the Resolution
column, that they all show Unresolved but the genuine ones have it in
italic, the others in plain text: so I'm assuming Jira behind the scenes
uses a different metadata set than it appears externally.

[0] JQL: `assignee = currentUser() AND resolution = Unresolved ORDER BY
updatedDate DESC`
[1] JQL: `assignee = currentUser() AND status in (Accepted, Reviewable,
Open, In Progress)`


 Is there no way we can fix the schema to not do this?
 I'm assuming you already asked INFRA?

 I haven't and I don't know.  I don't really think it has anything to do
with our schema: this happened to me before at other places, both with
on-prem and on-demand Jira.
I'll file a ticket and see what they say, though.

On a side note, is it possible to make the Shepherd field mandatory when
 a task transitions from Accepted -- Assigned? I think this will force
 users to find shepherds before they start working on an issue. Will also
 help shepherds guide what issues we want new contributors to focus on.


I would suggest filing a ticket with INFRA (I don't know and don't have the
necessary perms to try it out, unfortunately); we must be very clear that
this should only apply to a *transition* (and I presume, you meant:
Accepted -- In Progress) otherwise our backlog grooming (Open to
Accepted) becomes too laborious.



 On Wed, Aug 5, 2015 at 11:34 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Dear all:
 
  When re-opening an issue (for whatever reason) moving it from its
 Resolved
  state (to either Open or In progress) Jira will *not* update the
  Resolution field back to Unresolved.
 
  This means that (a) you now have a confusing Open but Resolution: Fixed
  issue and (b) the issue link/display (eg, MESOS-1234) will appear with a
  misleading strike-through in Sprint and Kanban Boards.
 
  The solution is rather simple, albeit fiendishly unintuitive:
 
  1) Resolve (again) the issue;
  2) in the resolve dialog that pops up, choose Unresolved for its
  Resolution field;
  3) move it back to whatever state makes sense (Open, In Progress, etc.)
 
  Hope this helps!
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 

Re: Re-opening an issue (aka - Un-Resolving it)

[Marco Massenzio]

https://issues.apache.org/jira/browse/INFRA-10086
(apparently, I'm not allowed to add Watchers on an INFRA ticket... weird!)

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Aug 6, 2015 at 2:00 PM, Marco Massenzio ma...@mesosphere.io wrote:


 On Wed, Aug 5, 2015 at 11:55 AM, Vinod Kone vinodk...@gmail.com wrote:

 Ah. That's confusing.

 It gets even more confusing

 ... even doing this, the outcome is unsatisfactory - apparently Jira has
 two classes of Unresolved Resolution - the one where the issue never
 was Resolved, and the one which is attained when following my suggested
 hack.
 So, if you hit the My Open Issues[0] query, you *still* don't get those
 issues, and they still show up struck through.

 If you use a hand-crafted query[1] you can see, if you add the Resolution
 column, that they all show Unresolved but the genuine ones have it in
 italic, the others in plain text: so I'm assuming Jira behind the scenes
 uses a different metadata set than it appears externally.

 [0] JQL: `assignee = currentUser() AND resolution = Unresolved ORDER BY
 updatedDate DESC`
 [1] JQL: `assignee = currentUser() AND status in (Accepted, Reviewable,
 Open, In Progress)`


 Is there no way we can fix the schema to not do this?
 I'm assuming you already asked INFRA?

 I haven't and I don't know.  I don't really think it has anything to do
 with our schema: this happened to me before at other places, both with
 on-prem and on-demand Jira.
 I'll file a ticket and see what they say, though.

 On a side note, is it possible to make the Shepherd field mandatory when
 a task transitions from Accepted -- Assigned? I think this will force
 users to find shepherds before they start working on an issue. Will also
 help shepherds guide what issues we want new contributors to focus on.


 I would suggest filing a ticket with INFRA (I don't know and don't have
 the necessary perms to try it out, unfortunately); we must be very clear
 that this should only apply to a *transition* (and I presume, you meant:
 Accepted -- In Progress) otherwise our backlog grooming (Open to
 Accepted) becomes too laborious.



 On Wed, Aug 5, 2015 at 11:34 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Dear all:
 
  When re-opening an issue (for whatever reason) moving it from its
 Resolved
  state (to either Open or In progress) Jira will *not* update the
  Resolution field back to Unresolved.
 
  This means that (a) you now have a confusing Open but Resolution:
 Fixed
  issue and (b) the issue link/display (eg, MESOS-1234) will appear with a
  misleading strike-through in Sprint and Kanban Boards.
 
  The solution is rather simple, albeit fiendishly unintuitive:
 
  1) Resolve (again) the issue;
  2) in the resolve dialog that pops up, choose Unresolved for its
  Resolution field;
  3) move it back to whatever state makes sense (Open, In Progress, etc.)
 
  Hope this helps!
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 

Re: Request to adding me to contributors list

[Marco Massenzio]

Hi Qian,

I've added you to the 'Contributors' group, welcome to Apache Mesos!

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Aug 6, 2015 at 6:34 AM, Qian AZ Zhang zhang...@cn.ibm.com wrote:

 Thanks!


 Regards,
 *Qian Zhang （张乾）*
 Developer, IBM Platform Computing
 --
 *Phone:* 86-29-68797144 | *Tie-Line:* 87144
 * E-mail:* *zhang...@cn.ibm.com* zhang...@cn.ibm.com
 * Chat:* zhq527725

 *“An educated man should know everything about something and something
 about everything*
 [image: IBM]

 陕西省西安市高新区
 高新六路42号中清大厦3层
 Xian, Shaanxi Province 710075
 China

Re-opening an issue (aka - Un-Resolving it)

[Marco Massenzio]

Dear all:

When re-opening an issue (for whatever reason) moving it from its Resolved
state (to either Open or In progress) Jira will *not* update the
Resolution field back to Unresolved.

This means that (a) you now have a confusing Open but Resolution: Fixed
issue and (b) the issue link/display (eg, MESOS-1234) will appear with a
misleading strike-through in Sprint and Kanban Boards.

The solution is rather simple, albeit fiendishly unintuitive:

1) Resolve (again) the issue;
2) in the resolve dialog that pops up, choose Unresolved for its
Resolution field;
3) move it back to whatever state makes sense (Open, In Progress, etc.)

Hope this helps!

*Marco Massenzio*
*Distributed Systems Engineer*

Re: Can't re-open issue?

[Marco Massenzio]

Please don't re-open issues (unless for the very specific case in which a
patch gets committed and then turns out to either be insufficient to meet
requirements and/or buggy).

It's much better to instead create a new one and reference the original one
(you can even Link to it, or just reference it in the comment).

(there's also a peculiar Jira issue in which the Resolved state doesn't
get cleared once one moves it back in open or in progress and the issue
continues to appear struck out in lists, sprints, backlog, etc. confusing
the obsessives like me :)).

Thanks!

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jul 29, 2015 at 8:30 AM, James DeFelice james.defel...@gmail.com
wrote:

 Yep I was logged in

 On Wed, Jul 29, 2015 at 11:21 AM, Alex Rukletsov a...@mesosphere.com
 wrote:

  That's weird, because AFAIK I'm a regular contributor without any
 elevated
  rights.
 
  Just to make sure and exclude this option: were you logged in?
 
  On Wed, Jul 29, 2015 at 5:06 PM, James DeFelice 
 james.defel...@gmail.com
  wrote:
 
   Thanks. I probably don't have ops. How do I get them?
  
   On Wed, Jul 29, 2015 at 10:57 AM, Alex Rukletsov a...@mesosphere.com
   wrote:
  
It looks like it worked for me: I was able to re-open it.
   
On Wed, Jul 29, 2015 at 4:51 PM, James DeFelice 
   james.defel...@gmail.com
wrote:
   
 I'd like to re-open
 https://issues.apache.org/jira/browse/MESOS-349
   for
 discussion. I have a very specific use case in mind that the file
   system
 isolator will not solve for me.

 JIRA won't let me re-open this -- possibly related to the recent
   workflow
 changes?

   
  
  
  
   --
   James DeFelice
   585.241.9488 (voice)
   650.649.6071 (fax)
  
 



 --
 James DeFelice
 585.241.9488 (voice)
 650.649.6071 (fax)

Re: Request to adding me to a contributors list

[Marco Massenzio]

Hi Jihun,

I've added you to the contributors list, welcome to Mesos!
(and thanks for working on those issues).

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 23, 2015 at 8:37 PM, Jihun Kang ykr...@gmail.com wrote:

 Hello,

 I recently created and worked on jira issues, MESOS-2216, MESOS-3084, and
 MESOS-3085.
 And I would liked to assign myself on these issues.
 Could anyone add me to a contributors list?

 Thanks and best regards,
 Jihun.

Re: [RESULT] [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Marco Massenzio]

Great news, indeed!

Thanks, Adam, for all the hard work in driving this release to fruition,
you're a star!

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jul 22, 2015 at 9:29 PM, Adam Bordelon a...@mesosphere.io wrote:

 Good news, everyone!

 The vote for Mesos 0.23.0 (rc4) has passed with the following votes.

 +1 (Binding)
 --
 *** Vinod Kone
 *** Adam B
 *** Benjamin Hindman
 *** Timothy Chen

 +1 (Non-binding)
 --
 *** Vaibhav Khanduja
 *** Marco Massenzio

 There were no 0 or -1 votes.

 Known issue: `sudo make check` may fail on some OSes. These tests have
 been fixed in 0.24.0 without any changes to the rest of the code.

 Please find the release at:
 https://dist.apache.org/repos/dist/release/mesos/0.23.0

 It is recommended to use a mirror to download the release:
 http://www.apache.org/dyn/closer.cgi

 The CHANGELOG for the release is available at:

 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0

 The mesos-0.23.0.jar has been released to:
 https://repository.apache.org

 The website (http://mesos.apache.org) will be updated shortly to reflect
 this release.

 Thanks,
 -Adam-



 On Wed, Jul 22, 2015 at 1:20 PM, Timothy Chen tnac...@gmail.com wrote:

 +1

 The docker bridge network test failed because some iptable rules that was
 set on the environment. I will comment on the JIRA but not a blocker.

 Tim


  On Jul 22, 2015, at 1:07 PM, Benjamin Hindman 
 benjamin.hind...@gmail.com wrote:
 
  +1 (binding)
 
  On Ubuntu 14.04:
 
  $ make check
  ... all tests pass ...
  $ sudo make check
  ... tests with known issues fail, but ignoring because these have all
 been
  resolved and are issues with the tests alone ...
 
  Thanks Adam.
 
  On Fri, Jul 17, 2015 at 4:42 PM Adam Bordelon a...@mesosphere.io
 wrote:
 
  Hello Mesos community,
 
  Please vote on releasing the following candidate as Apache Mesos
 0.23.0.
 
  0.23.0 includes the following:
 
 
 
  - Per-container network isolation
  - Dockerized slaves will properly recover Docker containers upon
 failover.
  - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
 
  as well as experimental support for:
  - Fetcher Caching
  - Revocable Resources
  - SSL encryption
  - Persistent Volumes
  - Dynamic Reservations
 
  The CHANGELOG for the release is available at:
 
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0-rc4
 
 
 
 
  The candidate for Mesos 0.23.0 release is available at:
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz
 
  The tag to be voted on is 0.23.0-rc4:
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.0-rc4
 
  The MD5 checksum of the tarball can be found at:
 
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.md5
 
  The signature of the tarball can be found at:
 
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.asc
 
  The PGP key used to sign the release is here:
  https://dist.apache.org/repos/dist/release/mesos/KEYS
 
  The JAR is up in Maven in a staging repository here:
  https://repository.apache.org/content/repositories/orgapachemesos-1062
 
  Please vote on releasing this package as Apache Mesos 0.23.0!
 
  The vote is open until Wed July 22nd, 17:00 PDT 2015 and passes if a
  majority of at least 3 +1 PMC votes are cast.
 
  [ ] +1 Release this package as Apache Mesos 0.23.0 (I've tested it!)
  [ ] -1 Do not release this package because ...
 
  Thanks,
  -Adam-
 
 

Re: [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Marco Massenzio]

+1

Run all tests on Ubuntu 14.04 (physical box, not a VM).
All tests pass (as regular user).

`sudo make distcheck` still fails with the following errors; I am assuming
these are known issues and not deemed to be blockers?

[  FAILED  ] 9 tests, listed below:
[  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[  FAILED  ]
MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
[  FAILED  ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
[  FAILED  ] NsTest.ROOT_setns
[  FAILED  ] PerfTest.ROOT_Events
[  FAILED  ] PerfTest.ROOT_SamplePid

I tried to check out 0.22.1 and run the same tests, but it has several
failures and it complains about already existing cgroups hierarchies; so
I'm assuming the earlier test run left the system in an unclean state.


*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jul 21, 2015 at 3:12 PM, Adam Bordelon a...@mesosphere.io wrote:

 +1 (binding) to Mesos 0.23.0-rc4 as 0.23.0
 As I mentioned before, for rc3, basic integration tests passed for Mesos 0
 .23.0 on CoreOS with DCOS GUI/CLI, Marathon, Chronos, Spark, HDFS,
 Cassandra, and Kafka.

 We have been tracking the Ubuntu `sudo make check` failures in
 https://issues.apache.org/jira/browse/MESOS-3079 and related CentOS ROOT_
 test failures in https://issues.apache.org/jira/browse/MESOS-3050 (some
 fixes already pulled into rc4).
 After pulling down the latest master, including a series of test code only
 fixes for MESOS-3079, `sudo make check` passed for me on Ubuntu 14.04,
 excluding only ROOT_DOCKER_Launch_Executor_Bridged (segfault tracked in
 MESOS-3123). There are at least two remaining test-only fixes tracked in
 MESOS-3079, but none of these are critical for Mesos 0.23.0, so I'm not
 inclined to call for a rc5. We can call out the ROOT_ test failures as a
 known issue with the release.

 Anybody else have any test results?

 Please vote,
 -Adam-

 On Fri, Jul 17, 2015 at 8:18 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

 I am almost sure (more like hoping) I'm missing something fundamental
 here and/or there is some basic configuration missing on my box.
 Running tests as root, causes a significant number of failures.

 Has anyone else *ever* run tests as root in the last few weeks?

 Here's the headline, the full log of the failed tests attached.

 $ lsb_release -a
 LSB Version:
  
 core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:cxx-3.0-amd64:cxx-3.0-noarch:cxx-3.1-amd64:cxx-3.1-noarch:cxx-3.2-amd64:cxx-3.2-noarch:cxx-4.0-amd64:cxx-4.0-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-3.1-amd64:desktop-3.1-noarch:desktop-3.2-amd64:desktop-3.2-noarch:desktop-4.0-amd64:desktop-4.0-noarch:desktop-4.1-amd64:desktop-4.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch:graphics-4.1-amd64:graphics-4.1-noarch:languages-3.2-amd64:languages-3.2-noarch:languages-4.0-amd64:languages-4.0-noarch:languages-4.1-amd64:languages-4.1-noarch:multimedia-3.2-amd64:multimedia-3.2-noarch:multimedia-4.0-amd64:multimedia-4.0-noarch:multimedia-4.1-amd64:multimedia-4.1-noarch:printing-3.2-amd64:printing-3.2-noarch:printing-4.0-amd64:printing-4.0-noarch:printing-4.1-amd64:printing-4.1-noarch:qt4-3.1-amd64:qt4-3.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
 Distributor ID: Ubuntu
 Description:*Ubuntu 14.04.2 LTS*
 Release:14.04
 Codename:   *trusty*

 $ sudo make -j12 V=0 check

 [==] 712 tests from 116 test cases ran. (318672 ms total)
 [  PASSED  ] 676 tests.
 [  FAILED  ] 36 tests, listed below:
 [  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
 [  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
 TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
 [  FAILED  ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam =
 mesos::internal::slave::MesosContainerizer
 [  FAILED  ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where
 TypeParam = mesos::internal::slave::MesosContainerizer
 [  FAILED  ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam =
 mesos::internal::slave::MesosContainerizer
 [  FAILED  ] SlaveRecoveryTest/0.RecoverUnregisteredExecutor, where
 TypeParam = mesos::internal::slave::MesosContainerizer
 [  FAILED  ] SlaveRecoveryTest/0.RecoverTerminatedExecutor, where
 TypeParam = mesos::internal::slave::MesosContainerizer
 [  FAILED  ] SlaveRecoveryTest/0.RecoverCompletedExecutor, where
 TypeParam = mesos::internal::slave::MesosContainerizer

Re: Introducing a CMake-based build system for Mesos

[Marco Massenzio]

This is really cool!
Eclipse CDT is becoming a bit tiresome to use, but JetLabs' CLion only
support cmake, so I definitely have a stake in this working :)

Please keep us posted on progress, I'll definitely try and give it a spin
on Ubuntu and OSX.
Thanks for doing it!

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jul 22, 2015 at 6:06 PM, Alex Clemmer clemmer.alexan...@gmail.com
wrote:

 On Wed, Jul 22, 2015 at 3:47 PM, Vinod Kone vinodk...@gmail.com wrote:
  This is exciting! Thanks for sharing the progress Alex.
 
  Mind sending us instructions on how to build/test with cmake for noobs
 like
  me?

 Ah, rats, I knew I was forgetting something.

 It actually looks pretty much like the autotools build system:

 1. Make sure you have all the normal system dependencies installed
 (like APR, etc.)
 2. Make sure you have CMake 2.8 or later installed on your machine.
 (On Ubuntu this looks like: `sudo apt-get install cmake`)
 3. Go to the root of your Mesos source tree and do something like the
 following. Note that you will never have to run bootstrap or
 configure, so you should _only_ have to run the following commands.

 mkdir build-cmake
 cmake ..
 make

 4. Watch as it builds, and hopefully doesn't explode!

 Finally to run tests, you can do `make test ARGS=-V`. They run
 without ANSI colors right now, which is not ideal, but we know it's an
 issue.


 --
 Alex

 Theory is the first term in the Taylor series of practice. -- Thomas M
 Cover (1992)

Re: [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Marco Massenzio]

  ]
MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceForward
[  FAILED  ]
MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PidNamespaceBackward
[  FAILED  ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
[  FAILED  ] NsTest.ROOT_setns
[  FAILED  ] PerfTest.ROOT_Events
[  FAILED  ] PerfTest.ROOT_SamplePid

36 FAILED TESTS
  YOU HAVE 12 DISABLED TESTS



*Marco Massenzio*
*Distributed Systems Engineer*

On Fri, Jul 17, 2015 at 7:26 PM, Marco Massenzio ma...@mesosphere.io
wrote:

 Ubuntu 14.04

 Not sure if I'm doing something wrong, `sudo make distcheck` fails -
 re-running after a `make clean`

 If it continues failing, I'll provide more detailed log output.
 In the meantime, if anyone has any suggestions as to what I may be doing
 wrong, please let me know.

 $ ../configure  make -j8 V=0  make -j12 V=0 check

 [==] 649 tests from 94 test cases ran. (254152 ms total)
 [  PASSED  ] 649 tests.

 $ sudo make -j12 V=0 distcheck

 [==] 712 tests from 116 test cases ran. (325751 ms total)
 [  PASSED  ] 702 tests.
 [  FAILED  ] 10 tests, listed below:
 [  FAILED  ] LimitedCpuIsolatorTest.ROOT_CGROUPS_Pids_and_Tids
 [  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
 [  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
 TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
 [  FAILED  ]
 MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
 [  FAILED  ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
 [  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
 [  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
 [  FAILED  ] NsTest.ROOT_setns
 [  FAILED  ] PerfTest.ROOT_Events
 [  FAILED  ] PerfTest.ROOT_SamplePid

 10 FAILED TESTS
   YOU HAVE 12 DISABLED TESTS


 *Marco Massenzio*
 *Distributed Systems Engineer*

 On Fri, Jul 17, 2015 at 6:49 PM, Vinod Kone vinodk...@gmail.com wrote:

 +1 (binding)

 Successfully built RPMs for CentOS5 and CentOS6 with network isolator.


 On Fri, Jul 17, 2015 at 4:56 PM, Khanduja, Vaibhav 
 vaibhav.khand...@emc.com
  wrote:

  +1
 
  Sent from my iPhone. Please excuse the typos and brevity of this
 message.
 
   On Jul 17, 2015, at 4:43 PM, Adam Bordelon a...@mesosphere.io
 wrote:
  
   Hello Mesos community,
  
   Please vote on releasing the following candidate as Apache Mesos
 0.23.0.
  
   0.23.0 includes the following:
  
 
 
   - Per-container network isolation
   - Dockerized slaves will properly recover Docker containers upon
  failover.
   - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
  
   as well as experimental support for:
   - Fetcher Caching
   - Revocable Resources
   - SSL encryption
   - Persistent Volumes
   - Dynamic Reservations
  
   The CHANGELOG for the release is available at:
  
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0-rc4
  
 
 
  
   The candidate for Mesos 0.23.0 release is available at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz
  
   The tag to be voted on is 0.23.0-rc4:
  
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.0-rc4
  
   The MD5 checksum of the tarball can be found at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.md5
  
   The signature of the tarball can be found at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.asc
  
   The PGP key used to sign the release is here:
   https://dist.apache.org/repos/dist/release/mesos/KEYS
  
   The JAR is up in Maven in a staging repository here:
  
 https://repository.apache.org/content/repositories/orgapachemesos-1062
  
   Please vote on releasing this package as Apache Mesos 0.23.0!
  
   The vote is open until Wed July 22nd, 17:00 PDT 2015 and passes if a
   majority of at least 3 +1 PMC votes are cast.
  
   [ ] +1 Release this package as Apache Mesos 0.23.0 (I've tested it!)
   [ ] -1 Do not release this package because ...
  
   Thanks,
   -Adam-
 






$ sudo make -j12 V=0 check

[==] 712 tests from 116 test cases ran. (318672 ms total)
[  PASSED  ] 676 tests.
[  FAILED  ] 36 tests, listed below:
[  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[  FAILED  ] SlaveRecoveryTest/0.RecoverSlaveState, where TypeParam = mesos::internal::slave::MesosContainerizer
[  FAILED  ] SlaveRecoveryTest/0.RecoverStatusUpdateManager, where TypeParam = mesos::internal::slave::MesosContainerizer
[  FAILED  ] SlaveRecoveryTest/0.ReconnectExecutor, where TypeParam = mesos::internal::slave::MesosContainerizer
[  FAILED  ] SlaveRecoveryTest/0

Re: [VOTE] Release Apache Mesos 0.23.0 (rc4)

[Marco Massenzio]

Ubuntu 14.04

Not sure if I'm doing something wrong, `sudo make distcheck` fails -
re-running after a `make clean`

If it continues failing, I'll provide more detailed log output.
In the meantime, if anyone has any suggestions as to what I may be doing
wrong, please let me know.

$ ../configure  make -j8 V=0  make -j12 V=0 check

[==] 649 tests from 94 test cases ran. (254152 ms total)
[  PASSED  ] 649 tests.

$ sudo make -j12 V=0 distcheck

[==] 712 tests from 116 test cases ran. (325751 ms total)
[  PASSED  ] 702 tests.
[  FAILED  ] 10 tests, listed below:
[  FAILED  ] LimitedCpuIsolatorTest.ROOT_CGROUPS_Pids_and_Tids
[  FAILED  ] PerfEventIsolatorTest.ROOT_CGROUPS_Sample
[  FAILED  ] UserCgroupIsolatorTest/2.ROOT_CGROUPS_UserCgroup, where
TypeParam = mesos::internal::slave::CgroupsPerfEventIsolatorProcess
[  FAILED  ]
MesosContainerizerSlaveRecoveryTest.CGROUPS_ROOT_PerfRollForward
[  FAILED  ] CgroupsAnyHierarchyWithPerfEventTest.ROOT_CGROUPS_Perf
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_Statistics
[  FAILED  ] MemoryPressureMesosTest.CGROUPS_ROOT_SlaveRecovery
[  FAILED  ] NsTest.ROOT_setns
[  FAILED  ] PerfTest.ROOT_Events
[  FAILED  ] PerfTest.ROOT_SamplePid

10 FAILED TESTS
  YOU HAVE 12 DISABLED TESTS


*Marco Massenzio*
*Distributed Systems Engineer*

On Fri, Jul 17, 2015 at 6:49 PM, Vinod Kone vinodk...@gmail.com wrote:

 +1 (binding)

 Successfully built RPMs for CentOS5 and CentOS6 with network isolator.


 On Fri, Jul 17, 2015 at 4:56 PM, Khanduja, Vaibhav 
 vaibhav.khand...@emc.com
  wrote:

  +1
 
  Sent from my iPhone. Please excuse the typos and brevity of this message.
 
   On Jul 17, 2015, at 4:43 PM, Adam Bordelon a...@mesosphere.io wrote:
  
   Hello Mesos community,
  
   Please vote on releasing the following candidate as Apache Mesos
 0.23.0.
  
   0.23.0 includes the following:
  
 
 
   - Per-container network isolation
   - Dockerized slaves will properly recover Docker containers upon
  failover.
   - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
  
   as well as experimental support for:
   - Fetcher Caching
   - Revocable Resources
   - SSL encryption
   - Persistent Volumes
   - Dynamic Reservations
  
   The CHANGELOG for the release is available at:
  
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0-rc4
  
 
 
  
   The candidate for Mesos 0.23.0 release is available at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz
  
   The tag to be voted on is 0.23.0-rc4:
  
 
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.0-rc4
  
   The MD5 checksum of the tarball can be found at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.md5
  
   The signature of the tarball can be found at:
  
 
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc4/mesos-0.23.0.tar.gz.asc
  
   The PGP key used to sign the release is here:
   https://dist.apache.org/repos/dist/release/mesos/KEYS
  
   The JAR is up in Maven in a staging repository here:
   https://repository.apache.org/content/repositories/orgapachemesos-1062
  
   Please vote on releasing this package as Apache Mesos 0.23.0!
  
   The vote is open until Wed July 22nd, 17:00 PDT 2015 and passes if a
   majority of at least 3 +1 PMC votes are cast.
  
   [ ] +1 Release this package as Apache Mesos 0.23.0 (I've tested it!)
   [ ] -1 Do not release this package because ...
  
   Thanks,
   -Adam-
 

Re: [jira] [Commented] (MESOS-3035) As a Developer I would like a standard way to run a Subprocess in libprocess

[Marco Massenzio]

No update, I'm afraid, still waiting for a review from the shepherd.
Implemented all suggested changes, but before investing more time on this,
I want to be sure I'm on the right track.

Been burned already a few times, having gone through several reviews cycle,
done all that was asked of me, and yet, eventually, the whole thing was
dropped...

BTW - the whole idea of this RR was to avoid having the same code, slightly
changed, sprinkled all over the code base (MESOS-2902 needs this too).

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 16, 2015 at 12:31 PM, Paul Brett pbr...@twitter.com.invalid
wrote:

 Marco

 Any progress on getting an update to this?  It is a blocker on fixing the
 perf issues.

 Thanks

 -- Paul


 On Mon, Jul 13, 2015 at 3:24 PM, Paul Brett (JIRA) j...@apache.org
 wrote:

 
  [
 
 https://issues.apache.org/jira/browse/MESOS-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14625487#comment-14625487
  ]
 
  Paul Brett commented on MESOS-3035:
  ---
 
  +1
 
   As a Developer I would like a standard way to run a Subprocess in
  libprocess
  
 
 
  
   Key: MESOS-3035
   URL: https://issues.apache.org/jira/browse/MESOS-3035
   Project: Mesos
Issue Type: Story
Components: libprocess
  Reporter: Marco Massenzio
  Assignee: Marco Massenzio
  
   As part of MESOS-2830 and MESOS-2902 I have been researching the
 ability
  to run a {{Subprocess}} and capture the {{stdout / stderr}} along with
 the
  exit status code.
   {{process::subprocess()}} offers much of the functionality, but in a
 way
  that still requires a lot of handiwork on the developer's part; we would
  like to further abstract away the ability to just pass a string, an
  optional set of command-line arguments and then collect the output of the
  command (bonus: without blocking).
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.3.4#6332)
 



 --
 -- Paul Brett

Re: [jira] [Commented] (MESOS-3035) As a Developer I would like a standard way to run a Subprocess in libprocess

[Marco Massenzio]

No, no - no frustration at all :)
It was just me going down the wrong path too fast, without waiting for
advice.
(as allegedly a Turkish proverb says: No matter how far down the wrong
path you're gone, it's never too late to turn back - I'm hoping someone
from Turkey on the list can confirm or deny :)

@Paul: please go ahead if you can't wait for this to be committed - by all
means, feel free to add a TODO(marco) against your code and assign me a
Jira to refactor, once this lands.
(please tag it 'mesosphere' and 'tech debt' so we're sure not to drop it.
Thanks!)

More Comments inline.

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 16, 2015 at 6:20 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 Hey sorry for the frustration, I wrote subprocess originally but it's
 evolved over time through a number of folks. Is ben going to shepherd this?


Sweet - I'll be copying your comments into the review (so we keep track of
them) and will work my way through them.

Yes, benh was supposed to shepherd this - but he's not feeling all that
well, as you wrote originally the Subprocess, I'm kinda wondering whether
you could shepherd this one?
Just a thought.


 Just a few higher level things to consider:

 (1) Discard semantics: with subprocess the caller has the ability to kill
 the process through s.pid. However, with 'execute' that you've introduced,
 if the caller discards the future, we should be killing the process tree
 we've forked to clean up.


Nice catch - I may need some guidance on how to do that, but I'll give it a
shot.



 (2) As a general note, FutureTrystring as a type tends to be a bit
 confusing for folks as one has to resort to reading comments to figure out
 the difference between f.isFailed() and f.get().isError(). When we talk
 about readability we're generally including things like this, where it
 isn't obvious to the reader of the code. Similar to paul's approach, I'd
 suggest having a small struct to capture the data of a completed command
 (i.e. status, out, err) to make this very clear. e.g. FutureOutput Make
 sense?


Yes!
I was actually thinking about even creating a Protobuf for this (some kind
of CommandResultInfo) and use that.



 (3) Subprocess has two overloads, path+args (exec-style), and command (sh
 -c command style). Your documentation says sh -c but the code is just
 directly passing through to path+args subprocess, so it's not going through
 sh -c at all. Something I'm missing?


Bad comment (I'd originally started down the 'sh -c' path, then figured out
it was not strictly necessary).
I'll fix that.


 Lastly, it would be great to see the caller code related to this, spot
 checking I see a number of places that are unnecessarily tedious (e.g.
 perf.cpp):

 // Start reading from stdout and stderr now. We don't use stderr
 // but must read from it to avoid the subprocess blocking on the
 // pipe.
 output.push_back(io::read(perf.get().out().get()));
 output.push_back(io::read(perf.get().err().get()));

 // Wait for the process to exit.
 perf.get().status()
   .onAny(defer(self(), Self::_sample, lambda::_1));

 vs

 process::await(
 perf.get().status(),
 io::read(perf.get().out().get()),
 io::read(perf.get().err().get()))
   .then(defer(self(), Self::_sample, lambda::_1));

 There is no need to wait for the command first before continuing, can just
 wait for everything. Having something like what you're proposing seems even
 cleaner, but it would be helpful to first start with the above improvement
 to get a better sense of all the use cases, and whether just adding a
 .join() that returns FutureOutput gets us all the way there. I propose
 this first because the structural simplifications needed will be very
 similar to those from process::executeCommand.


Uhm - this is assuming a deeper understanding of libprocess than I
currently have: let me ponder this a bit and I may reach out for more
advice.
And, yes, my code was largely based on perf.cpp blueprint.



 Anyway, I will let benh shepherd this, but just wanted to share some
 feedback.


Thanks, appreciated!



 On Thu, Jul 16, 2015 at 5:06 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  No update, I'm afraid, still waiting for a review from the shepherd.
  Implemented all suggested changes, but before investing more time on
 this,
  I want to be sure I'm on the right track.
 
  Been burned already a few times, having gone through several reviews
 cycle,
  done all that was asked of me, and yet, eventually, the whole thing was
  dropped...
 
  BTW - the whole idea of this RR was to avoid having the same code,
 slightly
  changed, sprinkled all over the code base (MESOS-2902 needs this too).
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
  On Thu, Jul 16, 2015 at 12:31 PM, Paul Brett pbr...@twitter.com.invalid
 
  wrote:
 
   Marco
  
   Any progress on getting an update to this?  It is a blocker on fixing
 the
   perf issues

Re: [VOTE] Release Apache Mesos 0.23.0 (rc3)

[Marco Massenzio]

Adam - thanks.
Please let me know soon as you push an rc4, if I'm still home, I can test
it against Ubuntu 14.04 with/without SSL, with/without sudo (or I can
always VPN in :)

Very minor doc update: https://reviews.apache.org/r/36532/
(feel free to ignore).

Thanks, everyone!

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 16, 2015 at 8:05 PM, Adam Bordelon a...@mesosphere.io wrote:

 Thanks, Vinod. I've got those commits in the list already. We'll pull in
 fixes for MESOS-3055 and others for rc4.
 I'll give it another night for Bernd to commit the fetcher fix and for
 Niklas to update the oversubscription doc.
 Then I'll cut rc4 tomorrow and leave the new vote open until next
 Wednesday.
 See the dashboard for status on remaining issues:
 https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326227

 Jeff, see my cherry-pick spreadsheet to see what we're planning to pull
 into rc4:

 https://docs.google.com/spreadsheets/d/14yUtwfU0mGQ7x7UcjfzZg2o1TuRMkn5SvJvetARM7JQ/edit#gid=0
 If anybody has any other high priority fixes or doc updates that they want
 in rc4, let me know asap.

 On Thu, Jul 16, 2015 at 7:58 PM, Jeff Schroeder 
 jeffschroe...@computer.org wrote:

 What about MESOS-3055 in 0.23? Is that going to get passed up on even if
 we are going to cut another rc?

 On Thursday, July 16, 2015, Vinod Kone vinodk...@gmail.com wrote:

 -1 so that we can cherry pick MESOS-3055.

 The master crash bug is MESOS-3070
 https://issues.apache.org/jira/browse/MESOS-3070 but the fix is
 non-trivial and the bug has been in the code base prior to 23.0. So I won't
 make it a blocker.

 Can't update the spreadsheet. So here are the commits I would like
 cherry-picked.

 fc85cc512b7767fc2e3921b15cf6602c0c68593e
 bfe6c07b79550bb3d1f2ab6f5344d740e6eb6f60

 Thanks Adam.

 On Thu, Jul 16, 2015 at 7:39 PM, Adam Bordelon a...@mesosphere.io
 wrote:

 The 7 day voting period has ended with only 2 binding +1s (we needed 3)
 and
 no explicit -1s.
 However, Vinod says they've found a bug that crashes master when a
 framework uses duplicate task ids.
 Vinod, can you please share the new JIRA and officially vote -1 for rc3
 if
 you want to call for an rc4?
 Assuming we'll cut an rc4, I'm tracking the JIRAs/patches to pull in
 here:


 https://docs.google.com/spreadsheets/d/14yUtwfU0mGQ7x7UcjfzZg2o1TuRMkn5SvJvetARM7JQ/edit#gid=0
 Since the rc4 changes are minor (mostly tests) and we've heavily tested
 rc3, the next vote will only last for 3 (business) days.


 On Thu, Jul 16, 2015 at 6:38 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Just to add my +1
 
  Built  Make check on Ubuntu 14.04
  With  Without SSL / libevent
  (no 'sudo' - can test all 4 variants this evening on rc4)
 
  —
  Sent from Mailbox https://www.dropbox.com/mailbox
 
 
  On Thu, Jul 16, 2015 at 3:10 PM, Timothy Chen tnac...@gmail.com
 wrote:
 
  As Adam mention I also think this is not a blocker, as it only
 affects
  the way we test the cgroup on CentOS 7.x due to a CentOS bug and
  doesn't actually impact Mesos normal operations.
 
  My vote is +1 as well.
 
  Tim
 
  On Thu, Jul 16, 2015 at 12:10 PM, Vinod Kone vinodk...@gmail.com
  wrote:
   Found a bug in HTTP API related code: MESOS-3055
   https://issues.apache.org/jira/browse/MESOS-3055
  
   If we don't fix this in 0.23.0, we cannot expect the 0.24.0
 scheduler
   driver (that will send Calls) to properly subscribe with a 0.23.0
  master. I
   could add a work around in the driver to only send Calls if the
 master
   version is 0.24.0, but would prefer to not have to do that.
  
   Also, on the review https://reviews.apache.org/r/36518/ for that
  bug, we
   realized that we might want to make Subscribe.force 'optional'
 instead
  of
   'required'. That's an API change, which would be nice to go into
 0.23.0
  as
   well.
  
   So, not a -1 per se, but if you are willing to cut another RC, I
 can
  land
   the fixes today. Sorry for the trouble.
  
   On Thu, Jul 16, 2015 at 11:48 AM, Adam Bordelon 
 a...@mesosphere.io
  wrote:
  
   +1 (binding)
   This vote has been silent for almost a week. I assume everybody's
 busy
   testing. My testing results: basic integration tests passed for
 Mesos
   0.23.0 on CoreOS with DCOS GUI/CLI, Marathon, Chronos, Spark,
 HDFS,
   Cassandra, and Kafka.
  
   `make check` passes on Ubuntu and CentOS, but `sudo make check`
 fails
  on
   CentOS 7.1 due to errors in CentOS. See
   https://issues.apache.org/jira/browse/MESOS-3050 for more
 details.
  I'm not
   convinced this is serious enough to do another release candidate
 and
  voting
   round, but I'll let Tim and others chime in with their thoughts.
  
   If we don't get enough deciding votes by 6pm Pacific today, I'll
  extend the
   vote for another day.
  
   On Thu, Jul 9, 2015 at 6:09 PM, Khanduja, Vaibhav 
   vaibhav.khand...@emc.com
   wrote:
  
+1
   
Sent from my iPhone. Please excuse the typos and brevity of this
  message.
   
 On Jul 9, 2015, at 6:07 PM

Re: Doxygen / Javadoc changes

[Marco Massenzio]

BTW - I concur that we are indeed in agreement ;)

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jul 14, 2015 at 11:08 PM, Marco Massenzio ma...@mesosphere.io
wrote:

 Hey Ben,

 my apologies - I expressed myself incorrectly: what I meant was a generic
 you random guy (which I know, the correct way would have been to use
 one and I didn't, my bad).
 I promise never again to send an email at 8am, sleep-deprived and
 oxygen-deprived in a crowded train.

 *Marco Massenzio*
 *Distributed Systems Engineer*

 On Tue, Jul 14, 2015 at 1:54 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com wrote:

 I'm bewildered by this reply, seems my comments were misinterpreted?

 I'm suggesting that we _do_ add doxygen comments to our libraries (stout,
 libprocess, state, cgroups, etc) as that is a nice way to make them
 accessible. I'm less convinced that there's value in adding doxygen in
 _every_ internal header in mesos (e.g. master / slave, as these are not
 libraries).

 Also, folks _are_ free to add documentation no matter what, I'm just
 suggesting that they keep the style consistent within a library header.
 They are free to do a conversion sweep before _or_ after, it does not
 block
 their ability to contribute to documentation, just means they need to
 maintain consistent formatting.

 Sad to see implications that I do not care about productivity, or that I'm
 trying to prevent people from contributing documentation... :(

 On Tue, Jul 14, 2015 at 8:12 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  On Mon, Jul 13, 2015 at 9:41 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
   Let me try to contain the length of this thread, two points don't
 seem to
   agree my request and benh's reply.
  
   (1) You're saying all non-trivial classes / methods in headers should
  have
   javadoc, whereas benh is saying APIs. Are these the same? I'd much
 rather
   see this focused on APIs (i.e. libraries) rather than internal
   implementations (e.g. master / slave) since people operating within
 the
   latter ideally should be comfortable reading the code. Library users,
  less
   so.
  
 
  I find difficult to follow the reasoning here: are you suggesting that
  every time a developer uses a library function they are supposed to
  reverse engineer the code?
  that feels not a very efficient way of running a large development team
 and
  it certainly was not the way we rolled at Google :)
 
  On the contrary, due to their frequent and extensive use, IMO library
  methods/classes ought to have _extensive_ documentation.
 
  Then again, maybe it's just me caring about productivity in my teams...
 
 
  
   (2) Doing the incremental change will make things inconsistent :(
 Given
   that doing a javadoc conversion sweep for a library header is not that
   tedious, it seems wise to just have consistency as a forcing function
 for
   folks to do sweeps. Plus we keep the documentation consistently
  formatted,
   which seems like a big win!
  
 
  Sure - and +100 to that!
  But, in the meantime, let's not have folks *not* add javadoc (or worse,
  demand they remove those they may have already added during code
 review!)
  or require them to do a sweep only because they added ONE method and
 want
  to document that.
 
  Again, I'm trying here to lower the bar for participation for folks who
 are
  not (yet) deep experts in Mesos' internals and encourage participation
 of
  people who are excited about contributing functionality to Mesos: if the
  cost is to have to reverse engineer[*] some obscure parts of
 libprocess
  and spend days (or weeks) trying to figure out how to correctly use the
  base libraries, I think we'll all lose in the long run.
 
  Bottom line, Ben - if you don't feel like adding documentation/javadoc
 to
  the methods/classes you contribute, I guess that's fine: but, please,
 let's
  not prevent folks from doing so, that's all I'm saying.
 
  Thanks!
 
  [*] NOTE - I still expect people to intimately understand the
 functionality
  of libprocess/stout and whatever else is already in Mesos proper:
 however,
  that would ideally be gained by studying extensive documentation;
 looking
  at existing and sample code: and experimenting with it.
  What I do object to is the extra layer of effort in having to
  reverse-engineer large, undocumented and complex areas of the code.
 
 
  
  
   On Fri, Jul 10, 2015 at 9:39 AM, Marco Massenzio ma...@mesosphere.io
 
   wrote:
  
On Thu, Jul 9, 2015 at 5:23 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com

wrote:
   
 A couple of thoughts:

 (1) When introducing javadoc comments, can we please keep comment
  style
 consistent within files and APIs? For the most part, it seems
 folks
  are
 introducing javadoc in consistent sweeps, which is great.
 However, it
looks
 also like there are reviews and commits where we are introducing
   javadoc
+
 non-javadoc within a file / api, would love to avoid

Re: Doxygen / Javadoc changes

[Marco Massenzio]

Hey Ben,

my apologies - I expressed myself incorrectly: what I meant was a generic
you random guy (which I know, the correct way would have been to use
one and I didn't, my bad).
I promise never again to send an email at 8am, sleep-deprived and
oxygen-deprived in a crowded train.

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jul 14, 2015 at 1:54 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 I'm bewildered by this reply, seems my comments were misinterpreted?

 I'm suggesting that we _do_ add doxygen comments to our libraries (stout,
 libprocess, state, cgroups, etc) as that is a nice way to make them
 accessible. I'm less convinced that there's value in adding doxygen in
 _every_ internal header in mesos (e.g. master / slave, as these are not
 libraries).

 Also, folks _are_ free to add documentation no matter what, I'm just
 suggesting that they keep the style consistent within a library header.
 They are free to do a conversion sweep before _or_ after, it does not block
 their ability to contribute to documentation, just means they need to
 maintain consistent formatting.

 Sad to see implications that I do not care about productivity, or that I'm
 trying to prevent people from contributing documentation... :(

 On Tue, Jul 14, 2015 at 8:12 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  On Mon, Jul 13, 2015 at 9:41 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
   Let me try to contain the length of this thread, two points don't seem
 to
   agree my request and benh's reply.
  
   (1) You're saying all non-trivial classes / methods in headers should
  have
   javadoc, whereas benh is saying APIs. Are these the same? I'd much
 rather
   see this focused on APIs (i.e. libraries) rather than internal
   implementations (e.g. master / slave) since people operating within the
   latter ideally should be comfortable reading the code. Library users,
  less
   so.
  
 
  I find difficult to follow the reasoning here: are you suggesting that
  every time a developer uses a library function they are supposed to
  reverse engineer the code?
  that feels not a very efficient way of running a large development team
 and
  it certainly was not the way we rolled at Google :)
 
  On the contrary, due to their frequent and extensive use, IMO library
  methods/classes ought to have _extensive_ documentation.
 
  Then again, maybe it's just me caring about productivity in my teams...
 
 
  
   (2) Doing the incremental change will make things inconsistent :( Given
   that doing a javadoc conversion sweep for a library header is not that
   tedious, it seems wise to just have consistency as a forcing function
 for
   folks to do sweeps. Plus we keep the documentation consistently
  formatted,
   which seems like a big win!
  
 
  Sure - and +100 to that!
  But, in the meantime, let's not have folks *not* add javadoc (or worse,
  demand they remove those they may have already added during code review!)
  or require them to do a sweep only because they added ONE method and
 want
  to document that.
 
  Again, I'm trying here to lower the bar for participation for folks who
 are
  not (yet) deep experts in Mesos' internals and encourage participation of
  people who are excited about contributing functionality to Mesos: if the
  cost is to have to reverse engineer[*] some obscure parts of libprocess
  and spend days (or weeks) trying to figure out how to correctly use the
  base libraries, I think we'll all lose in the long run.
 
  Bottom line, Ben - if you don't feel like adding documentation/javadoc to
  the methods/classes you contribute, I guess that's fine: but, please,
 let's
  not prevent folks from doing so, that's all I'm saying.
 
  Thanks!
 
  [*] NOTE - I still expect people to intimately understand the
 functionality
  of libprocess/stout and whatever else is already in Mesos proper:
 however,
  that would ideally be gained by studying extensive documentation; looking
  at existing and sample code: and experimenting with it.
  What I do object to is the extra layer of effort in having to
  reverse-engineer large, undocumented and complex areas of the code.
 
 
  
  
   On Fri, Jul 10, 2015 at 9:39 AM, Marco Massenzio ma...@mesosphere.io
   wrote:
  
On Thu, Jul 9, 2015 at 5:23 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com

wrote:
   
 A couple of thoughts:

 (1) When introducing javadoc comments, can we please keep comment
  style
 consistent within files and APIs? For the most part, it seems folks
  are
 introducing javadoc in consistent sweeps, which is great. However,
 it
looks
 also like there are reviews and commits where we are introducing
   javadoc
+
 non-javadoc within a file / api, would love to avoid the
  inconsistency.
:(

   
This is a great suggestion, and I am really excited to see people
 doing
this and helping us having a great, well-documented codebase!
   
Until we get to the point

Re: Doxygen / Javadoc changes

[Marco Massenzio]

On Mon, Jul 13, 2015 at 9:41 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 Let me try to contain the length of this thread, two points don't seem to
 agree my request and benh's reply.

 (1) You're saying all non-trivial classes / methods in headers should have
 javadoc, whereas benh is saying APIs. Are these the same? I'd much rather
 see this focused on APIs (i.e. libraries) rather than internal
 implementations (e.g. master / slave) since people operating within the
 latter ideally should be comfortable reading the code. Library users, less
 so.


I find difficult to follow the reasoning here: are you suggesting that
every time a developer uses a library function they are supposed to
reverse engineer the code?
that feels not a very efficient way of running a large development team and
it certainly was not the way we rolled at Google :)

On the contrary, due to their frequent and extensive use, IMO library
methods/classes ought to have _extensive_ documentation.

Then again, maybe it's just me caring about productivity in my teams...



 (2) Doing the incremental change will make things inconsistent :( Given
 that doing a javadoc conversion sweep for a library header is not that
 tedious, it seems wise to just have consistency as a forcing function for
 folks to do sweeps. Plus we keep the documentation consistently formatted,
 which seems like a big win!


Sure - and +100 to that!
But, in the meantime, let's not have folks *not* add javadoc (or worse,
demand they remove those they may have already added during code review!)
or require them to do a sweep only because they added ONE method and want
to document that.

Again, I'm trying here to lower the bar for participation for folks who are
not (yet) deep experts in Mesos' internals and encourage participation of
people who are excited about contributing functionality to Mesos: if the
cost is to have to reverse engineer[*] some obscure parts of libprocess
and spend days (or weeks) trying to figure out how to correctly use the
base libraries, I think we'll all lose in the long run.

Bottom line, Ben - if you don't feel like adding documentation/javadoc to
the methods/classes you contribute, I guess that's fine: but, please, let's
not prevent folks from doing so, that's all I'm saying.

Thanks!

[*] NOTE - I still expect people to intimately understand the functionality
of libprocess/stout and whatever else is already in Mesos proper: however,
that would ideally be gained by studying extensive documentation; looking
at existing and sample code: and experimenting with it.
What I do object to is the extra layer of effort in having to
reverse-engineer large, undocumented and complex areas of the code.




 On Fri, Jul 10, 2015 at 9:39 AM, Marco Massenzio ma...@mesosphere.io
 wrote:

  On Thu, Jul 9, 2015 at 5:23 PM, Benjamin Mahler 
 benjamin.mah...@gmail.com
  
  wrote:
 
   A couple of thoughts:
  
   (1) When introducing javadoc comments, can we please keep comment style
   consistent within files and APIs? For the most part, it seems folks are
   introducing javadoc in consistent sweeps, which is great. However, it
  looks
   also like there are reviews and commits where we are introducing
 javadoc
  +
   non-javadoc within a file / api, would love to avoid the inconsistency.
  :(
  
 
  This is a great suggestion, and I am really excited to see people doing
  this and helping us having a great, well-documented codebase!
 
  Until we get to the point where the majority of the codebase is well
  documented, I would suggest we use what in past similar situations I
 called
  the ratchet concept: whatever is added must be Done Right, and you can
  never slip back.
  This will, in due course, get us all where we want to be, without slowing
  progress too much.
 
  (Am I correct in assuming you too were *not* suggesting that, if we add
 1-2
  methods with javadoc-style docs, *all* existing ones must be updated too,
  right?)
 
 
   (2) Where are we planning to introduce javadoc comments? APIs only? All
   headers? Would love to see some communication around how we'd like
 folks
  to
   be proceeding. Maybe I missed it, but can't seem to find an email with
   this.
  
 
  The idea would be to have javadoc-style Doxygen comments for all header
  files, for all *non-trivial* public classes/methods - initially, this
 will
  be a *requirement* only for newly added code, with the occasional sweep
  on existing classes; hopefully, we'll eventually get to the point where
 the
  undocumented wilderness footprint has shrunk to the point where we can
  mandate complete compliance.
 
  I think it would also be great to encourage drive-by additions: it's
  often the case that one spends time trying to figure out how an (as yet,
  undocumented) API/method works while they are using it in other parts of
  the code, and it would be a shame to waste that effort.
  If that's done in a chained patch, so much the better, but the admin
  burden is sometimes not worth

Re: Doxygen / Javadoc changes

[Marco Massenzio]

On Thu, Jul 9, 2015 at 5:23 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 A couple of thoughts:

 (1) When introducing javadoc comments, can we please keep comment style
 consistent within files and APIs? For the most part, it seems folks are
 introducing javadoc in consistent sweeps, which is great. However, it looks
 also like there are reviews and commits where we are introducing javadoc +
 non-javadoc within a file / api, would love to avoid the inconsistency. :(


This is a great suggestion, and I am really excited to see people doing
this and helping us having a great, well-documented codebase!

Until we get to the point where the majority of the codebase is well
documented, I would suggest we use what in past similar situations I called
the ratchet concept: whatever is added must be Done Right, and you can
never slip back.
This will, in due course, get us all where we want to be, without slowing
progress too much.

(Am I correct in assuming you too were *not* suggesting that, if we add 1-2
methods with javadoc-style docs, *all* existing ones must be updated too,
right?)


 (2) Where are we planning to introduce javadoc comments? APIs only? All
 headers? Would love to see some communication around how we'd like folks to
 be proceeding. Maybe I missed it, but can't seem to find an email with
 this.


The idea would be to have javadoc-style Doxygen comments for all header
files, for all *non-trivial* public classes/methods - initially, this will
be a *requirement* only for newly added code, with the occasional sweep
on existing classes; hopefully, we'll eventually get to the point where the
undocumented wilderness footprint has shrunk to the point where we can
mandate complete compliance.

I think it would also be great to encourage drive-by additions: it's
often the case that one spends time trying to figure out how an (as yet,
undocumented) API/method works while they are using it in other parts of
the code, and it would be a shame to waste that effort.
If that's done in a chained patch, so much the better, but the admin
burden is sometimes not worth the effort: again, I'd like to encourage
folks to add as much docs as they feel like doing, by lowering the barriers
to doing so.


 (3) I ask because there is a tradeoff: we make the code more verbose to
 navigate visually. Also, sometimes we document things unnecessarily:


Couldn't agree more!
That was the non-trivial part of my comment above :)


 /**
  * Sends a message with data without a return address.
  *
  * @param to Receiver of the message.
  * @param name Name of the message.
  * @param data Data to send (gets copied).
  * @param length Length of data.
  */
 void post(const UPID to,
   const std::string name,
   const char* data = NULL,
   size_t length = 0);

 Here, having a 'to' or 'receiver' as a variable name is pretty
 self-evident, ditto for 'messageName', 'data', 'length'. Are we ok with
 omitting these kinds of comments? It seems like we have to be asking
 ourselves when this provides value. Thoughts?


+1

Thanks for raising the issue, Ben - and sorry for not doing this before: I
got over-enthusiastic about having great documented code :)

Re: Quota Design Doc v1

[Marco Massenzio]

I've added my twocent in the doc - my vote goes for Guaranteed Allocation
- not as catchy as Quota (and will make classes' naming a challenge!) but
maybe more helpful in the long-term.

Anyone has a better suggestion, please do... I can't really say I'm
super-excited by Guaranteed Allocation myself!

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 9, 2015 at 1:48 AM, Alex Rukletsov a...@mesosphere.com wrote:

 And you're not the only one who were confused by the terminology! One of
 the alternatives that didn't make it to the public doc was cluster-wide
 dynamic reservations. The reason we preferred quota to  ...
 reservation is because the latter is already overloaded with meanings in
 Mesos world (static reservations, dynamic reservations). I have hoped the
 Terminology section would have helped to avoid the confusion, but I see it
 doesn't. We'll think about how we can solve the problem, we definitely
 don't want to create one more libprocess process represented as a thread
 in an OS process ; ).

 I see your point regarding authorization, you're not alone here either : ).
 Some folks mentioned that the lack of authz is a blocker and will prevent
 them from upgrading the cluster. I would propose to treat MVP as
 experimental feature: use it at your own risk or disable endpoints related
 to quota and hence the entire feature. Does it make sense?

 On Wed, Jul 8, 2015 at 7:10 PM, James Peach jor...@gmail.com wrote:

 
   On Jul 4, 2015, at 3:15 AM, Alex Rukletsov a...@mesosphere.com
 wrote:
  
   Folks,
  
   Jörg and I are working on adding *quota* support to Mesos. Quota can be
   described as cluster-wide dynamic reservation. I would like to share
 the
   design doc [1] to gather community feedback early in the design phase.
 
  The most confusing part of this document to me was the 'quota'
  terminology. Quotas normally refer to administrative limits (esp. disk
  quotas with hard and soft limits), not reserving resources. Since what
 you
  are describing is an extension to the resource reservation system, it
 would
  be clearer if it was described in those terms.
 
  I was also concerned that access control / authorization is not planned
  for the initial implementation. I think that if Mesos is to have an
  authorization policy, it should be applied uniformly following the
  principle of least surprise.
 
   The doc is work in progress, especially the part related to quota
 support
   in the allocator. We think we can start working on adding quota support
  to
   Mesos Master while fleshing out the design for how quota is handled by
  the
   built-in allocator.
  
   While working on the design, we faced some challenges and design
  questions.
   One of them is what decisions should be deferred to allocator and what
  can
   be decided by the Master. We elaborate on this in the doc.
  
   Looking forward to your feedback!
  
   [1]:
  
 
 https://docs.google.com/document/d/16iRNmziasEjVOblYp5bbkeBZ7pnjNlaIzPQqMTHQ-9I/edit?usp=sharing
 
 

Re: [RESULT] [VOTE] Release Apache Mesos 0.23.0 (rc1)

[Marco Massenzio]

As a general rule, we should not include anything other than the fixes in an 
RC, to avoid introducing further bugs in a never-ending cycle.




Please keep the cherry-picking strictly limited to a very narrow set (which I'm 
sure you're already doing, but your email seemed to imply otherwise ;-)




Thanks!



—
Sent from Mailbox

On Tue, Jul 7, 2015 at 3:56 PM, Adam Bordelon a...@mesosphere.io wrote:

 In case it wasn't obvious, rc1 did not pass the vote, due to a few build
 and unit test issues.
 Most of those fixes have been committed, so we will cut rc2 when the last
 blocker is resolved.
 This is your last chance to get any recently committed patches or resolved
 issues into 0.23.0.
 I am tracking the 0.23.0-rc2 cherry picks in
 https://docs.google.com/spreadsheets/d/14yUtwfU0mGQ7x7UcjfzZg2o1TuRMkn5SvJvetARM7JQ/edit#gid=0
 Please contact me ASAP if you want anything else included.
 Thanks,
 -Adam-
 P.S. 0.23 Dashboard is still in action:
 https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326227
 On Tue, Jul 7, 2015 at 1:59 PM, Adam Bordelon a...@mesosphere.io wrote:
  -1 (non-binding) Network isolator will not compile.
 https://issues.apache.org/jira/browse/MESOS-3002

 The changes for MESOS-2800
 https://issues.apache.org/jira/browse/MESOS-2800 to Rename
 OptionT::get(const T _t) to getOrElse() happened after the 0.23.0-rc1
 cut and are not planned for cherry-picking into the release.
 The Fix Version of MESOS-2800
 https://issues.apache.org/jira/browse/MESOS-2800 is 0.24.0, so the
 Affects Version of MESOS-3002
 https://issues.apache.org/jira/browse/MESOS-3002 is really 0.24.0, and
 hence its Target Version should also be 0.24.0.
 Please let me know otherwise if you actually saw this build error when
 building from the 0.23.0-rc1 tag.

 On Tue, Jul 7, 2015 at 11:48 AM, Paul Brett pbr...@twitter.com wrote:

 -1 (non-binding) Network isolator will not compile.
 https://issues.apache.org/jira/browse/MESOS-3002


 On Tue, Jul 7, 2015 at 11:38 AM, Alexander Rojas alexan...@mesosphere.io
  wrote:

 +1 (non-binding)

 Ubuntu Server 15.04 gcc 4.9.2 and clang 3.6.0

 OS X Yosemite clang Apple LLVM based on 3.6.0


 On 06 Jul 2015, at 21:14, Jörg Schad jo...@mesosphere.io wrote:

 After more testing:
 -1 (non-binding)
 Docker tests failing on CentOS Linux release 7.1.1503 (Core) , Tim is
 already on the issue (see MESOS-2996)


 On Mon, Jul 6, 2015 at 8:59 PM, Kapil Arya ka...@mesosphere.io wrote:

 +1 (non-binding)

 OpenSUSE Tumbleweed, Linux 4.0.3 / gcc 4.8.3

 On Mon, Jul 6, 2015 at 2:33 PM, Ben Whitehead 
 ben.whiteh...@mesosphere.io wrote:

 +1 (non-binding)

 openSUSE 13.2 Linux 3.16.7 / gcc-4.8.3
 Tested running Marathon 0.9.0-RC3 and Cassandra on Mesos
 0.1.1-SNAPSHOT.

 On Mon, Jul 6, 2015 at 6:57 AM, Till Toenshoff toensh...@me.com
 wrote:

 Even though Alex has IMHO already “busted” this vote ;) .. THANKS
 ALEX! … ,
 here are my results.

 +1

 OS 10.10.4 (14E46) + Apple LLVM version 6.1.0 (clang-602.0.53) (based
 on LLVM 3.6.0svn), make check - OK
 Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64) + gcc (Ubuntu
 4.8.2-19ubuntu1) 4.8.2, make check - OK




 On Jul 6, 2015, at 3:22 PM, Alex Rukletsov a...@mesosphere.com
 wrote:

 -1

 Compilation error on Mac OS 10.10.4 with clang 3.5, which is
 supported according to release notes.
 More details: https://issues.apache.org/jira/browse/MESOS-2991

 On Mon, Jul 6, 2015 at 11:55 AM, Jörg Schad jo...@mesosphere.io
 wrote:

 P.S. to my prior +1
 Tested on ubuntu-trusty-14.04 including docker.

 On Sun, Jul 5, 2015 at 6:44 PM, Jörg Schad jo...@mesosphere.io
 wrote:

 +1

 On Sun, Jul 5, 2015 at 4:36 PM, Nikolaos Ballas neXus 
 nikolaos.bal...@nexusgroup.com wrote:

  +1



  Sent from my Samsung device


  Original message 
 From: tommy xiao xia...@gmail.com
 Date: 05/07/2015 15:14 (GMT+01:00)
 To: u...@mesos.apache.org
 Subject: Re: [VOTE] Release Apache Mesos 0.23.0 (rc1)

  +1

 2015-07-04 12:32 GMT+08:00 Weitao zhouwtl...@gmail.com:

  +1

 发自我的 iPhone

 在 2015年7月4日，09:41，Marco Massenzio ma...@mesosphere.io 写道：

   +1

  *Marco Massenzio*
 *Distributed Systems Engineer*

 On Fri, Jul 3, 2015 at 12:25 PM, Adam Bordelon 
 a...@mesosphere.io wrote:

 Hello Mesos community,

 Please vote on releasing the following candidate as Apache Mesos
 0.23.0.

 0.23.0 includes the following:

 
  - Per-container network isolation
 - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
 - Dockerized slaves will properly recover Docker containers upon
 failover.

 as well as experimental support for:
  - Fetcher Caching
  - Revocable Resources
  - SSL encryption
  - Persistent Volumes
  - Dynamic Reservations

 The CHANGELOG for the release is available at:

 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0-rc1

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

[Marco Massenzio]

+1

*Marco Massenzio*
*Distributed Systems Engineer*

On Fri, Jul 3, 2015 at 12:25 PM, Adam Bordelon a...@mesosphere.io wrote:

 Hello Mesos community,

 Please vote on releasing the following candidate as Apache Mesos 0.23.0.

 0.23.0 includes the following:

 
 - Per-container network isolation
 - Upgraded minimum required compilers to GCC 4.8+ or clang 3.5+.
 - Dockerized slaves will properly recover Docker containers upon failover.

 as well as experimental support for:
 - Fetcher Caching
 - Revocable Resources
 - SSL encryption
 - Persistent Volumes
 - Dynamic Reservations

 The CHANGELOG for the release is available at:

 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.23.0-rc1

 

 The candidate for Mesos 0.23.0 release is available at:
 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc1/mesos-0.23.0.tar.gz

 The tag to be voted on is 0.23.0-rc1:
 https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.23.0-rc1

 The MD5 checksum of the tarball can be found at:

 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc1/mesos-0.23.0.tar.gz.md5

 The signature of the tarball can be found at:

 https://dist.apache.org/repos/dist/dev/mesos/0.23.0-rc1/mesos-0.23.0.tar.gz.asc

 The PGP key used to sign the release is here:
 https://dist.apache.org/repos/dist/release/mesos/KEYS

 The JAR is up in Maven in a staging repository here:
 https://repository.apache.org/content/repositories/orgapachemesos-1056

 Please vote on releasing this package as Apache Mesos 0.23.0!

 The vote is open until Fri July 10th, 12:00 PDT 2015 and passes if a
 majority of at least 3 +1 PMC votes are cast.

 [ ] +1 Release this package as Apache Mesos 0.23.0
 [ ] -1 Do not release this package because ...

 Thanks,
 -Adam-

Cannot add Resolution to Resolved issues

[Marco Massenzio]

Just heads-up that due to a bug introduced during our recent workflow
change, it's currently not possible to add a Resolution reason when
resolving an issue.

This is tracked here: https://issues.apache.org/jira/browse/INFRA-9910

I'm hoping to have this resolved soon, and will keep folks posted.
In the meantime, please add the Resolution in a comment for the issue, and
once this gets sorted out, we will manually update them.

Thanks for your patience, folks!

*Marco Massenzio*
*Distributed Systems Engineer*

Re: Cannot add Resolution to Resolved issues

[Marco Massenzio]

Awesome, Jake, thanks!

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jul 2, 2015 at 11:49 AM, Vinod Kone vinodk...@gmail.com wrote:

 Thanks Jake!

 I also bulk transitioned the erroneously reopened issues back to resolved.

 On Thu, Jul 2, 2015 at 11:48 AM, Jake Farrell jfarr...@apache.org wrote:

  I updated the workflow to take care of this, should be all set now
 
  -Jake
 
  On Thu, Jul 2, 2015 at 1:54 PM, Marco Massenzio ma...@mesosphere.io
  wrote:
 
   Just heads-up that due to a bug introduced during our recent workflow
   change, it's currently not possible to add a Resolution reason when
   resolving an issue.
  
   This is tracked here: https://issues.apache.org/jira/browse/INFRA-9910
  
   I'm hoping to have this resolved soon, and will keep folks posted.
   In the meantime, please add the Resolution in a comment for the issue,
  and
   once this gets sorted out, we will manually update them.
  
   Thanks for your patience, folks!
  
   *Marco Massenzio*
   *Distributed Systems Engineer*
  
 

Re: [Breaking Change, MESOS-1865] Redirect to the leader master when current master is not a leader.

[Marco Massenzio]

+1

As an API writer (and consumer), this behavior makes sense, and most
clients (notably, Apache HttpClient) would be able to handle this
transparently
(I think - it's been a few years since I messed with it :)

I completely agree that returning a 200 OK with empty (or, worse, stale)
data would be confusing to most clients.

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jul 1, 2015 at 9:54 AM, haosdent haosd...@gmail.com wrote:

 Oh, I got it. I would discuss document this with @adam. Thank you for your
 great advice.

 On Thu, Jul 2, 2015 at 12:33 AM, James DeFelice james.defel...@gmail.com
 wrote:

  Sure, that makes sense. I guess I was wondering if we should document a
  recommended retry-limit threshold for people writing clients - along
 with a
  recommended approach for backing off before retrying again.
 
  On Wed, Jul 1, 2015 at 12:29 PM, haosdent haosd...@gmail.com wrote:
 
   Hi, @James Thank you very much for your good question. My current patch
   could not avoid this problem. I think you could handle this in client
  side,
   give it up or return error when redirect times overflow your define
  limit.
  
   On Thu, Jul 2, 2015 at 12:23 AM, James DeFelice 
  james.defel...@gmail.com
   wrote:
  
In a cluster that's having network problems and the selected leader
 is
flapping is there an upper limit on how many subsequent redirects a
client may expect to receive before it should give up for some period
  of
time? For example:
   
client requests /tasks.json from master1
master1 sends redirect to master2
master1 is elected as leader
client requests /tasks.json from master2
master2 redirects to master1
master3 is elected as leader
client requests /tasks.json from master1
master1 redirects to master3
...
   
   
On Wed, Jul 1, 2015 at 6:09 AM, haosdent haosd...@gmail.com wrote:
   
 Hi, @Tomas Senart. Currently, my patch is to redirect the request
 to
 correct url. For example:

 $ curl -i http://master1:5050/master/tasks.json
 HTTP/1.1 307 Temporary Redirect
 Date: Mon, 01 Jun 2015 06:30:08 GMT
 Location: http://master2:5050/master/tasks.json
 Content-Length: 0

 Assume master1 is not a leader, master 2 is the leader. When you
 send
your
 request to master1, you could recieve the redirection to master2.
 And
   the
 location field in response headers also contains the correct url.
 And
this
 is a single patch, not a precursor for something else. Also thanks
  the
help
 from @adam and @alex. :-)

 On Wed, Jul 1, 2015 at 12:12 PM, Tomás Senart to...@mesosphere.io
 
wrote:

  Hi Haosdent,
 
  Thanks for the heads up. Would you be able to share the rationale
  for
 this
  change? Is it a precursor for something else?
 
  Best,
  Tomás
  On Tue 30 Jun 2015 at 19:24 haosdent haosd...@gmail.com wrote:
 
   Hi All,
  
   We intend to introduce a breaking change[1] in the http
  endpoints.
For
   below http endpoints, when user request to a master which is
 not
  a
  leader,
   user would got a 302 redirect to the leader master.
   * /slaves
   * /state
   * /stateSummary
   * /roles
   * /teardown
   * /tasks
   For other endpoints in master, the behaviour is not change. If
  your
   existing framework relied on this behaviour, I suggest add a
  logic
   to
   handle 302 redirect response. Let me know if you have any
  queries/concerns.
   Thank you very much.
  
   Links:
   [1]  Tracking JIRA:
   https://issues.apache.org/jira/browse/MESOS-1865
  
  
   --
   Best Regards,
   Haosdent Huang
  
 



 --
 Best Regards,
 Haosdent Huang

   
   
   
--
James DeFelice
585.241.9488 (voice)
650.649.6071 (fax)
   
  
  
  
   --
   Best Regards,
   Haosdent Huang
  
 
 
 
  --
  James DeFelice
  585.241.9488 (voice)
  650.649.6071 (fax)
 



 --
 Best Regards,
 Haosdent Huang

Re: Update minimum required automake version to 1.13

[Marco Massenzio]

On Thu, Jun 25, 2015 at 3:27 PM, Cody Maloney c...@mesosphere.io wrote:

 CentOS 5 and 6 don't come out of the box with a new enough version of GCC
 to compile Mesos. Already they need to upgrade that to compile Mesos. I
 don't see how adding another upgrade when they have to do GCC is overly
 onerous / should require lots of compatibility hacks to make unnecessary.


+1
Different story for production servers; but build/dev machines are supposed
to use modern build/dev tools and environments (unless supporting an older
toolchain is a specific need for the project).



 On Thu, Jun 25, 2015 at 3:17 PM Kapil Arya ka...@mesosphere.io wrote:

  It's not available for CentOS 5/6 or the previous debian stable. I guess
  since we still want to keep supporting the older distros, one possibility
  is to create a patch for configure.ac which is applied during
 ./bootstrap
  after detecting the automake version. Is this an acceptable solution?
 
  If this works, then we can decide on whether we want to patch it for
 older
  ( 1.13) or newer (= 1.13) automake version. Is there a preference
 there?
 
  Kapil
 
  On Thu, Jun 25, 2015 at 2:30 PM, Jake Farrell jfarr...@apache.org
 wrote:
 
   we encountered a lot of issues in thrift between all the backwards
   incompatible changes automake had in 1.12 to 1.14 and trying to support
  all
   the default versions across different distros. due to this we are
  switching
   to cmake as well
  
   -Jake
  
  
   On Thu, Jun 25, 2015 at 1:46 PM, Benjamin Mahler 
   benjamin.mah...@gmail.com
   wrote:
  
What about CentOS 5 and 6?
https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule
   
Also, how does this interact with the effort to use CMake?
https://issues.apache.org/jira/browse/MESOS-898
   
On Thu, Jun 25, 2015 at 10:40 AM, Kapil Arya ka...@mesosphere.io
   wrote:
   
 Hi All,

 First off, I am not sure if we record the minimum required version
 of
 automake/autoconf somewhere in the documentation.

 Having said that, I want to propose to move to automake 1.13 in
 order
   to
be
 able to use the AM_EXTRA_RECURSIVE_TARGETS macro which allows us
 to
add a
 test target to just build the test and not run it. The issue is
   tracked
 at https://issues.apache.org/jira/browse/MESOS-2273 and the
corresponding
 RRs have received some ship-its.

 Best,
 Kapil

 ==
 Compatibility notes:
 Automake 1.13 came out in 2013 and here is the compatibility status
  for
 leading distros:
 * Debian: Since 8.0 [1].
 * Ubuntu: Since 13.10 [2].
 * Fedora: Since Fedora 20 [3].
 * Centos: Since 7.0 [4].

 1. https://packages.debian.org/jessie/automake
 2. https://launchpad.net/ubuntu/trusty/+package/automake
 3. https://apps.fedoraproject.org/packages/automake
 4. http://mirror.centos.org/centos/7/os/x86_64/Packages/

   
  
 

Re: Project wide updates to #include statements

[Marco Massenzio]

As I mentioned in the review that Paul submitted, I've been working on
cpplint.py to make it more Mesos-friendly.
I have also submitted a few Pull Requests
https://github.com/google/styleguide/pulls to the original github repo,
but got neither love nor attention.

My fork is here: https://github.com/massenz/styleguide
and the code in the `master` branch (
https://github.com/massenz/styleguide/tree/master) has all my changes; it
currently works well with the existing code (in that, submitted, valid
Mesos code does not raise errors) apart from the opening brace on a newline
for multi-line method declarations.

Love to get contributions and pull requests folks, feel free to submit!

An example CPPLINT.cfg that works with the code in `master` is something
like this:

$ cat CPPLINT.cfg
# Apache Mesos cpplint custom file

extensions=cpp,hpp
access_keywords_indent=0
headers=h,hpp
custom_headers=mesos,process,stout
set braces_newline

PS - am I the only one to find it hilarious that code that supposedly
checks on style correctness is written in some of the least readable, badly
PEP8-violating Python? :)

*Marco Massenzio*
*Distributed Systems Engineer*

On Thu, Jun 25, 2015 at 3:18 PM, Paul Brett pbr...@twitter.com.invalid
wrote:

 ​The style guide prescribes the order of header file inclusions for the
 project and requires that we #include or make explicit forward declarations
 for any functions we use, however we were only  enforcing this at review
 time manually and not commit time.  I would like to turn on the checks at
 commit time, so I am in the process of raising changes against stout,
 libprocess and mesos to bring the code base into compliance.  Once this is
 completed, I propose to update cpplint.py and mesos-style.py to enforce the
 style guide.

 Anyone interested can comment on the following tickets:

 https://issues.apache.org/jira/browse/MESOS-2926 Extend
 mesos-style.py/cpplint.py to check #include files
 https://issues.apache.org/jira/browse/MESOS-2927 Update mesos #include
 headers
 https://issues.apache.org/jira/browse/MESOS-2928 Update stout #include
 headers
 https://issues.apache.org/jira/browse/MESOS-2929 Update libprocess
 #include
 headers
 ​

 -- Paul Brett

Re: Mesos Jira workflow

[Marco Massenzio]

Folks,

thanks to Tony Stevenson in INFRA, our Mesos workflow
https://issues.apache.org/jira/secure/attachment/12740454/Mesos%20Workflow.png
now reflects the one we arrived at.

Due to some quirks in Jira, the transitions buttons shown at the top of the
issue may not always reflect a valid transition (we're looking into this
with Tony): for example, an Accepted story has a Stop Progress button
(makes no sense); if you hit it, you'll get an error message - which is
correct, but annoying (also, really, we would like a Start Progress
button!).

For the time being, please use the Workflow button (which offers a subset
of possible states to transition to) to move Issues across states.

We'll keep you updated on progress.
The INFRA ticket to follow is here:
https://issues.apache.org/jira/browse/INFRA-9846


*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io wrote:

 Folks,

 Please take a look at MESOS-2806: in a nutshell, our current workflow is
 rather convoluted and brings about a host of issues, when managing tasks'
 status transitions (detailed in the Jira - see screenshots there).

 This is what it currently looks like:

 [image: Inline image 1]

 (spaghetti workflow? :)

 I would propose to simplify it to the following:

 [image: Inline image 2]

 I'm sure we can think up all sorts of corner cases, but I would submit
 that simplicity would trump complexity and allow us to track progress (or
 lack thereof) of stories/tasks/bugs in a much more punctual manner.

 Anyone against it?

 *Marco Massenzio*
 *Distributed Systems Engineer*

[Breaking Change 0.24 Upgrade path] ZooKeeper MasterInfo change.

[Marco Massenzio]

Folks,

as heads-up, we are planning to convert the format of the MasterInfo
information stored in ZooKeeper from the Protocol Buffer binary format to
JSON - this is in conjunction with the HTTP API development, to allow
frameworks *not* to depend on libmesos and other binary dependencies to
interact with Mesos Master nodes.

*NOTE* - there is no change in 0.23 (so any Master/Slave/Framework that is
currently working in 0.22 *will continue to work* in 0.23 too) but as of
Mesos 0.24, frameworks and other clients relying on the binary format will
break.

The details of the design are in this Google Doc:
https://docs.google.com/document/d/1i2pWJaIjnFYhuR-000NG-AC1rFKKrRh3Wn47Y2G6lRE/edit

the actual work is detailed in MESOS-2340:
https://issues.apache.org/jira/browse/MESOS-2340

and the patch (and associated test) are here:
https://reviews.apache.org/r/35571/
https://reviews.apache.org/r/35815/

*Marco Massenzio*
*Distributed Systems Engineer*

Re: [Breaking Change 0.24, MESOS 1988] Silently ignore launchTask/acceptOffers calls when disconnected

[Marco Massenzio]

Hey Dave,

sorry about the confusion, but the deprecation cycle is happening: this
change won't take place until 0.24 is out (as the title of this email
states); this will obviously be captured in the update notes from 0.23 to
0.24: as you correctly pointed out, we wanted to give folks very early
notice of the impending change.

The conversation has actually taken place on the MESOS-1988 ticket (
https://issues.apache.org/jira/browse/MESOS-1988) which also gets forwarded
to the issues@ mailing list; this was also proposed and shepherded by
Vinod, so I would recommend you follow up with him if you want to further
clarify matters.

In our limited understanding, this was an undocumented behavior so we
would expect the impact to be minor and the suggested solution to be a more
desirable behavior.

Please also feel free to reach out to Ben H to discuss in greater depth.

Thanks for being vigilant!

*Marco Massenzio*
*Distributed Systems Engineer*

On Mon, Jun 22, 2015 at 9:38 PM, Dave Lester d...@davelester.org wrote:

 Hi Anand,

 Was there a discussion thread on this?

 Breaking changes should only be introduced when the community has had a
 chance to discuss its impact and any necessary deprecation cycle -- I
 didn't see a discussion on the relevant thread, but perhaps I missed
 something?

 Thanks,
 Dave

 On Mon, Jun 22, 2015, at 05:23 PM, Anand Mazumdar wrote:
  Hi All,
 
  We intend to introduce a breaking change [1] in the driver to silently
  ignore launchTasks/acceptOffers(…) calls when disconnected from the
  master in 0.24. The previous behavior was to send out “TASK_LOST”
  messages since there was no way to know that these task launches were
  dropped. However , with the advent of Task Reconciliation, this feature
  is redundant. Other calls like killTask/requestResource et al already had
  this behavior.
 
  If your existing framework relied on this behavior, I would encourage you
  to use the Task Reconciliation API [2] in lieu of this feature/hack. Let
  me know if you have any queries/concerns.
 
  Links:
  [1] Tracking JIRA: https://issues.apache.org/jira/browse/MESOS-1988
  https://issues.apache.org/jira/browse/MESOS-1988
  [2] Task Reconciliation API :
  http://mesos.apache.org/documentation/latest/reconciliation/
  http://mesos.apache.org/documentation/latest/reconciliation/
 
  -anand

Re: Mesos Jira workflow

[Marco Massenzio]

Inline...

On Tue, Jun 9, 2015 at 4:56 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 I don't have comment permissions on the doc, but it looks like you omitted
 a way to go from Reviewable - In Progress, which we often do when the
 reviewee has more work to do before being ready for additional reviews, for
 example.


Great catch - added!
(called it `fix` - anyone has any suggestions for something more
suggestive?)



 I'm not sure what 'Closed' is supposed to represent, what does it mean to
 go from Resolved to Closed?


Great question! I don't know (it was there, and I thought it worth leaving)
In my previous experience, we used it to mark it as QA Certified

In other words - developer(s) would run and test locally (or in Jenkins, or
whatever) and mark the bug/story as Resolved - but it would only be
declared Closed (and make it to the Release Notes) once QA had it tested
against regressions, etc.

I'm happy to remove it from the workflow (assuming Jira allows it) or we
can leave it there.


 On Tue, Jun 9, 2015 at 3:41 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Hi Vinod,
 
  thanks for super-quick reply.
  We've already been through this in our internal (Mesosphere) Jira (on a
  completely different topic) so I know that this can be done, if we use
 our
  own custom Mesos workflow (here:
 
 https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows
 )
  which I think we already do.
 
  I would probably need to be given adequate permissions to modify it
  (avoiding to mess up in the process the entirety of ASF :)
  Once we agree that the proposed one works for folks here, I'll work with
  Jake and Infra folks, and figure out how to implement.
 
  Thanks!
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
  On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote:
 
  +jake
 
  Marco, this sounds good to me. Have you looked into see if JIRA allows
 us
  to constrain ourselves to this workflow? If yes, the next step would be
 to
  work with ASF infra to see if they are ok with us adopting a new
 workflow.
  IIRC, there are some JIRA settings that are global to all ASF projects
 and
  hence can't be customized.
 
  On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io
  wrote:
 
  Hadn't realized that the mailing list forwarder would make the images
  unavailable, apologies about that.
 
  I've created this Google Doc
  
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
 
  which should be open and accessible.
 
  Again, please let me know if anyone feels strongly that we should keep
  the current workflow.
  Thanks!
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
  On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io
  wrote:
 
  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current workflow
  is rather convoluted and brings about a host of issues, when managing
  tasks' status transitions (detailed in the Jira - see screenshots
 there).
 
  This is what it currently looks like:
 
  [image: Inline image 1]
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
  [image: Inline image 2]
 
  I'm sure we can think up all sorts of corner cases, but I would submit
  that simplicity would trump complexity and allow us to track progress
 (or
  lack thereof) of stories/tasks/bugs in a much more punctual manner.
 
  Anyone against it?
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
 
 
 
 

Re: Mesos Jira workflow

[Marco Massenzio]

Thanks, everyone, for your suggestions: quick feedback was much appreciated!

I've updated the Google Doc, I think we're in good shape, I'll wait until
Friday to hear if anyone has still objections, then I'll work with Jake
(thanks for offer to help!) to implement it.

*Marco Massenzio*
*Distributed Systems Engineer*

On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io
wrote:


 On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote:

 Very helpful Marco… I like the idea of tightening our JIRA workflow.

 +1 removing “closed

 done


 +1 “reviewable” back to in progress — to me this is a very helpful
 signal for longer lasting comment addressing

 done


 +1 making sure that “accepted is the gatekeeper and includes assigning
 the maintainer as a default shepherd — should we even go as far as to
 prevent  “assigning” issues that have not gotten “accepted” and “shepherd
 assigned” ?


 let's not gate fixing the workflow to my achieving the next level of
 Jira-Wizardry :)
 the goal can be achieved by education (and enforcement of the policy)

 I am totally in favor of asking folks NOT to work on non-accepted stories
 (or, conversely, if they come across issues that are NOT accepted, but want
 to do work and/or investigation, to assign to themselves and move to
 accepted state).

 +1 removing “reopened as it has no extra value for us

 it's history!


 Resolving without accepting to me sounds like a shortcut that we might
 want to prevent as it could be a bad example?

  On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io
 wrote:
 
  Hadn't realized that the mailing list forwarder would make the images
 unavailable, apologies about that.
 
  I've created this Google Doc 
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
 which should be open and accessible.
 
  Again, please let me know if anyone feels strongly that we should keep
 the current workflow.
  Thanks!
 
  Marco Massenzio
  Distributed Systems Engineer
 
  On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io
 mailto:ma...@mesosphere.io wrote:
  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current workflow
 is rather convoluted and brings about a host of issues, when managing
 tasks' status transitions (detailed in the Jira - see screenshots there).
 
  This is what it currently looks like:
 
 
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
 
 
  I'm sure we can think up all sorts of corner cases, but I would submit
 that simplicity would trump complexity and allow us to track progress (or
 lack thereof) of stories/tasks/bugs in a much more punctual manner.
 
  Anyone against it?
 
  Marco Massenzio
  Distributed Systems Engineer
 

Re: Mesos Jira workflow

[Marco Massenzio]

On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote:

 Very helpful Marco… I like the idea of tightening our JIRA workflow.

 +1 removing “closed

done


 +1 “reviewable” back to in progress — to me this is a very helpful
 signal for longer lasting comment addressing

done


 +1 making sure that “accepted is the gatekeeper and includes assigning
 the maintainer as a default shepherd — should we even go as far as to
 prevent  “assigning” issues that have not gotten “accepted” and “shepherd
 assigned” ?


let's not gate fixing the workflow to my achieving the next level of
Jira-Wizardry :)
the goal can be achieved by education (and enforcement of the policy)

I am totally in favor of asking folks NOT to work on non-accepted stories
(or, conversely, if they come across issues that are NOT accepted, but want
to do work and/or investigation, to assign to themselves and move to
accepted state).

+1 removing “reopened as it has no extra value for us

 it's history!


 Resolving without accepting to me sounds like a shortcut that we might
 want to prevent as it could be a bad example?

  On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io
 wrote:
 
  Hadn't realized that the mailing list forwarder would make the images
 unavailable, apologies about that.
 
  I've created this Google Doc 
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
 which should be open and accessible.
 
  Again, please let me know if anyone feels strongly that we should keep
 the current workflow.
  Thanks!
 
  Marco Massenzio
  Distributed Systems Engineer
 
  On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io
 mailto:ma...@mesosphere.io wrote:
  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current workflow is
 rather convoluted and brings about a host of issues, when managing tasks'
 status transitions (detailed in the Jira - see screenshots there).
 
  This is what it currently looks like:
 
 
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
 
 
  I'm sure we can think up all sorts of corner cases, but I would submit
 that simplicity would trump complexity and allow us to track progress (or
 lack thereof) of stories/tasks/bugs in a much more punctual manner.
 
  Anyone against it?
 
  Marco Massenzio
  Distributed Systems Engineer
 

Re: Mesos Jira workflow

[Marco Massenzio]

inline...

On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman b...@eecs.berkeley.edu
wrote:

 +1 This sounds great to me Marco. I love eliminating Reopened, as well as
 simplifying (constraining) other transitions. I couple of quick questions:

 Why does stoping progress go from In Progress back to Open instead of
 Accepted? Seems like it's still an Accepted issue just not being worked on.


I thought about it and it occurs to me that there are three reasons why one
would Stop Progress:

   1. I haven't got time, and more important stuff came along (this is the
   case your question seems to imply)
   2. I looked into it, and it really doesn't seem worth/desirable to do,
   ever (covered in Resolved - won't fix)
   3. I looked into it, and I have my doubts this may ever be desirable,
   but I'll leave it to others to decide (the current Stop Progress)

I've added a Pause Progress transition (back to Accepted) that covers
case #1 - would this work?


 Can we resolve or close something directly from Open? For example, issues
 we're never going to work on or are duplicates or already fixed, etc.


Sure - added.


 Do we need both Resolved and Closed? This has come up in the past, we tend
 to close issues after we cut a release with them, but it's kind of an extra
 step that I'm not convinced we really need to do.


Got rid of Closed.
As both Bens don't like it - I think it was doomed :)



 On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io
 wrote:

  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current workflow is
  rather convoluted and brings about a host of issues, when managing tasks'
  status transitions (detailed in the Jira - see screenshots there).
 
  This is what it currently looks like:
 
  [image: Inline image 1]
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
  [image: Inline image 2]
 
  I'm sure we can think up all sorts of corner cases, but I would submit
  that simplicity would trump complexity and allow us to track progress (or
  lack thereof) of stories/tasks/bugs in a much more punctual manner.
 
  Anyone against it?
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 

Re: Mesos Jira workflow

[Marco Massenzio]

inline...

On Wed, Jun 10, 2015 at 12:44 AM, Adam Bordelon a...@mesosphere.io wrote:

 +1 to removing Closed. In other projects, I've seen Resolved mean that a
 supposed fix has been committed, and Closed means that somebody (QA?
 Reporter?) has verified the fix, but we don't wait for verification, so
 it's probably pointless for us.


yep, gone.


 +1 to removing Reopened, and just going back to Open/Accepted instead.
 +1 to BenH's request to be able to Resolve from any status, so that an Open
 issue can be quickly resolved as Duplicate or Won't Fix.


added.


 We'll need to continue educating users about what Accepted means,
 especially if it becomes a required transition. Is there a way that we can
 require the Shepherd field to be filled out before something can be
 Accepted?


I don't think there is (and, to be honest, I am hesitant to require a
Shepherd for the transition:
it seems too high a bar - I'd suggest to require a Shepherd for the
transition to In Progress).

But totally +1 on educating the community about the semantics of Accepted
(especially,
the requirement of clear, well-written feature descriptions/bug reports)


 On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman b...@eecs.berkeley.edu
 wrote:

  +1 This sounds great to me Marco. I love eliminating Reopened, as well as
  simplifying (constraining) other transitions. I couple of quick
 questions:
 
  Why does stoping progress go from In Progress back to Open instead of
  Accepted? Seems like it's still an Accepted issue just not being worked
 on.
 
  Can we resolve or close something directly from Open? For example, issues
  we're never going to work on or are duplicates or already fixed, etc.
 
  Do we need both Resolved and Closed? This has come up in the past, we
 tend
  to close issues after we cut a release with them, but it's kind of an
 extra
  step that I'm not convinced we really need to do.
 
 
 
  On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io
  wrote:
 
  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current workflow is
  rather convoluted and brings about a host of issues, when managing
 tasks'
  status transitions (detailed in the Jira - see screenshots there).
 
  This is what it currently looks like:
 
  [image: Inline image 1]
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
  [image: Inline image 2]
 
  I'm sure we can think up all sorts of corner cases, but I would submit
  that simplicity would trump complexity and allow us to track progress
 (or
  lack thereof) of stories/tasks/bugs in a much more punctual manner.
 
  Anyone against it?
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
 

Re: Introduction / Request to be added to Jira committers

[Marco Massenzio]

Hey Oliver,

thanks for the patch and really glad to hear that Mesos just works for
you!
As you can imagine, we'd love to add Uber to the Powered by page:
http://mesos.apache.org/documentation/latest/powered-by-mesos/

Do you think that would be possible?

Welcome to the club!

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jun 9, 2015 at 6:47 PM, Oliver Nicholas b...@uber.com wrote:

 Hey Tim.  We're not *currently* planning Storm work (I think it just
 works for us at the moment), but I suspect as we move more and more stuff
 over Mesos and start to expand our clusters and add complexity to our
 configurations, we'll have work to do on that side as well.

 -o

 On Tue, Jun 9, 2015 at 6:43 PM, Timothy Chen tnac...@gmail.com wrote:

  Hi Oliver,
 
  It's great to hear you're using the Storm over Mesos framework too! I
  think there are lots of improvements that can be made there, are you
  guys planning to help work on that framework as well?
 
  Tim
 
  On Tue, Jun 9, 2015 at 6:37 PM, Oliver Nicholas b...@uber.com wrote:
   Hello Folks,
  
   Name's Oliver Nicholas, I'm a sometimes-manager, sometimes-engineer
 here
  at
   Uber.  We've been running some Storm jobs over Mesos for a year or two
  but
   are looking into moving larger workloads under Marathon now, and
 ironing
   out some kinks along the way.  My first patch is pretty
 straightforward,
   and I'd love to get it committed so I can get on to the rest of them.
  
   My Jira username is bigo.
  
   https://issues.apache.org/jira/browse/MESOS-1825
   https://reviews.apache.org/r/35270/
  
   Thanks!
   -o
  
   --
   *bigo* / oliver nicholas | staff engineer, infrastructure | uber
   technologies, inc.
 



 --
 *bigo* / oliver nicholas | staff engineer, infrastructure | uber
 technologies, inc.

Re: Mesos Jira workflow

[Marco Massenzio]

On Wed, Jun 10, 2015 at 6:44 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 Don't forget that folks accidentally do things all the time in JIRA,


or in life :)
eh eh I never forget that


 so if
 you fence off the ability to go back you make an accident permanent, or
 does JIRA have some undo support I'm unaware of?


I am pretty sure that we can alter the state of a given issue to move it
back to 'Open' (even if, as you pointed out, we need to take a detour via
'in progress') - but let me do some investigation and figure this one out.

Thanks!



 On Wed, Jun 10, 2015 at 6:33 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler 
  benjamin.mah...@gmail.com
  wrote:
 
   To go from accepted to open you need to go through in progress?
  
   That part wasn't changed from before?
  Anyways, why would you ever want to do that?
 
  This means that, at some point we looked at something, thought we would
  want to do that (at some point in future) then, eventually, changed our
  mind (we no longer want to do it) but will think some more at some other
  future point and (maybe) re-accept it?
 
  This seems an unlikely scenario? more likely, you figured out it wasn't a
  good idea after all (or maybe it turned out to be a duplicate - or some
  other features took the problem away) and we can move directly to
  resolved.
 
  Granted, we can obviously add an unaccept transition, but I would much
  prefer to keep this simple to avoid confusing people.
  (and, as you correctly pointed out, there is a path back to 'Open' if we
  really want to).
 
  On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io
   wrote:
  
Thanks, everyone, for your suggestions: quick feedback was much
appreciated!
   
I've updated the Google Doc, I think we're in good shape, I'll wait
  until
Friday to hear if anyone has still objections, then I'll work with
 Jake
(thanks for offer to help!) to implement it.
   
*Marco Massenzio*
*Distributed Systems Engineer*
   
On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio 
 ma...@mesosphere.io
wrote:
   

 On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com
wrote:

 Very helpful Marco… I like the idea of tightening our JIRA
 workflow.

 +1 removing “closed

 done


 +1 “reviewable” back to in progress — to me this is a very
 helpful
 signal for longer lasting comment addressing

 done


 +1 making sure that “accepted is the gatekeeper and includes
   assigning
 the maintainer as a default shepherd — should we even go as far as
  to
 prevent  “assigning” issues that have not gotten “accepted” and
“shepherd
 assigned” ?


 let's not gate fixing the workflow to my achieving the next level
 of
 Jira-Wizardry :)
 the goal can be achieved by education (and enforcement of the
 policy)

 I am totally in favor of asking folks NOT to work on non-accepted
   stories
 (or, conversely, if they come across issues that are NOT accepted,
  but
want
 to do work and/or investigation, to assign to themselves and move
 to
 accepted state).

 +1 removing “reopened as it has no extra value for us

 it's history!


 Resolving without accepting to me sounds like a shortcut that we
  might
 want to prevent as it could be a bad example?

  On Jun 10, 2015, at 12:00 AM, Marco Massenzio 
  ma...@mesosphere.io
 wrote:
 
  Hadn't realized that the mailing list forwarder would make the
   images
 unavailable, apologies about that.
 
  I've created this Google Doc 

   
  
 
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit

 which should be open and accessible.
 
  Again, please let me know if anyone feels strongly that we
 should
   keep
 the current workflow.
  Thanks!
 
  Marco Massenzio
  Distributed Systems Engineer
 
  On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio 
   ma...@mesosphere.io
 mailto:ma...@mesosphere.io wrote:
  Folks,
 
  Please take a look at MESOS-2806: in a nutshell, our current
   workflow
 is rather convoluted and brings about a host of issues, when
  managing
 tasks' status transitions (detailed in the Jira - see screenshots
there).
 
  This is what it currently looks like:
 
 
 
  (spaghetti workflow? :)
 
  I would propose to simplify it to the following:
 
 
 
  I'm sure we can think up all sorts of corner cases, but I would
   submit
 that simplicity would trump complexity and allow us to track
  progress
(or
 lack thereof) of stories/tasks/bugs in a much more punctual
 manner.
 
  Anyone against it?
 
  Marco Massenzio
  Distributed Systems Engineer
 



   
  
 

Re: Mesos Jira workflow

[Marco Massenzio]

On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com
wrote:

 To go from accepted to open you need to go through in progress?

 That part wasn't changed from before?
Anyways, why would you ever want to do that?

This means that, at some point we looked at something, thought we would
want to do that (at some point in future) then, eventually, changed our
mind (we no longer want to do it) but will think some more at some other
future point and (maybe) re-accept it?

This seems an unlikely scenario? more likely, you figured out it wasn't a
good idea after all (or maybe it turned out to be a duplicate - or some
other features took the problem away) and we can move directly to
resolved.

Granted, we can obviously add an unaccept transition, but I would much
prefer to keep this simple to avoid confusing people.
(and, as you correctly pointed out, there is a path back to 'Open' if we
really want to).

On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

  Thanks, everyone, for your suggestions: quick feedback was much
  appreciated!
 
  I've updated the Google Doc, I think we're in good shape, I'll wait until
  Friday to hear if anyone has still objections, then I'll work with Jake
  (thanks for offer to help!) to implement it.
 
  *Marco Massenzio*
  *Distributed Systems Engineer*
 
  On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io
  wrote:
 
  
   On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com
  wrote:
  
   Very helpful Marco… I like the idea of tightening our JIRA workflow.
  
   +1 removing “closed
  
   done
  
  
   +1 “reviewable” back to in progress — to me this is a very helpful
   signal for longer lasting comment addressing
  
   done
  
  
   +1 making sure that “accepted is the gatekeeper and includes
 assigning
   the maintainer as a default shepherd — should we even go as far as to
   prevent  “assigning” issues that have not gotten “accepted” and
  “shepherd
   assigned” ?
  
  
   let's not gate fixing the workflow to my achieving the next level of
   Jira-Wizardry :)
   the goal can be achieved by education (and enforcement of the policy)
  
   I am totally in favor of asking folks NOT to work on non-accepted
 stories
   (or, conversely, if they come across issues that are NOT accepted, but
  want
   to do work and/or investigation, to assign to themselves and move to
   accepted state).
  
   +1 removing “reopened as it has no extra value for us
  
   it's history!
  
  
   Resolving without accepting to me sounds like a shortcut that we might
   want to prevent as it could be a bad example?
  
On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io
   wrote:
   
Hadn't realized that the mailing list forwarder would make the
 images
   unavailable, apologies about that.
   
I've created this Google Doc 
  
 
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
  
   which should be open and accessible.
   
Again, please let me know if anyone feels strongly that we should
 keep
   the current workflow.
Thanks!
   
Marco Massenzio
Distributed Systems Engineer
   
On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio 
 ma...@mesosphere.io
   mailto:ma...@mesosphere.io wrote:
Folks,
   
Please take a look at MESOS-2806: in a nutshell, our current
 workflow
   is rather convoluted and brings about a host of issues, when managing
   tasks' status transitions (detailed in the Jira - see screenshots
  there).
   
This is what it currently looks like:
   
   
   
(spaghetti workflow? :)
   
I would propose to simplify it to the following:
   
   
   
I'm sure we can think up all sorts of corner cases, but I would
 submit
   that simplicity would trump complexity and allow us to track progress
  (or
   lack thereof) of stories/tasks/bugs in a much more punctual manner.
   
Anyone against it?
   
Marco Massenzio
Distributed Systems Engineer
   
  
  
  
 

Mesos Jira workflow

[Marco Massenzio]

Folks,

Please take a look at MESOS-2806: in a nutshell, our current workflow is
rather convoluted and brings about a host of issues, when managing tasks'
status transitions (detailed in the Jira - see screenshots there).

This is what it currently looks like:

[image: Inline image 1]

(spaghetti workflow? :)

I would propose to simplify it to the following:

[image: Inline image 2]

I'm sure we can think up all sorts of corner cases, but I would submit that
simplicity would trump complexity and allow us to track progress (or lack
thereof) of stories/tasks/bugs in a much more punctual manner.

Anyone against it?

*Marco Massenzio*
*Distributed Systems Engineer*

Re: Mesos Jira workflow

[Marco Massenzio]

Hi Vinod,

thanks for super-quick reply.
We've already been through this in our internal (Mesosphere) Jira (on a
completely different topic) so I know that this can be done, if we use our
own custom Mesos workflow (here:
https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows)
which I think we already do.

I would probably need to be given adequate permissions to modify it
(avoiding to mess up in the process the entirety of ASF :)
Once we agree that the proposed one works for folks here, I'll work with
Jake and Infra folks, and figure out how to implement.

Thanks!

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote:

 +jake

 Marco, this sounds good to me. Have you looked into see if JIRA allows us
 to constrain ourselves to this workflow? If yes, the next step would be to
 work with ASF infra to see if they are ok with us adopting a new workflow.
 IIRC, there are some JIRA settings that are global to all ASF projects and
 hence can't be customized.

 On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

 Hadn't realized that the mailing list forwarder would make the images
 unavailable, apologies about that.

 I've created this Google Doc
 https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
 which should be open and accessible.

 Again, please let me know if anyone feels strongly that we should keep
 the current workflow.
 Thanks!

 *Marco Massenzio*
 *Distributed Systems Engineer*

 On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io
 wrote:

 Folks,

 Please take a look at MESOS-2806: in a nutshell, our current workflow is
 rather convoluted and brings about a host of issues, when managing tasks'
 status transitions (detailed in the Jira - see screenshots there).

 This is what it currently looks like:

 [image: Inline image 1]

 (spaghetti workflow? :)

 I would propose to simplify it to the following:

 [image: Inline image 2]

 I'm sure we can think up all sorts of corner cases, but I would submit
 that simplicity would trump complexity and allow us to track progress (or
 lack thereof) of stories/tasks/bugs in a much more punctual manner.

 Anyone against it?

 *Marco Massenzio*
 *Distributed Systems Engineer*

Re: Mesos Jira workflow

[Marco Massenzio]

Hadn't realized that the mailing list forwarder would make the images
unavailable, apologies about that.

I've created this Google Doc
https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit
which should be open and accessible.

Again, please let me know if anyone feels strongly that we should keep the
current workflow.
Thanks!

*Marco Massenzio*
*Distributed Systems Engineer*

On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io wrote:

 Folks,

 Please take a look at MESOS-2806: in a nutshell, our current workflow is
 rather convoluted and brings about a host of issues, when managing tasks'
 status transitions (detailed in the Jira - see screenshots there).

 This is what it currently looks like:

 [image: Inline image 1]

 (spaghetti workflow? :)

 I would propose to simplify it to the following:

 [image: Inline image 2]

 I'm sure we can think up all sorts of corner cases, but I would submit
 that simplicity would trump complexity and allow us to track progress (or
 lack thereof) of stories/tasks/bugs in a much more punctual manner.

 Anyone against it?

 *Marco Massenzio*
 *Distributed Systems Engineer*