You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@mesos.apache.org by Damien GERARD <da...@iwi.me> on 2021/03/01 01:05:28 UTC
Re: Feature requests for Mesos
On 2021-02-28 05:38 PM, Qian Zhang wrote:
> Hi Folks,
>
> To reboot this awesome project, I'd like to collect feature requests
> for Mesos. Please let us know your requirements for Mesos and whether
> you or your organization would like to contribute to the
> implementation of the requirements. Thanks!
We can already summarize what has been said in previous discussions,
mainly
making mesos easier to deploy / maintain, and my personal one, with more
batteries included by default.
There are also several ways of improvements, especially regarding GPU
support,
numa, ZFS integration, volume management...
But first, reducing the effort to have a fully functional mesos cluster
would be to me, one of the priorities (and also targeting local
development
like minimesos was trying to achieve)
--
Damien GERARD
RE: Feature requests for Mesos
Posted by Chris Holman <Ch...@eu.medical.canon>.
>On 2021-02-28 05:38 PM, Qian Zhang wrote:
>> Hi Folks,
>>
>> To reboot this awesome project, I'd like to collect feature requests
>> for Mesos. Please let us know your requirements for Mesos and whether
>> you or your organization would like to contribute to the
>> implementation of the requirements. Thanks!
>
>We can already summarize what has been said in previous discussions, mainly making mesos easier to deploy / maintain, and my personal one, with more batteries included by default.
>There are also several ways of improvements, especially regarding GPU support, numa, ZFS integration, volume management...
>
>But first, reducing the effort to have a fully functional mesos cluster would be to me, one of the priorities (and also targeting local development like minimesos was trying to achieve)
>
>
>--
>Damien GERARD
Ease of install is definitely something that would make it easier for others to use and experiment with Mesos.
I've just been through the process of setting up a Mesos cluster and it's definitely a right-of-passage.
Not a particularly fun experience, but primarily because I wanted ssl enabled.
I'm using an Ansible playbook to deploy a Linux/Windows Mesos cluster for a Jenkins Build Farm.
I've made a few local mods to:
* Mesos to support Windows and ssl (not complete)
* Jenkins Mesos Plugin (and mesos-usi) to support reusable Agents and Mesos attribute operators i.e. match Mesos offers with an attribute version [lt|le|gt|eq|ne|ge|gt] '2.2.2'
Regards, Chris
Re: Feature requests for Mesos
Posted by Abel Souza <ab...@cs.umu.se>.
+1 HPC support, but this requires NUMA support and cgroup features, besides easier to write modules for new scheduling techniques (beyond DRF).
/Abel
> On 1 Mar 2021, at 09:43, Damien GERARD <da...@iwi.me> wrote:
>
> On 2021-03-01 04:14 PM, Klaus Ma wrote:
>> Mesos is really a great project!
>> In addition to new features, is it possible to make Mesos focus on
>> some specific area, e.g. HPC?
>
> I really do think also that HPC should be a target :)
>
>> -- Klaus
>> <http://k82.me/>
>> ________________________________
>> From: Damien GERARD <da...@iwi.me>
>> Sent: Monday, March 1, 2021 1:05 AM
>> To: user@mesos.apache.org <us...@mesos.apache.org>
>> Cc: mesos <de...@mesos.apache.org>
>> Subject: Re: Feature requests for Mesos
>>> On 2021-02-28 05:38 PM, Qian Zhang wrote:
>>> Hi Folks,
>>> To reboot this awesome project, I'd like to collect feature requests
>>> for Mesos. Please let us know your requirements for Mesos and whether
>>> you or your organization would like to contribute to the
>>> implementation of the requirements. Thanks!
>> We can already summarize what has been said in previous discussions,
>> mainly
>> making mesos easier to deploy / maintain, and my personal one, with more
>> batteries included by default.
>> There are also several ways of improvements, especially regarding GPU
>> support,
>> numa, ZFS integration, volume management...
>> But first, reducing the effort to have a fully functional mesos cluster
>> would be to me, one of the priorities (and also targeting local
>> development
>> like minimesos was trying to achieve)
>> --
>> Damien GERARD
>
> --
> Damien GERARD
Re: Feature requests for Mesos
Posted by Damien GERARD <da...@iwi.me>.
On 2021-03-01 04:14 PM, Klaus Ma wrote:
> Mesos is really a great project!
>
> In addition to new features, is it possible to make Mesos focus on
> some specific area, e.g. HPC?
I really do think also that HPC should be a target :)
>
> -- Klaus
> <http://k82.me/>
> ________________________________
> From: Damien GERARD <da...@iwi.me>
> Sent: Monday, March 1, 2021 1:05 AM
> To: user@mesos.apache.org <us...@mesos.apache.org>
> Cc: mesos <de...@mesos.apache.org>
> Subject: Re: Feature requests for Mesos
>
> On 2021-02-28 05:38 PM, Qian Zhang wrote:
>> Hi Folks,
>>
>> To reboot this awesome project, I'd like to collect feature requests
>> for Mesos. Please let us know your requirements for Mesos and whether
>> you or your organization would like to contribute to the
>> implementation of the requirements. Thanks!
>
> We can already summarize what has been said in previous discussions,
> mainly
> making mesos easier to deploy / maintain, and my personal one, with
> more
> batteries included by default.
> There are also several ways of improvements, especially regarding GPU
> support,
> numa, ZFS integration, volume management...
>
> But first, reducing the effort to have a fully functional mesos cluster
> would be to me, one of the priorities (and also targeting local
> development
> like minimesos was trying to achieve)
>
>
> --
> Damien GERARD
--
Damien GERARD
RE: Feature requests for Mesos
Posted by Marc <Ma...@f1-outsourcing.eu>.
> What is the estimated size of such a team? And is there any data
> available how many man hours were committed by mesosphere the last year
> or so?
>
>
If questions are raised about creating a proper support base for the future development of mesos. Is it not relevant to have some numbers on what mesossphere/id2q spend on this the last 3 years or so?
RE: Feature requests for Mesos
Posted by Marc <Ma...@f1-outsourcing.eu>.
>
> I think the key issues have been brought up by Benjamin and Renan.
>
> Just to add to Benjamin's comments above, achieving those key markers of
> a healthy project requires serious corporate backing such that people
> are being
> employed to primarily work on Mesos. It takes a lot of work to keep the
> project
> running along and if people are doing that on the side or as a hobby it
> is going
> to be unsustainable.
>
> In the initial phase of the project, there was a team dedicated to Mesos
> at Twitter,
What is the estimated size of such a team? And is there any data available how many man hours were committed by mesosphere the last year or so?
Re: Feature requests for Mesos
Posted by Charles-François Natali <cf...@gmail.com>.
I think it's fair, but it would be nice if the current committers could
reach a consensus on the way forward: either be willing to help new
contributors get up to speed - with the caveats mentioned - or move the
project to the Attic, so that interested people can try to
maintain/continue its development outside of the ASF. The current state of
the project being in limbo is quite sad and prevents any work from being
done.
These email threads started 3 weeks ago and so far nothing concrete has
been done, at least from an outsider point of view.
Cheers,
Charles
On Tue, 9 Mar 2021, 09:16 Andrei Sekretenko, <as...@gmail.com> wrote:
> I think Benjamin Bannier and Benjamin Mahler are right about the
> immediate non-technical issues and how the backing of the project
> could/could not look like in future.
>
> I would say that the main root cause of both the non-technical
> troubles and the lack of the backing is the issue of the long-term
> direction of the project. Infrastructure components are notoriously
> prone (maybe much more prone than some other kinds of software) to the
> following feedback loop: the larger the installed base, the more
> battle-tested and thus stable the project becomes (despite the growing
> complexity), the larger the installed base is.
>
> Under the current circumstances, this, in my view, means that Mesos
> has no long-term prospects unless it manages to shift to a
> niche/role/direction in which the problems cannot be reasonably solved
> by the Kubernetes-style cluster orchestration.
>
> Should we - despite the current issue of the long-term direction -
> find people/entities willing to support the project in future, there
> will be a task of experience transfer, regardless of whether Mesos
> continues to be an ASF project or not. In the past, the experience
> transfer used to occur from persons with a history of contributing to
> the project (i.e. committers) to ones contributing (who, under the
> Apache paradigm, eventually became new committers).
>
> The task of experience transfer IMO is only potentially solvable if
> there is going to be a _significant_ contribution coming from a _few_
> individuals. Under other circumstances (say, 20 people contributing 2
> small bugfixes each), the efforts of current committers to review that
> - even if some of us will be able to do that on a side - are going to
> be spread thin and will not lead to getting more people with
> significant experience on the project. The latter, in turn, is not a
> good motivation to reviewing contribution on a non-paid basis (and
> even on a paid basis, especially given that most committers seem to
> have a full-time occupation not relevant - or, like me, no longer
> really relevant - to working on Mesos).
>
> Best,
> Andrei Sekretenko
>
> P.S. Sorry folks, in general I hate to fuel self-fulfilling
> prophecies, but what I tried to explain above had to be said
> explicitly.
>
>
> On Mon, 8 Mar 2021 at 21:41, Benjamin Mahler <bm...@apache.org> wrote:
> >
> > I think the key issues have been brought up by Benjamin and Renan.
> >
> > Just to add to Benjamin's comments above, achieving those key markers of
> > a healthy project requires serious corporate backing such that people
> are being
> > employed to primarily work on Mesos. It takes a lot of work to keep the
> project
> > running along and if people are doing that on the side or as a hobby it
> is going
> > to be unsustainable.
> >
> > In the initial phase of the project, there was a team dedicated to Mesos
> at Twitter,
> > which is how the system was productionized and core features were
> developed.
> > The second phase of the project, in which Twitter was largely absent,
> was driven
> > by Mesosphere (now called D2iQ) along with a few people making sporadic
> > contributions. With the shift in D2iQs priorities away from Mesos, the
> project is
> > now without corporate backing.
> >
> > Ultimately, I think with a project like Mesos those corporate backers
> tend to be
> > vendors rather than users, because vendors can justify the investment as
> a core
> > part of their business whereas users cannot. The vendors in this space
> have
> > consolidated around kubernetes.
> >
> > An alternative model to vendor driven development would be to have a
> > foundation that allows users to fund development in the project, but
> this model
> > requires donations which seems prone to persistent underfunding. (Reading
> > the wikipedia sections on freebsd and openbsd funding shows examples of
> > these alternative models).
> >
> > So I see two options related to how the project is backed:
> >
> > - Vendor and user companies are employing engineers to work on Mesos
> > because either they have products based on Mesos, or use it heavily.
> >
> > - Users / Companies / Other bodies donate to a foundation which houses
> the
> > project and drives the development using these donations / resources.
> >
> > The current model of Apache + maybe some folks stepping up to help I
> > don't think will work.
> >
> > On Sun, Mar 7, 2021 at 6:39 PM Marc <Ma...@f1-outsourcing.eu> wrote:
> >>
> >>
> >> * csi slrp unmanaged driver
> >> (unless it is possible to work around enabling SYS_ADMIN in
> bounding_capabilities for all tasks)
> >> * csi serp
> >>
> >>
> >> http://mesos.apache.org/documentation/latest/csi/#limitations
> >> https://issues.apache.org/jira/browse/MESOS-8371
> >>
>
RE: Feature requests for Mesos
Posted by Marc <Ma...@f1-outsourcing.eu>.
>
> Under the current circumstances, this, in my view, means that Mesos
> has no long-term prospects unless it manages to shift to a
> niche/role/direction in which the problems cannot be reasonably solved
> by the Kubernetes-style cluster orchestration.
>
If I read (outdated?) articles such as these[1] I wonder how currently mesos compares to kubernetes. Has kubernetes developed into the direction of mesos. Here they seem to be pretty pleased about the scheduler functionality of mesos.
[1]
https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/
Re: Feature requests for Mesos
Posted by Andrei Sekretenko <as...@gmail.com>.
I think Benjamin Bannier and Benjamin Mahler are right about the
immediate non-technical issues and how the backing of the project
could/could not look like in future.
I would say that the main root cause of both the non-technical
troubles and the lack of the backing is the issue of the long-term
direction of the project. Infrastructure components are notoriously
prone (maybe much more prone than some other kinds of software) to the
following feedback loop: the larger the installed base, the more
battle-tested and thus stable the project becomes (despite the growing
complexity), the larger the installed base is.
Under the current circumstances, this, in my view, means that Mesos
has no long-term prospects unless it manages to shift to a
niche/role/direction in which the problems cannot be reasonably solved
by the Kubernetes-style cluster orchestration.
Should we - despite the current issue of the long-term direction -
find people/entities willing to support the project in future, there
will be a task of experience transfer, regardless of whether Mesos
continues to be an ASF project or not. In the past, the experience
transfer used to occur from persons with a history of contributing to
the project (i.e. committers) to ones contributing (who, under the
Apache paradigm, eventually became new committers).
The task of experience transfer IMO is only potentially solvable if
there is going to be a _significant_ contribution coming from a _few_
individuals. Under other circumstances (say, 20 people contributing 2
small bugfixes each), the efforts of current committers to review that
- even if some of us will be able to do that on a side - are going to
be spread thin and will not lead to getting more people with
significant experience on the project. The latter, in turn, is not a
good motivation to reviewing contribution on a non-paid basis (and
even on a paid basis, especially given that most committers seem to
have a full-time occupation not relevant - or, like me, no longer
really relevant - to working on Mesos).
Best,
Andrei Sekretenko
P.S. Sorry folks, in general I hate to fuel self-fulfilling
prophecies, but what I tried to explain above had to be said
explicitly.
On Mon, 8 Mar 2021 at 21:41, Benjamin Mahler <bm...@apache.org> wrote:
>
> I think the key issues have been brought up by Benjamin and Renan.
>
> Just to add to Benjamin's comments above, achieving those key markers of
> a healthy project requires serious corporate backing such that people are being
> employed to primarily work on Mesos. It takes a lot of work to keep the project
> running along and if people are doing that on the side or as a hobby it is going
> to be unsustainable.
>
> In the initial phase of the project, there was a team dedicated to Mesos at Twitter,
> which is how the system was productionized and core features were developed.
> The second phase of the project, in which Twitter was largely absent, was driven
> by Mesosphere (now called D2iQ) along with a few people making sporadic
> contributions. With the shift in D2iQs priorities away from Mesos, the project is
> now without corporate backing.
>
> Ultimately, I think with a project like Mesos those corporate backers tend to be
> vendors rather than users, because vendors can justify the investment as a core
> part of their business whereas users cannot. The vendors in this space have
> consolidated around kubernetes.
>
> An alternative model to vendor driven development would be to have a
> foundation that allows users to fund development in the project, but this model
> requires donations which seems prone to persistent underfunding. (Reading
> the wikipedia sections on freebsd and openbsd funding shows examples of
> these alternative models).
>
> So I see two options related to how the project is backed:
>
> - Vendor and user companies are employing engineers to work on Mesos
> because either they have products based on Mesos, or use it heavily.
>
> - Users / Companies / Other bodies donate to a foundation which houses the
> project and drives the development using these donations / resources.
>
> The current model of Apache + maybe some folks stepping up to help I
> don't think will work.
>
> On Sun, Mar 7, 2021 at 6:39 PM Marc <Ma...@f1-outsourcing.eu> wrote:
>>
>>
>> * csi slrp unmanaged driver
>> (unless it is possible to work around enabling SYS_ADMIN in bounding_capabilities for all tasks)
>> * csi serp
>>
>>
>> http://mesos.apache.org/documentation/latest/csi/#limitations
>> https://issues.apache.org/jira/browse/MESOS-8371
>>
Re: Feature requests for Mesos
Posted by Benjamin Mahler <bm...@apache.org>.
I think the key issues have been brought up by Benjamin and Renan.
Just to add to Benjamin's comments above, achieving those key markers of
a healthy project requires serious corporate backing such that people are
being
employed to primarily work on Mesos. It takes a lot of work to keep the
project
running along and if people are doing that on the side or as a hobby it is
going
to be unsustainable.
In the initial phase of the project, there was a team dedicated to Mesos at
Twitter,
which is how the system was productionized and core features were developed.
The second phase of the project, in which Twitter was largely absent, was
driven
by Mesosphere (now called D2iQ) along with a few people making sporadic
contributions. With the shift in D2iQs priorities away from Mesos, the
project is
now without corporate backing.
Ultimately, I think with a project like Mesos those corporate backers tend
to be
vendors rather than users, because vendors can justify the investment as a
core
part of their business whereas users cannot. The vendors in this space have
consolidated around kubernetes.
An alternative model to vendor driven development would be to have a
foundation that allows users to fund development in the project, but this
model
requires donations which seems prone to persistent underfunding. (Reading
the wikipedia sections on freebsd and openbsd funding shows examples of
these alternative models).
So I see two options related to how the project is backed:
- Vendor and user companies are employing engineers to work on Mesos
because either they have products based on Mesos, or use it heavily.
- Users / Companies / Other bodies donate to a foundation which houses the
project and drives the development using these donations / resources.
The current model of Apache + maybe some folks stepping up to help I
don't think will work.
On Sun, Mar 7, 2021 at 6:39 PM Marc <Ma...@f1-outsourcing.eu> wrote:
>
> * csi slrp unmanaged driver
> (unless it is possible to work around enabling SYS_ADMIN in
> bounding_capabilities for all tasks)
> * csi serp
>
>
> http://mesos.apache.org/documentation/latest/csi/#limitations
> https://issues.apache.org/jira/browse/MESOS-8371
>
>
RE: Feature requests for Mesos
Posted by Marc <Ma...@f1-outsourcing.eu>.
* csi slrp unmanaged driver
(unless it is possible to work around enabling SYS_ADMIN in bounding_capabilities for all tasks)
* csi serp
http://mesos.apache.org/documentation/latest/csi/#limitations
https://issues.apache.org/jira/browse/MESOS-8371
Re: Feature requests for Mesos
Posted by Moula BADJI <mo...@gmail.com>.
HPC +1
Thank's
Moula.
Le 01/03/2021 à 08:14, Klaus Ma a écrit :
> Mesos is really a great project!
>
> In addition to new features, is it possible to make Mesos focus on
> some specific area, e.g. HPC?
>
> -- Klaus
> ------------------------------------------------------------------------
> *From:* Damien GERARD <da...@iwi.me>
> *Sent:* Monday, March 1, 2021 1:05 AM
> *To:* user@mesos.apache.org <us...@mesos.apache.org>
> *Cc:* mesos <de...@mesos.apache.org>
> *Subject:* Re: Feature requests for Mesos
> On 2021-02-28 05:38 PM, Qian Zhang wrote:
> > Hi Folks,
> >
> > To reboot this awesome project, I'd like to collect feature requests
> > for Mesos. Please let us know your requirements for Mesos and whether
> > you or your organization would like to contribute to the
> > implementation of the requirements. Thanks!
>
> We can already summarize what has been said in previous discussions,
> mainly
> making mesos easier to deploy / maintain, and my personal one, with more
> batteries included by default.
> There are also several ways of improvements, especially regarding GPU
> support,
> numa, ZFS integration, volume management...
>
> But first, reducing the effort to have a fully functional mesos cluster
> would be to me, one of the priorities (and also targeting local
> development
> like minimesos was trying to achieve)
>
>
> --
> Damien GERARD
Re: Feature requests for Mesos
Posted by Damien GERARD <da...@iwi.me>.
On 2021-03-01 04:14 PM, Klaus Ma wrote:
> Mesos is really a great project!
>
> In addition to new features, is it possible to make Mesos focus on
> some specific area, e.g. HPC?
I really do think also that HPC should be a target :)
>
> -- Klaus
> <http://k82.me/>
> ________________________________
> From: Damien GERARD <da...@iwi.me>
> Sent: Monday, March 1, 2021 1:05 AM
> To: user@mesos.apache.org <us...@mesos.apache.org>
> Cc: mesos <de...@mesos.apache.org>
> Subject: Re: Feature requests for Mesos
>
> On 2021-02-28 05:38 PM, Qian Zhang wrote:
>> Hi Folks,
>>
>> To reboot this awesome project, I'd like to collect feature requests
>> for Mesos. Please let us know your requirements for Mesos and whether
>> you or your organization would like to contribute to the
>> implementation of the requirements. Thanks!
>
> We can already summarize what has been said in previous discussions,
> mainly
> making mesos easier to deploy / maintain, and my personal one, with
> more
> batteries included by default.
> There are also several ways of improvements, especially regarding GPU
> support,
> numa, ZFS integration, volume management...
>
> But first, reducing the effort to have a fully functional mesos cluster
> would be to me, one of the priorities (and also targeting local
> development
> like minimesos was trying to achieve)
>
>
> --
> Damien GERARD
--
Damien GERARD
Re: Feature requests for Mesos
Posted by Klaus Ma <kl...@gmail.com>.
Mesos is really a great project!
In addition to new features, is it possible to make Mesos focus on some specific area, e.g. HPC?
-- Klaus
<http://k82.me/>
________________________________
From: Damien GERARD <da...@iwi.me>
Sent: Monday, March 1, 2021 1:05 AM
To: user@mesos.apache.org <us...@mesos.apache.org>
Cc: mesos <de...@mesos.apache.org>
Subject: Re: Feature requests for Mesos
On 2021-02-28 05:38 PM, Qian Zhang wrote:
> Hi Folks,
>
> To reboot this awesome project, I'd like to collect feature requests
> for Mesos. Please let us know your requirements for Mesos and whether
> you or your organization would like to contribute to the
> implementation of the requirements. Thanks!
We can already summarize what has been said in previous discussions,
mainly
making mesos easier to deploy / maintain, and my personal one, with more
batteries included by default.
There are also several ways of improvements, especially regarding GPU
support,
numa, ZFS integration, volume management...
But first, reducing the effort to have a fully functional mesos cluster
would be to me, one of the priorities (and also targeting local
development
like minimesos was trying to achieve)
--
Damien GERARD
Re: Feature requests for Mesos
Posted by Klaus Ma <kl...@gmail.com>.
Mesos is really a great project!
In addition to new features, is it possible to make Mesos focus on some specific area, e.g. HPC?
-- Klaus
<http://k82.me/>
________________________________
From: Damien GERARD <da...@iwi.me>
Sent: Monday, March 1, 2021 1:05 AM
To: user@mesos.apache.org <us...@mesos.apache.org>
Cc: mesos <de...@mesos.apache.org>
Subject: Re: Feature requests for Mesos
On 2021-02-28 05:38 PM, Qian Zhang wrote:
> Hi Folks,
>
> To reboot this awesome project, I'd like to collect feature requests
> for Mesos. Please let us know your requirements for Mesos and whether
> you or your organization would like to contribute to the
> implementation of the requirements. Thanks!
We can already summarize what has been said in previous discussions,
mainly
making mesos easier to deploy / maintain, and my personal one, with more
batteries included by default.
There are also several ways of improvements, especially regarding GPU
support,
numa, ZFS integration, volume management...
But first, reducing the effort to have a fully functional mesos cluster
would be to me, one of the priorities (and also targeting local
development
like minimesos was trying to achieve)
--
Damien GERARD