On augmenting TLS configuration options in libprocess

Folks, We reviewed TLS configuration options in libprocess and came up with the following proposal [1] to allow for certificate verification in client mode only. In short, the proposal suggests to add two flags to libprocess so that it can be configured to: * always require presence and verify

Re: '*.json' endpoints removed in 1.7

; breaking some user/tooling, in my opinion. We could revisit this if and > when we do a Mesos 2.0. > > On Wed, Aug 8, 2018 at 9:25 AM Alex Rukletsov wrote: > > > Folks, > > > > The long ago deprecated '*.json' endpoints will be removed in Mesos > 1.7.0. > > Pleas

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

Modulo Jorge's comment (hope he'll come back soon), +1 (binding). This rc has been deployed on a cluster internally by us at Mesosphere and has been running without noticeable issues for a couple of days for now. Alex. On Mon, Apr 29, 2019 at 10:05 PM Benno Evers wrote: > Hi Jorge, > > I'm

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

This will be the last official 1.4.x release. Even though we agreed to keep the branch and occasionally back port fixes to it post last release, maybe it makes sense to include all pending patches into 1.4.3? I see for example Gilbert added the fix for MESOS-9532 [1]. We were also considering back

Re: full Zookeeper authentication

Kishchukov. > Leading software developer > Submission Portal Team > > > On 12/21/18, 4:02 AM, "Alex Rukletsov" wrote: > > Dmitrii— > > here we go: MESOS-9499 [1]. I've noticed you don't have an Apache JIRA > account, I'd suggest you create one s

Re: full Zookeeper authentication

Dmitrii— here we go: MESOS-9499 [1]. I've noticed you don't have an Apache JIRA account, I'd suggest you create one so that you can assign the ticket to you and hence get credit properly. Hope it is not your last contribution to Apache projects : ). [1]

Re: Propose to create a Kubernetes framework for Mesos

I'm in favour of the proposal, Cameron. Building a bridge between Mesos and Kubernetes will be beneficial for both communities. Virtual kubelet effort looks promising indeed and is definitely a worthwhile approach to build the bridge. While we will need some sort of a scheduler when implementing

Re: Join us at MesosCon 2018 next week!

I'd like to thank everyone involved in organising this MesosCon, and especially Gastón, Jörg, and Andy. I enjoyed the laid-back "underground" style this year; it was easy to engage in conversations with users and Mesos developers. Looking forward to the next MesosCon! Alex On Thu, Nov 1, 2018 at

Re: Request for Comments - Health Check API Proposal

