Re: [VOTE] Move Apache Mesos to Attic

Hi Shane, >> FWIW, I'm one of those people who said they were interested, and I >> still voted to move it to the attic (even though my vote is non >> binding as I'm not a committer). > >That's great! One of the questions I have for the project is: why >haven't they made you a committer yet?

Re: [VOTE] Move Apache Mesos to Attic

With a heavy heart, but also curiosity about what will come next, +1. Benjamin On Mon, Apr 5, 2021 at 7:58 PM Vinod Kone wrote: > Hi folks, > > Based on the recent conversations >

Re: Feature requests for Mesos

Hi Charles-François, thanks for your detailed message, you captured important points, and I think I agree with your sentiment here. Mesos might still have a place, and before thinking about what new features to add, the project first needs to solve more fundamental issues. My previous

Re: Next Steps

Hi Vinod, > I would like to start a discussion around the future of the Mesos project. > > As you are probably aware, the number of active committers and contributors > to the project have declined significantly over time. As of today, there's > no active development of any features or a public

RFC: Extending supported RESERVE operations

Hi, Mesos currently puts a number of restrictions on what a RESERVE operation can do (e.g., add only one refinement; no support to change a resource reservations) which implies restrictions elsewhere, e.g., on persistent volumes. In order to make reservations more flexible we came up with a

Re: RFC: Improving linting in Mesos (MESOS-9630)

