Renaming the topic because apparently we need to have this discussion again.

First I'd like to thank Charles-François Natali for his patience and recent contributions.

Second, I'd like say I agree with everything they have said regarding the state of project. The project can't even begin to talk new features until some housekeeping is done (not to mention the incredible backlog on JIRA).

As of right now, there's currently 3-4 pull requests waiting on reviews and we can't put this all on Andrei to do. The last 4 PRs made by folks have been open for 10, 12, 14,and 25 days respectively, and the authors seem to be very eager for them to land (there was one more waiting to be merged which thankfully was merged by Andrei).

As I've said in a previous email: I've been here before in the same situation with Apache Aurora.

Unless new committers and PMC members are added, someone dedicated to continuing the project like Charles-François, will be left with no choice but to explore the option of forking and renaming the project due to Apache owning the Mesos trademark.

Therefore, the PMC *must* add members or the project  *will* fizzle out and die.

I'd also be curious to see if we even have enough PMC members to form a quorum at the moment as I only see Andrei Sekretenko reviewing pull requests on Github and the new chair Qian Zhang on emails. The project needs three PMC members for the project to be considered in a good state according to the Apache guidelines [0].

At this point I suggest the PMC does a roll call and get Apche board members involved so that they can be aware of the situation.

-Renan

[0]https://www.apache.org/dev/pmc.html

On 5/24/21 10:21 AM, Charles-François Natali wrote:
Hey,

Le lun. 24 mai 2021 à 14:12, Qian Zhang <zhq527...@gmail.com> a écrit :
several fixing bugs which basically make Mesos unusable on a recent Linux
distro
Can you please elaborate a bit on this? Do you mean Mesos not working on a
recent Linux distro? If so, I think we can start to fix the issues and
maybe do a patch release for that.
Yes, there are several issues on recent Linux distributions, e.g.
Debian Bullseye:
- https://github.com/apache/mesos/pull/387: compilaiton error,
although it's only in master not in the last release
- https://github.com/apache/mesos/pull/388: problem with the freezer
cgroup based task killer which causes over a dozen test to fail and
can leave the freezer frozen, tasks in uninterruptible state etc
- https://github.com/apache/mesos/pull/384: problem parsing
ld.so.cache which also breaks a lot of things

You were tagged in some of this MRs, I tagged you in all of them, it'd
be great if you could have a look :).

Cheers,


Regards,
Qian Zhang


On Fri, May 21, 2021 at 2:57 AM Charles-François Natali <cf.nat...@gmail.com>
wrote:

Hey,

Sorry for being a killjoy and repeating myself, but as mentioned in
the past, I don't think that technical direction is the most important
problem right now - community is.
Coming up with medium/long-term technical roadmap doesn't do much if
there are no contributors to implement them, and users to use them.

The following issues which have been brought up are still not resolved:
- very few committers willing to review and merge MRs - currently only
Andrei Sekretenko is doing that, and I'm sure he's busy with his day
job so only has that much bandwidth
- very few people contribute MRs and triage/address JIRA issues -
AFAICT it's pretty much Andreas and me

So I think the first thing to do would be to address those problems.
Some suggestions which come to mind:
- to the remaining committers who'd still like to salvage the project,
please take some time to review and merge MRs -
https://github.com/apache/mesos/pulls has a few open, several fixing
bugs which basically make Mesos unusable on a recent Linux distro
- to the various users who've said they were interested in keeping the
project alive: start contributing. It doesn't have to be anything big,
just get familiar with the code base:
   * start going through JIRA and triage bugs, closing invalid/stale
ones, tackling small issues
   * submit MRs so that the test suite passes on your OS
   * submit MRs to merge various commits you have in your private repos
if applicable

Then in a few months, once the project  is back to having a small
active contributors base, they can together decide how to take the
project forward, and start addressing larger projects.

Cheers,

Charles






Le jeu. 20 mai 2021 à 18:16, Gregoire Seux <g.s...@criteo.com> a écrit :
Hi,

Interesting set of suggestions! Here are a few comments:

   *   Mesos feels simple to deploy (only very few components: zookeeper,
masters and agents), customization is done mostly through configuration
files. I don't think there is a strong need to make it easier (even though
I've used Mesos for years, so I'm pretty used to the difficulty if any)
   *   Having to manage Zookeeper adds some complexity but since
Zookeeper piece is required to operate Marathon (which is our main
framework), I don't see much value in the investment required to get rid of
this dependency.
   *   Taking advantage of NUMA topology by default would be a good
addition although I don't see it as strategic (at least we have solved this
on our clusters with custom modules)
   *   I would love to see improvement on masters scalability for large
clusters (our largest cluster is 3500 nodes and may start to suffer from
the actor model)
Something that I see as a very significant drawback to the ecosystem at
large is the difficulty to write frameworks. In addition to this, most
open-source frameworks feel abandoned. Without good frameworks, Mesos value
really decreases a lot (although it is very technically strong).
I think, making Mesos thrive would necessarily go through a solution to
this issue.
Something that I'd see as strategic would be the ability to deploy
complex workloads on Mesos without having to write a new framework. Random
idea: make Mesos really usable as a backend for Kubernetes (as a virtual
kubelet). This would remove a lot of barriers to use Mesos as a strong
engine to operate a fleet of servers while allowing to use the Kubernetes
API that apparently everybody loves.
What do you think?

--
Grégoire Seux

Reply via email to