s/deprecations. > > On Thu, Oct 18, 2018 at 4:04 AM Alex Rukletsov > wrote: > > > Thanks for the thoughts, Vinod! Answers inlined. > > > > On Wed, Oct 17, 2018 at 8:55 PM Vinod Kone wrote: > > > > > One of the things we discussed when we added `Chec

Re: Request for Comments - Health Check API Proposal

Thanks for the thoughts, Vinod! Answers inlined. On Wed, Oct 17, 2018 at 8:55 PM Vinod Kone wrote: > One of the things we discussed when we added `CheckInfo` and > `CheckStatusInfo` was to make the older `HealthCheck` and `bool healthy` > field (inside `TaskStatus`) consistent with the new

On committer candidate nomination

Folks, A seemingly complex and long path to become a committer can drive away potential candidates shortly after they start contributing to the project. Around a year ago Jim Jagielski raised a concern about the high entry bar we have in the project. We heard the feedback and decided to

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

+1 (binding) Mesosphere's internal CI run with the aforementioned tag. Observed 4 flaky tests, 3 are known: https://issues.apache.org/jira/browse/MESOS-5048 https://issues.apache.org/jira/browse/MESOS-8260 https://issues.apache.org/jira/browse/MESOS-8951 One has been introduced as part of adding

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

MESOS-9177 has been filed today. It is very likely a regression introduced by one of the state.json improvements. We are still investigating, but it is obviously a -1 (binding) for rc1. Alex. On Wed, Aug 22, 2018 at 4:34 AM, Chun-Hung Hsiao wrote: > Hi all, > > Please vote on releasing the

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

+1 binding (make check on Mac OS 10.13.5) On Mon, Aug 20, 2018 at 8:28 PM, Kapil Arya wrote: > +1 binding (internal CI). > > The Apache CI failures reported by Vinod are all known flaky tests. I have > inserted the details inline. > > Best, > Kapil > > On Tue, Aug 14, 2018 at 11:03 AM Vinod

'*.json' endpoints removed in 1.7

Folks, The long ago deprecated '*.json' endpoints will be removed in Mesos 1.7.0. Please use their non-'.json' counterparts instead. Commit: https://github.com/apache/mesos/commit/42551cb5290b7b04101f7d800b4b8fd573e47b91 JIRA ticket: https://issues.apache.org/jira/browse/MESOS-4509 Alex.

Apache Mesos repo migration

Folks, the official Mesos git repository has moved over to gitbox. Don't forget to update your git remotes and tooling! See the update dox [1] [1] https://github.com/apache/mesos/commit/9127c792c5a20aee2f31a2e56854c2490a9ca608 Alex.

Re: Is upgradeStrategy respected during redeployment

Feng, I'd suggest to contact Marathon developers directly, check out https://github.com/mesosphere/marathon#help. On Mon, Jul 23, 2018 at 12:01 PM, Feng LI wrote: > I think this might worth a discussion here. > > Feng > -- Forwarded message - > From: Feng LI > Date: jeu. 19

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

MPark— what's the decision regarding the 1.3.3 release? On Mon, Jul 9, 2018 at 8:52 PM, Michael Park wrote: > I'm considering simply abandoning the 1.3.3 release and bringing the 1.3.x > branch to end of life. > If anyone really wants a 1.3.3, I'm certainly willing to finish the > release

Re: Backport Policy

y as necessary, and leave it on > the committers to decide if backporting a particular change is necessary. > > > On 07/13/2018 12:54 am, Alex Rukletsov wrote: > >> This is exactly where our views differ, Ben : ) >> >> Ideally, I would like a release manager to have

Re: Backport Policy

erally backport every bug fix I commit > that applies cleanly, right after I commit it to master (with the > exceptions I listed below). > > On Thu, Jul 12, 2018 at 8:39 AM, Alex Rukletsov > wrote: > > > I would like to back port as little as possible. I suggest the fo

Re: Backport Policy

I would like to back port as little as possible. I suggest the following criteria: * By default, regressions are back ported to existing release branches. A bug is considered a regression if the functionality is present in the previous minor or patch version and is not affected by the bug there.

Re: Proposing change to the allocatable check in the allocator

Instead of the master flag, why not a master API call. This will allow to update the value without restarting the master. Another thought is that we should explain operators how and when to use this knob. For example, if they observe a behavioural pattern A, then it means B is happening, and

On filtering protobuf messages in the test harness

Folks, I was thinking how our test harness can be improved to allow for simpler, more reliable tests (captured as MESOS-8922). One thing, MESOS-8923, comes from an observation that sometimes an expectation in a test is satisfied by a similar but actually irrelevant message / call. Let me give

Re: Update the *Minimum Linux Kernel version* supported on Mesos

This does not seem to me as a disruptive change, so I'm +1. On Thu, Apr 5, 2018 at 6:36 PM, Jie Yu wrote: > User namespaces require >= 3.12 (November 2013). Can we make that the >> minimum? > > > No, we need to support CentOS7 which uses 3.10 (some variant) > > - Jie > > On

Re: Release policy and 1.6 release schedule

I would like us to do monthly releases and support 10 branches at a time. Ideally, releasing that often reduces the burden for the release manager, because there are less changes and less new features. However, we lack automation to support this pace: our release guide [1] is several pages long

Re: On disabled tests

> On 03/22/2018 12:22 am, Alex Rukletsov wrote: > >> I think such policy would help us discover and act on forgotten disabled >> tests. The reason I am reluctant to propose this as an official policy is >> because I don't know how to enforce it. >> >> On 21 Mar 201

Re: On disabled tests

this Alex! Are you proposing a policy that every disabled > test should’ve an associated ticket that is linked in the comment above the > test? I’m all for it. > > Sent from my phone > > > On Mar 21, 2018, at 9:42 AM, Alex Rukletsov <a...@mesosphere.io> wrote: > > >

On disabled tests

Folks, to increase visibility into disabled tests, I've added a "disabled-test" label. Whenever you disable a test, please add this label. A TODO comment before the test mentioning the corresponding jira helps too. At the moment we have 20+ disabled tests in 18 tickets [1]. Some tests were

Re: Reconsidering `allocatable` check in the allocator

If we are about to offer some of the resources from a particular agent, why would we filter anything at all? I doubt we should be concerned about the size of the offer representation travelling through the network. If available resources are "cpus:0.001,gpus:1" and we want to allocate GPU, what is

Re: Soliciting Hackathon Ideas

Judith — we have newbie and newbie++ labels [1]. To help people land their changes at the end of a hackathon, we should find shepherds for issues before giving them out to folks. Shepherds should have time for reviews and an idea about the approach. [1]

Re: [VOTE] C++14 Upgrade

+1 (binding) Mesos codebase seems to be ready for the upgrade (tested on Mesosphere's internal CI). I think beginning of 2018 is the right time for this. In addition to technical reasons mentioned by MPark, I add one more: modernising the codebase fosters learning, fun, and makes it a more

Re: Soliciting Hackathon Ideas

Andrew, here is my selection based on implementation difficulty, impact, and code locality. https://issues.apache.org/jira/browse/MESOS-5824 — augmenting string representation of Resource for debuggability. Coding is trivial, but requires finding a compromise between conciseness and clarity.

Re: Flaky executor tests on ARM

Might be libtool wrappers. Have a look at [1] and commits [2, 3, 4]. [1] https://issues.apache.org/jira/browse/MESOS-7500 [2] https://github.com/apache/mesos/commit/d863620e5cb82b7f22cade0da0a0d18afbdf9136 [3] https://github.com/apache/mesos/commit/74121798f24fca372180b8c4bc00b4df07d46240 [4]

Re: DC/OS (Mesos) portability

I think Tomas means Mesos dependencies, like libcurl, and not libmesos. If I understand him correctly, he is saying that part of Mesos dependencies is not distributed with Mesos binaries, and, if not included into a distribution, might complicate installation process. On Fri, Nov 3, 2017 at 8:54

Re: Mesos schedulers

What do you mean under "the regular mesos scheduler"? On Tue, Nov 21, 2017 at 6:44 AM, Trevor Powell wrote: > YoYo what up! > > We have been running into resource fragmentation across our clusters. We > have several small tasks and several large tasks. And sometimes, the

Re: mesos health checks

with some status code but with empty body, please file a bug report against Mesos jira. On Fri, Nov 3, 2017 at 2:20 PM, Alex Rukletsov <a...@mesosphere.com> wrote: > Tomas, can I reply to you and cc devlist to have our discussion logged > publicly? > > > On Fri, Nov 3, 2017 at 10:

On the current CI state

Folks, the CI state (both Apache and internal we have at Mesosphere) has recently degraded to a point when people no longer look at it failures. This defeats the primary purpose of a CI: to produce a reliable signal when a change breaks something. You might have seen a bunch of commits fixing

Re: [Proposal] Updating levels for verbose logging

Ben, I understand why you question that libprocess should log starting from a specific level. I think it is not quite illogical for a library to use lower priority levels. I can see this change being helpful for any user of libprocess, not just Mesos. On Mon, Oct 9, 2017 at 6:34 PM, Benjamin

Re: [Proposal] Updating levels for verbose logging

I support the effort, Armand. On Wed, Oct 4, 2017 at 3:59 PM, Armand Grillet wrote: > Hi all, > > We currently use three levels of verbose logging via the VLOG macro. I > propose to add two levels and change how we use the current ones to make > debugging easier for

Re: About the Mesos authorization

Look for "Implementing an Authorizer" in [1]. [1] https://mesos.apache.org/documentation/latest/authorization/ On Thu, Sep 14, 2017 at 4:01 AM, j...@is-land.com.tw <j...@is-land.com.tw> wrote: > > > On 2017-09-14 02:46, Alex Rukletsov <a...@mesosphere.io> wrote: &

Re: About the Mesos authorization

Mesos provides API which you can use to build any authz you like. But that does not necessarily mean that all those implementations should be part of the core mesos. I'd suggest to search around, maybe you will find something you can use. For example, internally we have Kerberos authz module, but

[RESULT][VOTE] Release Apache Mesos 1.1.3 (rc2)

Hi all, The vote for Mesos 1.1.3 (rc2) has passed with the following votes. +1 (Binding) -- Alex R Till Tönshoff Vinod Kone There were no 0 or -1 votes. Please find the release at: https://dist.apache.org/repos/dist/release/mesos/1.1.3 It is recommended to use a

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

cmake > > <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos- > Release/40/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=-- > verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu% > 3A14.04,label_exp=(docker%7C%7CHadoop)&&(!ubuntu-us1)

[VOTE] Release Apache Mesos 1.1.3 (rc2)

Folks, Please vote on releasing the following candidate as Apache Mesos 1.1.3. Note that this will be the last 1.1.x release. 1.1.3 includes the following: ** Bug  * [MESOS-5187] - The filesystem/linux isolator

Re: build tests/scheduler_http_api_tests.cpp error

Yes, we need to `#include `. Thanks for the report! It is fixed in the master now: 9735aebcdaa02d6577636b2c9ea45d986af747c9 On Tue, Aug 22, 2017 at 11:22 AM, Yanjun Shen wrote: > hi, > now, i have finished make install ,but when i build > scheduler_http_api_tests.cpp