`, and `cpplint` in our setup). Consider upstreaming whatever you found useful. Happy linting, Benjamin On Sat, Aug 17, 2019 at 2:12 PM Benjamin Bannier wrote: > Hi, > > I opened MESOS-9360[^1] to improve the way we do linting in Mesos some time > ago. I have put some polish on my p

RFC: Improving linting in Mesos (MESOS-9630)

Hi, I opened MESOS-9360[^1] to improve the way we do linting in Mesos some time ago. I have put some polish on my private setup and now published it, and am asking for feedback as linting is an important part of working with Mesos for most of you. I have moved my workflow to pre-commit more than

Re: Why does not mesos provide linux packages ?

Hi, > why don't we have packages for the main ubuntu distributions ? like ubuntu > and redhat ? Just reiterating my comment from https://issues.apache.org/jira/browse/MESOS-6851?focusedCommentId=16808547=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16808547 here

Re: Discussion: Scheduler API for Operation Reconciliation

Hi, have we reached a conclusion here? From the Mesos side of things I would be strongly in favor of proposal (III). This is not only consistent with what we do with task status updates, but also would allow us to provide improved operation status (e.g., `OPERATION_UNREACHABLE` instead of

Re: New scheduler API proposal: unsuppress and clear_filter

Hi Ben et al., I'd expect frameworks to *always* know how to accept or decline offers in general. More involved frameworks might know how to suppress offers. I don't expect that any framework models filters and their associated durations in detail (that's why I called them a Mesos

Re: New scheduler API proposal: unsuppress and clear_filter

Hi Meng, thanks for the proposal, I agree that the way these two aspects are currently entangled is an issue (e.g., for master/allocator performance reasons). At the same time, the workflow we currently expect frameworks to follow is conceptually not hard to grasp, (1) If framework has work

Re: Getting write access to our GitHub repo

Hi Vinod, We (Jie, James, me) briefly discussed this topic and some implication over slack: * I mentioned I was surprised how a vote on _moving the project repo to ASF gitbox_ turned into _moving the project repo to Github_. * Jie mentioned that this would simplify (enable?) how we could close

Re: Build failed in Jenkins: Mesos-Tidybot » -DENABLE_LIBEVENT=OFF -DENABLE_SSL=OFF,(docker||Hadoop)&&(!ubuntu-us1)&&(!ubuntu-eu2) #1341

> Hmm. Is this new? This is about a week old. There’s a fix in progress, https://reviews.apache.org/r/68001/. @jpeach @drexin > On Mon, Jul 23, 2018 at 11:04 AM Apache Jenkins Server < > jenk...@builds.apache.org> wrote: > >> See < >>

Re: mesos git commit: Added mpsc_linked_queue and use it as the concurrent event queue.

Hi Dario, this patch introduced two new clang-tidy warnings. Could we try to get these down to zero, even if the code does not look bad? I already created a patch for the unused lambda capture, https://reviews.apache.org/r/67927/ While the code does look reasonable, as a somewhat weird

Re: RFC: update C++ style to require the "override" keyword

Hi, >> Note that since our style guide _is_ the Google style guide plus some >> additions, we shouldn't need to update anything in our style guide; the >> Google >> style guide seems to have started requiring this from February this year and >> our code base just got out of sync > > I'd prefer

Re: RFC: update C++ style to require the "override" keyword

Hi James, > I’d like to propose that we update our style to require that the > “override” keyword always be used when overriding virtual functions > (including destructors). The proposed text is below. I’ll also prepare > a clang-tidy patch to update stout, libprocess and mesos globally. +1!

Re: Should we remove `noexcept` from `ObjectApprover::approved()` signature?

Hi, I still believe that declaring methods of this module interface `except` is a good thing which IMO we should also do for all new module interfaces going forward. We do not perform any exception handling around calls to these functions in Mesos, and `noexcept` is intended to communicate

Re: [Performance WG] Notes from meeting today

Hi Ben, thanks for taking the time to edit and share these detailed notes. Being able to asynchronously see the great work folks are doing surfaced is great, especially when put into context with thought like here. Benjamin > On May 16, 2018, at 8:06 PM, Benjamin Mahler

Re: Introducing `support/mesos-build.sh`

Done. > On Mar 20, 2018, at 10:46 AM, Tomek Janiszewski wrote: > > Thanks for merging. Can we push this image to dockerhub tagged as > ubuntu-16.04-arm? Then we will need to update CI configuration to: > JOBS=16 OS=ubuntu-16.04-arm BUILDTOOL=cmake COMPILER=gcc >

API change to augment resource provider information served in master and agent endpoints

Hi, this is a heads up that we would like to augment the master and agent HTTP APIs to also serve resource provider resources in `GET_AGENTS` and `GET_RESOURCE_PROVIDER` responses, respectively. This change does not remove or change the meaning of existing fields, but is strictly additive.

Release checksum file distribution change

Hi, this is a heads-up that future Mesos release checksum files will be SHA512, e.g., `mesos-1.6.0.tar.gz.sha512`. The previously used MD5 checksum files will not be used anymore for future releases. Please update any dependent tooling you have on your side accordingly. Best, Benjamin

Re: Reconsidering `allocatable` check in the allocator

Hi, > Chatted with BenM offline on this. There's another option what both of us > agreed that it's probably better than any of the ones mentioned above. > > The idea is to make `allocable` return the portion of the input resources > that are allocatable, and strip the unelectable portion. > >

Re: [VOTE] C++14 Upgrade

+1. I believe the spreadsheet linked in MESOS-7949 makes it pretty clear that the benefits outweigh the required build requirement changes. > On Feb 10, 2018, at 6:28 AM, Michael Park wrote: > > I'm going to put this up for a vote. My plan is to bump us to C++14 on Feb >

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

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

Re: Differing DRF flavors over roles and frameworks

Hi Ben, and thank you for answering. > > For frameworks in the same role on the other hand we choose to normalize > > with the allocated resources > > Within a role, the framework's share is evaluated using the *role*'s total > allocation as a denominator. Were you referring to the role's total

Differing DRF flavors over roles and frameworks

Hi, the DRF flavors we use in our hierarchical allocator slightly differ between how we identify the role and the framework most under fair share. In DRF each actual usage is normalized to some “total”. For roles we use the total resources in the cluster (or for quota the total non-revocable

Re: install function

Hi, > I now read Mesos-1.3.0 sourcecode ,but i am in troubled for Master > initialize() function。 can you help me? > > in Master’s initialize() function : > install( >::registerSlave, >::slave, >::checkpointed_resources, >::version, >::agent_capabilities); It is

Re: [Design Doc] Native Support for Prometheus Metrics

Hi James, I'd like to make a longer comment here to make it easier to discuss. > [...] > > Note the proposal to alter how Timer metrics are exposed in an incompatible > way (I argue this is OK because you can't really make use of these metrics > now). I am not sure I follow your argument

Re: Moving the website repo from svn to git

Hi Vinod, > *Implementation details: * > > We have an option to move to > 1) a standalone git repo (say "mesos-site") which will be mirrored on > github. > 2) just use our "mesos" git repo and publish a "asf-site" branch with > website contents (say at 'site/publish' directory) > > I'm leaning

Re: Parallel test runner added

. The test runner has help strings documenting the understood parameters. HTH, Benjamin > On Apr 29, 2017, at 8:26 AM, Benjamin Bannier > <benjamin.bann...@mesosphere.io> wrote: > > Hi Ben, > > I use the parallel exclusively on a 8 hyperthreads Mac OS machine and a

Re: Parallel test runner added

rward to seeing the parallel test runner turn green, I'll help >>> file tickets under the epic (I see there are a lot of test failures for >>> me). >>> >>> Once we clear the issues and turn it green, shall we make this the >> default? >>> I w

Re: Exponential Backoff

Hi Anindya, thanks for that nice systematic write up. It makes it pretty clear that there are some inconsistency how back-off is handled, and how a more systematic approach could help. I’d like to make a small remark here where I can use some more space than in the doc. >> On Feb 12, 2017,

Re: Proposal for Mesos Build Improvements

Hi, > I wonder if we should instead use headers like: > > <- mesos_common.h -> > #include > #include > #include > > <- xyz.cpp, which needs headers "b" and "d" -> > #include "mesos_common.h> > > #include > #include > > That way, the fact that "xyz.cpp" logically depends on (but not >

Tracking deprecated features

Hi, we currently track deprecation of features largely through TODOs in the source code. Here we typically write down a release at which a deprecated feature should be removed. I believe this is less than optimal since * it is hard for users of our APIs to track when a deprecated feature is

Re: Order of includes

Hi, > How does putting your own header at the top (vs. ~the bottom) help ensure > "a header file always includes all symbols it requires”? Given an incomplete header // foo.hpp std::string f(); // foo.cpp #include “foo.hpp” #include std::string f() { return {}; }

Re: Order of includes

Hi Yan, I don’t feel too strongly about most of our style rules regarding include ordering since they are just about style. > For a cpp file foo.cpp, our style guide instructs folks to put the header > foo.hpp at the top of the include list: >

Re: New Defects reported by Coverity Scan for Mesos

Hi, I filed https://issues.apache.org/jira/browse/MESOS-6726 to address this issue in particular and https://issues.apache.org/jira/browse/MESOS-6727 to more generally remove the dangerous overload used here. HTH, Benjamin > On Dec 6, 2016, at 4:40 AM, scan-ad...@coverity.com wrote: > > >

Re: [11/13] mesos git commit: Wired the libprocess code to use the streaming decoder.

Hi, just came across this with our `mesos-this-capture` clang-tidy check: > +// It is guaranteed that the continuation would run before the next > +// request arrives. Also, it's fine to pass the `this` pointer to the > +// continuation as this would get executed synchronously (if

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

Hi, This introduces a possibly uninitialized member `weight_info` which Coverity immediately detected. I filed MESOS-6604 for that. Could you please take that on @Alexander? Cheers, Benjamin > On Nov 16, 2016, at 6:00 PM, m...@apache.org wrote: > > Enabled multiple field based

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

Hi, >> What do folks think about removing future timeouts in tests altogether? >> Instead, we can time the whole suite differently on different CIs? > Has there been any response from the ASF Infra folks on addressing the > VM/hardware issues? Seems like it will be difficult to get good signal >

Re: 0.28.3 release dashboard!

Hi Joseph and Anand, > We are planning to cut this patch release within three workdays - that would > be around Monday next week. So, if you have any patches that need to get into > 0.28.3 make sure that either it is already in the 0.28.x branch or the > corresponding ticket has a target

Design doc for rlimit support in Mesos

Hi, we are interested in exposing user resource limits (rlimits) to Mesos so executors can prepare environments for task with differing limit requirements. The design doc can be found here, https://docs.google.com/document/d/148og6TlknWIG2d-VmyCG01eliiOGhNEc12mG4TWsfHU/edit?usp=sharing

Parallel test runner added

Hi, Since most tests in the Mesos, libprocess, and stout test suites can be executed in parallel (the exception being some `ROOT` tests with global side effects in Mesos), we recently added a parallel test runner `support/mesos-gtest-runner.py`. This should allow to potentially significantly

Re: Separate Compilation of Tests

Hi, being able to iterate more rapidly on tests sounds great. I am slightly unsure about the cost of (i) linking even more binaries, and (ii) the overhead of setting up the test environment for the invocations of test binaries (I believe this was O(100ms) per `main` at some point). I believe if

Re: mesos git commit: Updated quota endpoint help.

Hi, the way one currently has to manually regenerate markdown outputs which should then be checked in together (and ideally: atomically) with the corresponding source changes seems to be a reoccurring source of friction. I understand that being able to e.g., reference the generated markdown

Re: Looking for shepherd (MESOS-4807)

Hi Yong, > I am looking for shepherd to help me on MESOS-4807. > > https://issues.apache.org/jira/browse/MESOS-4807 > > This issue is similar to MESOS-4806 as both of them tries to fixes issues > that could parallelize the tests in mesos. Would appreciate if anyone could > shepherd to help

Re: Request Mesos contributor role

Hi, >> Error: >> 2016-01-14 09:19:38 URL:https://reviews.apache.org/r/42288/diff/raw/ >> [612/612] -> "42288.patch" [1] >> Total errors found: 0 >> Checking 1 files >> Error: Commit message summary (the first line) must not exceed 72 characters. > >> my patch first line is: >> diff --git

Re: Using dolt instead of libel when possible

Hi, > On Jan 5, 2016, at 8:08 PM, James Peach <jor...@gmail.com> wrote: >> On Jan 5, 2016, at 12:59 AM, Benjamin Bannier >> <benjamin.bann...@mesosphere.io> wrote: >> dolt is a replacement for libtool which promises to fix some performance >> issues of l

Using dolt instead of libel when possible

Hi, dolt is a replacement for libtool which promises to fix some performance issues of libtool, many of which have since dolt’s release landed in some versions of libtool. I have made some first measurements of dolt under Debian8 (hardly any improvement) and OS X 10.10.5 (noticeable

How do you use the fetcher cache?

Hi, In mesos-0.23.0 we added support for caching fetched artifacts (as described by `CommandInfo::URI`). Here if caching was enabled for an URI re-downloading of known artifacts could be avoided if the artifacts were still inside a slave-internal LRU-style artifact cache. Currently the caching

Re: Mesos Style Guideline Adjustments

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

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

Hi, thanks everyone for providing suggestions and feedback. It seems we reached a consensus to implement option (a): > (a) change *all* license headers to be wrapped in e.g. `/* .. */`, also > update the coding guidelines, or and to keep improving the documentation in the code to provide

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

...@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...@

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

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