[RESULT] [VOTE] Release Apache Mesos 1.2.3 (rc1)

[Adam Bordelon]

Hi all,

The vote for Mesos 1.2.3 (rc1) has passed with the following votes.

+1 (Binding)
--
Vinod Kone
Adam B
Benjamin Mahler

There were no 0 or -1 votes.

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

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=1.2.3

The mesos-1.2.3.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, Nov 29, 2017 at 6:32 PM, Benjamin Mahler  wrote:

> +1 (binding)
>
> make check on macOS 10.13.1
>
> On Wed, Nov 29, 2017 at 9:17 PM, Adam Bordelon  wrote:
>
>> +1 (binding)
>>
>> Passed all tests in DC/OS integration CI, with a bump to 1.2.x at
>> f8706e5, just one changelog update before 1.2.3-rc1.
>> https://github.com/dcos/dcos/pull/2104#pullrequestreview-79333676
>>
>> On Tue, Nov 21, 2017 at 2:46 PM, Vinod Kone  wrote:
>>
>>> +1 (binding)
>>>
>>> Tested on ASF CI. The failures are due to 2 issues 1) perf core dump
>>>  which was fixed in
>>> 1.5.0 and 2) flaky oversubscription test
>>>  also fixed in 1.5.0.
>>>
>>> *Revision*: 7559c9352c78912526820f6222ed2b17ad3b19cf
>>>
>>>- refs/tags/1.2.3-rc1
>>>
>>> Configuration Matrix gcc clang
>>> centos:7 --verbose --enable-libevent --enable-ssl autotools
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> cmake
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> --verbose autotools
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> cmake
>>> [image: Success]
>>> 
>>> [image: Not run]
>>> ubuntu:14.04 --verbose --enable-libevent --enable-ssl autotools
>>> [image: Failed]
>>> 
>>> [image: Failed]
>>> 
>>> cmake
>>> [image: Failed]
>>> 
>>> [image: Success]
>>> 
>>> --verbose autotools
>>> [image: Success]
>>> 
>>> [image: Failed]
>>> 
>>> cmake
>>> [image: Success]
>>> 

Mesos 1.5.0 Release

[Gilbert Song]

Folks,

It is time for Mesos 1.5.0 release. I am the release manager.

We plan to cut the rc1 in next couple weeks. Please start to wrap up
patches if you are contributing or shepherding any issue. If you expect any
particular JIRA for this new release, please set *Target Version* as "
*1.5.0"* and mark it as "*Blocker*" priority.

The dashboard for Mesos 1.5.0 will be posted in this thread soon.

Cheers,
Gilbert

Fwd: Request for Participation: The Right Metrics for the Right Project

[Benjamin Mahler]

FYI If anyone is able to look into setting this up that would be great!

-- Forwarded message --
From: Daniel Gruno 
Date: Mon, Nov 27, 2017 at 10:26 AM
Subject: Request for Participation: The Right Metrics for the Right Project
To: d...@kibble.apache.org


Hi there, fellow Apache projects!

The Apache Kibble project serves as a practical implementation of
metrics deemed to be helpful for open source projects trying to
understand where their project is, was, and is headed.

As such, we need help in determining which metrics projects either
already use and consider useful for measuring project health or which
metrics they would love to have and use.

We are looking for projects interested in participating in the Kibble
demo instance ( https://demo.kibble.apache.org/ ) and sending feedback
to the Kibble project on which parts they find useful, which elements
they find useless and which ideas they would love to see implemented to
better gauge the health and activity of their project.

Initially we are looking for Apache projects to help out, but we will
later on expand this to other open source organizations and projects.

Projects that participate will be added to the demo instance and scanned
on a regular basis so the data can be used for reports and analysis.
The Kibble PMC will ensure that the correct sources are added, but you
are of course welcome to help identify which parts need analyzing.

How to participate:

- Join the d...@kibble.apache.org mailing list and let us know if your
project is interested in joining the demo (a few projects were added in
advance so you can actually test it). You can also join us on HipChat or
in #kibble on Freenode IRC (IRC and HipChat are bridged).

- Try out the demo, and send us feedback to the mailing list on what you
like, dislike and would love to see added.

- In particular: Which metrics do you look for when reviewing the code,
development and community health/trends of your project - which do you
have, which would you love to see added?

With regards,
Daniel on behalf of the Apache Kibble project.

PS: Please note, we have limited capacity for these tests. We cannot
have every single ASF project in the demo, and we reserve the rights to
pick the projects that can participate, should we get a lot of requests.

Container launch metrics on agent

[Zhitao Li]

Hi,

We are working on defining containerizer SLA metrics in our cluster. I
found that Mesos agent only provides a "slave/container_launch_errors"
counter right now.

A couple of questions:

1) is there a "container launch success/count" on the agent which can be
used as the comparative baseline of the above metric? If not, should we add
one?
2) does the `errors` metric above also cover nested and standalone
containers?

Thanks!

-- 
Cheers,

Zhitao Li

Re: Please use `int_fd` instead of `int` for file descriptors

[Benjamin Bannier]

Hi,

> I'm not sure how to actually help with the issue of making `int_fd`
> more discoverable. The only idea I've got is a ClangTidy check to
> complain about variables of type `int` named `fd` and other similar
> common names for file descriptors such as `socket`.

I was wondering about this as well.

It seems like we already provide a pretty comprehensive set of stout
library functions to create file descriptors. As an example, I see
`net::socket`, so user code directly calling `::socket` seems not like
something we'd want and we should rather add missing functionality to
our library functions than completely avoid them. If we use wrappers it
should be trivial to catch undesirable use of unwrapped functions given
some list of wrapper functions. We have an existing ticket to create
such a check, https://issues.apache.org/jira/browse/MESOS-5105; please
feel to add interesting wrapper functions to it.

We might also want to consider making `int_ft` a tighter type so that
e.g., conversions to `int` require explicit user action. That might
throw another wrench into too careless work.


Cheers,

Benjamin