Re: [Proposal] Use jemalloc as default memory allocator for Mesos

I'm for making jemalloc default as well with adding an opt-out option to CMake and autotools build scripts. On Sat, Aug 19, 2017 at 3:23 AM, Benjamin Mahler wrote: > This will be a big win Benno, thanks for driving it! > > Nice to see that the heap profiling overhead is

Re: Mesos 1.1.3 release

We have two more issues that I would like to have in 1.1.3 because it's the last 1.1.x release: https://issues.apache.org/jira/browse/MESOS-7865 https://issues.apache.org/jira/browse/MESOS-7863 They are in review and will be back ported soon. On Tue, Jul 25, 2017 at 11:28 AM, Alex Rukletsov

Re: Mesos 1.1.3 release

MESOS-7643 is still unresolved. I am moving the cut date for one more week, because this is the last patch release for 1.1.x. On Fri, Jul 14, 2017 at 6:34 PM, Alex Rukletsov <a...@mesosphere.com> wrote: > Folks, > > We are planning to cut the 1.1.3 release once MESOS-7643 is res

Re: Mesos 1.1.3 release

://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12331463 Till & Alex. On Wed, Jun 14, 2017 at 12:59 PM, Alex Rukletsov <a...@mesosphere.com> wrote: > Folks, > > there are only 2 back ported tickets to the 1.1.x branch so far (MESOS-7540 > and MESOS-7569). Since this

Re: RFC: removing process implementations from common headers

I'm in favor of the suggestion. Do you guys plan to do a single sweep or document the pattern somewhere and apply it only for new and refactored code? On Wed, Jun 28, 2017 at 12:19 AM, Yan Xu wrote: > This sounds reasonable to me. Do others have comments? > > --- > @xujyan

On Apache Mesos release process

Folks, for more than a year Apache Mesos releases are done according to our "then new" release policy [1]. It seems to work quite well, but today I would like to address things that can be improved. Let's start with pain points: * A minor bug can cancel a release vote, even for a patch release.

Re: Easing the Pain of Code Formatting in Mesos

+1. Having an enforceable rule is sometimes more important than the rule itself (e.g., 4 vs. 2 spaces indent). On Thu, Jun 15, 2017 at 9:59 AM, Alexander Rojas wrote: > +1 It is always frustrating to rely in clang format to realize it generate > the wrong style, even

Mesos 1.1.3 release

Folks, there are only 2 back ported tickets to the 1.1.x branch so far (MESOS-7540 and MESOS-7569). Since this will be the last 1.1.x release, we are delaying it for 3 more weeks to leave more time for people to include critical bug fixes. Till & Alex.

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

PortMapping tests are indeed in bade shape. There are JIRAs already, have a look before filing new ones: MESOS-4646, MESOS-5687, MESOS-2765, MESOS-5690, MESOS-5688, MESOS-5689, MESOS-4643, MESOS-4644, MESOS-5309 On Sat, Jun 10, 2017 at 10:58 AM, Adam Bordelon wrote: > +1

Re: Questions about Mesos starting procedure in the source code

Wenzhao, I am sure your read some docs about Mesos, have you seen overview pages [1, 2, 3]? I think they will help to better understand the big picture, what the moving parts are and how they interact. To your questions, 1. There are two types of schedulers: those using "legacy" aka

Re: Added task status update reason for health checks

James, We are more than happy to write a comment if folks think it is useful. Do you have anything specific in mind you want to be captured there? For me, the reason's name is self-explanatory. Alex. On 22 May 2017 17:32, "James Peach" wrote: > > > On May 22, 2017, at 5:28

[RESULT][VOTE] Release Apache Mesos 1.1.2 (rc2)

Hi all, The vote for Mesos 1.1.2 (rc2) has passed with the following votes. +1 (Binding) -- Vinod Kone Till Tönshoff Alex Rukletsov There were no 0 or -1 votes. Please find the release at: https://dist.apache.org/repos/dist/release/mesos/1.1.2 It is recommended

[VOTE] Release Apache Mesos 1.1.2 (rc2)

Folks, Please vote on releasing the following candidate as Apache Mesos 1.1.2. 1.1.2 includes the following: ** Bug * [MESOS-2537] - AC_ARG_ENABLED checks are broken. * [MESOS-5028] - Copy provisioner cannot

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

est we include this fix in 1.1.2 >> https://issues.apache.org/jira/browse/MESOS-7471 >> >> On Thu, May 4, 2017 at 12:07 PM, Alex Rukletsov <a...@mesosphere.com> >> wrote: >> >>> Hi all, >>&g

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

7471 > > On Thu, May 4, 2017 at 12:07 PM, Alex Rukletsov <a...@mesosphere.com> > wrote: > >> Hi all, >> >> Please vote on releasing the following candidate as Apache Mesos 1.1.2. >> >> 1.1.2 includes the following: >> --

[VOTE] Release Apache Mesos 1.1.2 (rc1)

Hi all, Please vote on releasing the following candidate as Apache Mesos 1.1.2. 1.1.2 includes the following: ** Bug * [MESOS-2537] - AC_ARG_ENABLED checks are broken. * [MESOS-5028] - Copy provisioner cannot

Mesos 1.1.2 release

Folks, We are planning to cut the 1.1.2 release later this week. If you have any patch that needs to get into 1.1.2, please make sure that either it is already in the 1.1.x branch or the corresponding ticket has a target version including 1.1.2. The release dashboard:

Re: CMake and (eventually) deprecating the autotools build

A tip for ccache users. Recent versions of CMake allow to set CMAKE_{CXX|C}_COMPILER_LAUNCHER=. For example, `cmake -DCMAKE_CXX_COMPILER_LAUNCHER=/usr/local/bin/ccache -DCMAKE_C_COMPILER_LAUNCHER=/usr/local/bin/ccache`. On Tue, Mar 14, 2017 at 6:15 PM, Joseph Wu wrote: >

[RESULT][VOTE] Release Apache Mesos 1.1.1 (rc2)

Hi folks, The vote for Mesos 1.1.1 (rc2) has passed with the following votes. +1 (Binding) -- *** AlexR *** Till Tönshoff *** Vinod Kone There were no 0 or -1 votes. Please find the release at: https://dist.apache.org/repos/dist/release/mesos/1.1.1 It is

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

, MESOS-7218 > > > On Mar 4, 2017, at 1:09 AM, Vinod Kone <vinodk...@apache.org> wrote: > > +1 (binding) > > Since the perf issue I reported earlier doesn't seem to be a blocker. > > On Fri, Mar 3, 2017 at 12:14 AM, Alex Rukletsov <a...@mesosphere.com> > wro

[VOTE] Release Apache Mesos 1.1.1 (rc2)

Hi all, Please vote on releasing the following candidate as Apache Mesos 1.1.1. 1.1.1 includes the following: ** Bug * [MESOS-6002] - The whiteout file cannot be removed correctly using aufs backend. *

[Design Doc] Arbitrary task checks in Mesos

We've recently been working on a design for arbitrary task checks [1] in Mesos (currently called probes, but this will likely change). Please have a look and leave comments on the doc or

Mesos 1.1.1 release dashboard

Folks, We are planning to cut the 1.1.1 release early next week. If you have any patches that need to get into 1.1.1, please make sure that either it is already in the 1.1.x branch or the corresponding ticket has a target version including 1.1.1 *by Monday* Dec 26. The release dashboard:

Re: Order of includes

Yes! https://issues.apache.org/jira/browse/MESOS-6827 On Mon, Dec 19, 2016 at 8:49 AM, Yan Xu wrote: > The example is helpful. Thanks! > > I have no objection to sticking to the new rule then. But the we have to: > > - For contributors and committers, start using the new

Re: [webui] Started show wrong time

This looks like a bug. Tomek, could you please file a JIRA? On Tue, Dec 13, 2016 at 1:02 PM, Tomek Janiszewski wrote: > Hi > > When task has enabled Mesos healthcheck start time in UI can show wrong > time. This happens because UI assumes that first status is task started >

Re: Command healthcheck failed but status KILLED

Technically the task hast not failed but was killed by the executor (because it failed a health check). On Fri, Dec 9, 2016 at 11:27 AM, Tomek Janiszewski wrote: > Hi > > What is desired behavior when command health check failed? On Mesos 1.0.2 > when health check fails task

Re: Adding a reload end-point to `network/cni` isolator

Whatever the solution will be, it will be great to stay consistent. It looks like updating configuration during agent lifetime is a typical task, hence having a "standard approach" would be great. Agent Whitelist and ACLS come to my mind. On 8 Dec 2016 7:24 am, "Avinash Sridharan"

Re: Duplicate task IDs

I'm fine with prohibiting non-unique IDs, but why do you plan to keep the most recent in case of a conflict? I'd expect any duplicate (that we can find out) is rejected / killed / banned / unchurched. On 9 Dec 2016 8:13 pm, "Joris Van Remoortere" wrote: > Hey Neil, > > I

Re: Quota

Granularity in the allocator is a single agent. Hence even though you set quota for 0.0001 CPU, at least one agent is "blocked". This is probably the reason why marathon is not getting offers. You can turn verbose master logs and check allocator messages to confirm. Alex. On 10 Dec 2016 2:14 am,

Re: [GitHub] mesos issue #190: Ensure curl is present on Ubuntu

Curl is also a prerequisite for mesos-native HTTP health checks (from Mesos 1.2). We will remove it eventually but likely not in the nearest future. On 29 Nov 2016 19:08, "jieyu" wrote: > Github user jieyu commented on the issue: > >

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

&(!ubuntu-us1)&&(!ubuntu-eu2)/> >> cmake >> [image: Success] >> <https://builds.apache.org/view/M-R/view/Mesos/job/Mesos-Release/25/BUILDTOOL=cmake,COMPILER=gcc,CONFIGURATION=--verbose,ENVIRONMENT=GLOG_v=1%20MESOS_VERBOSE=1,OS=ubuntu%3A14.04,label_exp=(docker%7

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

I see LinuxFilesystemIsolatorTest.ROOT_ChangeRootFilesystem failing on CentOS 7 and Fedora 23, see e.g., [1]. I don't see any backports touching [2], can it be a regression or this test is know to be problematic in 0.28.x? [1] http://pastebin.com/c5PzfGF8 [2]

Re: [3/3] mesos git commit: Enabled multiple field based authorization in the authorizer interface.

Fixed in https://github.com/apache/mesos/commit/d2ab4b49d3cc0b86bacc5ec3400b46cfa70c3a7b On Fri, Nov 18, 2016 at 4:48 AM, Benjamin Bannier < benjamin.bann...@mesosphere.io> wrote: > Hi, > > This introduces a possibly uninitialized member `weight_info` which > Coverity immediately detected. I

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

+1 (binding) Tested in internal CI. On Mon, Nov 7, 2016 at 8:24 PM, Vinod Kone wrote: > Hi all, > > > Please vote on releasing the following candidate as Apache Mesos 1.0.2. > > > This is a bug fix release. > > > The CHANGELOG for the release is available at: > >

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

+1 (binding) make check locally + manually tested health checks with the locally modified mesos-execute. On Wed, Nov 9, 2016 at 6:13 PM, Zhitao Li wrote: > +1 (non-binding) > > Tested with ROOT and docker on debian jessie. > > On Mon, Nov 7, 2016 at 2:19 PM, Vinod Kone

Re: [2/2] mesos git commit: Added MESOS-6142 to CHANGELOG for 1.1.1.

If I read https://github.com/apache/mesos/blob/master/docs/release-guide.md correctly, that is actually what we do: create 1.1.x branch before 1.1.0. If the vote does not pass, we cherry-pick and fix in that branch. With this commit I haven't created any branches, *just* a placeholder for a

Re: Test failures in Apache Jenkins

<bmah...@apache.org> wrote: > Hm.. these links are all broken, were you linking to jenkins logs directly? > They get garbage collected rather quickly. > > On Mon, Oct 31, 2016 at 1:47 AM, Alex Rukletsov <a...@mesosphere.com> > wrote: > > > Folks, > > &g

Re: On increasing visibility into experimental features.

rs necessary for a feature to become stable is quite > important in such a case (not everyone has the luxury to comb through JIRA > boards for contexts, or talk to the direct owner of the the feature). > > On Tue, Nov 1, 2016 at 5:28 PM, Alex Rukletsov <a...@mesosphere.com> > wr

On increasing visibility into experimental features.

Folks, Additionally to the "known bugs" proposal in a parallel thread, we think that maintaining a list of still experimental features for each minor release will significantly help users to adjust their expectations. Our suggestion is to include a new section into the CHANGELOG called

On increasing visibility into known bugs and issues.

Folks, There have been several suggestions recently about how we can help people understand which known issues are in certain Mesos releases (thanks Joris for kicking this off!). With a time-based release strategy we may not have enough time to fix all the known issues prior to cutting an RC.

Re: Build failed in Jenkins: Mesos » autotools,gcc,--verbose --enable-libevent --enable-ssl,GLOG_v=1 MESOS_VERBOSE=1,centos:7,(docker||Hadoop)&&(!ubuntu-us1)&&(!ubuntu-6) #2852

Filed https://issues.apache.org/jira/browse/INFRA-12852 On Mon, Oct 31, 2016 at 4:26 PM, Neil Conway wrote: > I spent a little while looking into this. The > "PersistentVolumeEndpointsTest.OfferCreateThenEndpointRemove" test > fails on the following expectations: > >

Transition TASK_KILLING -> TASK_RUNNING

We've recently discovered a bug that may lead to a task being transitioned from killing to running state. More information about it in MESOS-6457 [1]. We plan to fix it in 1.2.0 and will backport it to all supported versions. [1] https://issues.apache.org/jira/browse/MESOS-6457

Test failures in Apache Jenkins

Folks, I observe a lot of flaky tests in Apache Jenkins. They seem rather random and not tied to particular machines (saw failures on H1 and on H2). Moreover, there are no tickets for them and I haven't seen any of those failures in our internal CI. Does anyone have an idea about any recent

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

This vote is cancelled. We'll cut RC2 later this week after the blockers are resolved. On Tue, Oct 25, 2016 at 5:48 AM, Zameer Manji wrote: > I'm going to -1 (non binding) for the same reason as David Robinson. > > I would classify the FD leak as serious and a violation of

Re: Parallel test runner added

This is great, Benjamin! I've used it the whole day today and it is awesome. (It will become insanely great once MESOS-6387 is resolved.) Thanks for everyone who made this happen, also on behalf of my employer : ) Alex. On Thu, Oct 13, 2016 at 11:28 PM, Benjamin Bannier <

On Mesos versioning and deprecation policy

Folks, There have been a bunch of online [1, 2] and offline discussions about our deprecation and versioning policy. I found that people—including myself—read the versioning doc [3] differently; moreover some aspects are not captured there. I would like to start a discussion around this topic by

Re: How to shutdown mesos-agent gracefully?

To make sure: you are aware of SIGUSR1? On Tue, Oct 11, 2016 at 5:37 PM, tommy xiao wrote: > Hi Ma, > > could you please input more background, why Maintenance feature is not > best option for your request? > > 2016-10-11 14:47 GMT+08:00 haosdent : > > >

Re: 1.1.0 release

, Alex & Till On Tue, Oct 11, 2016 at 5:30 PM, Alex Rukletsov <a...@mesosphere.io> wrote: > Folks, > > in preparation for Mesos 1.1.0 release we would like to ask people who > have worked on features in 1.1.0 to either: > * update the CHANGELOG and declare the feature impl

Re: LIBPROCSES_IP

> > Also, I think libprocess should always bind to 0.0.0.0, rather than doing a > hostname lookup and bind to the IP found for the hostname. > LIBPROCESS_ADVERTISE_IP can be used to overwrite the ip address it wants to > advertise to peers. If that's not specified, it'll try to do a hostname >

Re: Separate Compilation of Tests

Michael, I'm doing this wrong too and I have expensive laptop as well. I don't know any better solution than interleave compilation with other work. This is not always productive, hence +1 for this change. As a side note, we should probably revive the effort of a) splitting huge .cpps into

Re: Support HTTP(s)/TCP Health Check in Mesos

Aaron— we do use some on Boost libraries. I think supporting HTTP/2 is a great idea and we should definitely create a JIRA epic to evaluate and track work. My intuition we will have to implement it ourselves in libprocess. Would you like to open a ticket? However, let's not hijack this thread

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

+1 (binding) make check on Mac OS 10.11.6 with apple clang-703.0.31. DockerFetcherPluginTest.INTERNET_CURL_FetchImage is flaky (MESOS-4570), but this does not seem to be a regression or a blocker. On Fri, Aug 12, 2016 at 10:30 PM, Radoslaw Gruchalski wrote: > I am trying

On creating actor instances in Mesos

Folks, I've noticed recently that some actors do not specify a distinguishable actor ID. As a result, it may be hard to match output to a specific actor, for example an excerpt from "__processes__" endpoint:

Re: MESOS-4694

sort the frameworks almost every time. In fact, > frameworks are already kept sorted as long as possible, it’s just not > possible to keep them sorted for very long because of the call to said > function ;). > > -- >  Dario > > > On Jul 8, 2016, at 6:50

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

Haosdent investigated the issue, and it seems that health checks do work for docker executor. Hence I retract my negative vote. On Fri, Jul 15, 2016 at 12:57 PM, Alex Rukletsov <a...@mesosphere.com> wrote: > -1 (binding): MESOS-5848 > <https://issues.apache.org/jira/browse/MESOS

  1   2   3   >