RE: adding sortlist to /etc/resolv.conf in container

[Marc]

I am not entirely sure what you mean. The ip ranges are on different vlans and 
a hostname is being resolved is on both vlans, hence other tasks are being 
informed via mesos-dns about the other range. 

> It is easier if you enable it through the network. Stop following the
> easiest.
> 
> >
> > Hi,
> >
> > I was wondering if anyone knows how I could get this sortlist entry
> added to an /etc/resolv.conf?
> >
> > sortlist 192.168.x.0/255.255.255.0
> >
> > Could it be that I maybe have 'older' cni drivers as from such a config
> below I don't see search and domain being added to /etc/resolve.conf. I
> see however this nameserver being added.
> >
> > {
> >  "name": "cni-test",
> >  "type" : "mesos",
> >  "delegate": {
> > .
> > .
> > .
> >"ipam": {
> > .
> > .
> >  "resolvConf": "/etc/resolv.conf",
> >  "ranges": [
> >  [
> >{
> > .
> > .
> > .
> >}
> >  ] ]
> >},
> >"dns": {
> >  "nameservers": ["192.168.0.1"],
> >  "search": ["local2"],
> >  "domain": "thisdomain"
> >}
> >  }
> > }
> >
> >
> >
> >

Re: adding sortlist to /etc/resolv.conf in container

[Abel Souza]

It is easier if you enable it through the network. Stop following the easiest.

> On May 27, 2024, at 03:46, Marc  wrote:
> 
> Hi,
> 
> I was wondering if anyone knows how I could get this sortlist entry added to 
> an /etc/resolv.conf?
> 
> sortlist 192.168.x.0/255.255.255.0
> 
> Could it be that I maybe have 'older' cni drivers as from such a config below 
> I don't see search and domain being added to /etc/resolve.conf. I see however 
> this nameserver being added.
> 
> {
>  "name": "cni-test",
>  "type" : "mesos",
>  "delegate": {
> .
> .
> .
>"ipam": {
> .
> .
>  "resolvConf": "/etc/resolv.conf",
>  "ranges": [
>  [
>{
> .
> .
> .
>}
>  ] ]
>},
>"dns": {
>  "nameservers": ["192.168.0.1"],
>  "search": ["local2"],
>  "domain": "thisdomain"
>}
>  }
> }
> 
> 
> 
> 

Re: Docker images not starting since version 26

[samiksha baskar]

unsubscribe

On Sun, Apr 21, 2024 at 10:49 PM Frank Wettstein <
frank.wettst...@intersys.ch> wrote:

> After an update of Docker to the version 26 my docker images deployed in
> Mesos/Marathon are not starting
>
> anymore.
>
>
>
> The reason is probably due to the following:
>
> In version 26 Docker the field “Container” and “ContainerConfig” were
> removed from docker inspect
>
> (see
> https://docs.docker.com/engine/deprecated/#container-and-containerconfig-fields-in-image-inspect
> )
>
>
>
> However, https://github.com/apache/mesos/blob/master/src/docker/docker.cpp
> is using these fields.
>
>
>
>
>
>
>

RE: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Marc]

>   On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler
> mailto:bmah...@apache.org> > wrote:
> 
> 
>   As part of upgrading to CentOS 9 at X/Twitter, Shatil /
> Devin (cc'ed) will be working on:
> 
>   * Upgrading to Python 3
>   * Cgroups v2 support
> 

I was thinking of moving to rocky el9 is this supported? Is there are a public 
repo for rpms still?

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Tobi Knaup]

Great to see the early crew coming out of the woodwork. You guys are
awesome!

On Wed, Apr 17, 2024 at 16:30 Marcel Neuhausler 
wrote:

> Very very happy to see Benjamin and team at X contributing those patches,
> including urgently needed support for cgroups v2, to the open-source
> version.
>
> Keeps our Mesos clusters going for another few years :-)
>
> Thank you, thank you!
> --Marcel
>
>
> On Apr 3, 2024, at 09:27, Benjamin Mahler  wrote:
>
> 
> Just an update here, in late January we finished upstreaming our internal
> patches that were upstreamable. This amounted to 35 patches.
>
> The cgroups v2 work is ongoing, we're hoping to be mostly code complete by
> the end of this month.
>
> On Fri, Jan 12, 2024 at 6:01 PM Benjamin Mahler 
> wrote:
>
>> +user@
>>
>> On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler 
>> wrote:
>>
>>> As part of upgrading to CentOS 9 at X/Twitter, Shatil / Devin (cc'ed)
>>> will be working on:
>>>
>>> * Upgrading to Python 3
>>> * Cgroups v2 support
>>>
>>> We will attempt to upstream this work for the benefit of other users.
>>>
>>> In addition, we have several long-standing internal patches that should
>>> have been upstreamed but weren't. We currently deploy from an internal
>>> 1.9.x branch with these additional patches on top of OSS 1.9.x. To simplify
>>> the above work since the code changes will be substantial (especially for
>>> cgroups v2), we'll try to work off master (or 1.11.x) and upstream our
>>> long-standing internal patches to minimize the delta between OSS and our
>>> internal branch.
>>>
>>> Let me know if folks have any questions. IMO it would be good for users
>>> to hold off on going into the attic so that we can land this work at least.
>>>
>>> Ben
>>>
>>

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Marcel Neuhausler]

Very very happy to see Benjamin and team at X contributing those patches, including urgently needed support for cgroups v2, to the open-source version.Keeps our Mesos clusters going for another few years :-)Thank you, thank you!--MarcelOn Apr 3, 2024, at 09:27, Benjamin Mahler  wrote:Just an update here, in late January we finished upstreaming our internal patches that were upstreamable. This amounted to 35 patches.The cgroups v2 work is ongoing, we're hoping to be mostly code complete by the end of this month.On Fri, Jan 12, 2024 at 6:01 PM Benjamin Mahler  wrote:+user@On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler  wrote:As part of upgrading to CentOS 9 at X/Twitter, Shatil / Devin (cc'ed) will be working on:* Upgrading to Python 3* Cgroups v2 supportWe will attempt to upstream this work for the benefit of other users.In addition, we have several long-standing internal patches that should have been upstreamed but weren't. We currently deploy from an internal 1.9.x branch with these additional patches on top of OSS 1.9.x. To simplify the above work since the code changes will be substantial (especially for cgroups v2), we'll try to work off master (or 1.11.x) and upstream our long-standing internal patches to minimize the delta between OSS and our internal branch.Let me know if folks have any questions. IMO it would be good for users to hold off on going into the attic so that we can land this work at least.Ben

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Benjamin Mahler]

Just an update here, in late January we finished upstreaming our internal
patches that were upstreamable. This amounted to 35 patches.

The cgroups v2 work is ongoing, we're hoping to be mostly code complete by
the end of this month.

On Fri, Jan 12, 2024 at 6:01 PM Benjamin Mahler  wrote:

> +user@
>
> On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler 
> wrote:
>
>> As part of upgrading to CentOS 9 at X/Twitter, Shatil / Devin (cc'ed)
>> will be working on:
>>
>> * Upgrading to Python 3
>> * Cgroups v2 support
>>
>> We will attempt to upstream this work for the benefit of other users.
>>
>> In addition, we have several long-standing internal patches that should
>> have been upstreamed but weren't. We currently deploy from an internal
>> 1.9.x branch with these additional patches on top of OSS 1.9.x. To simplify
>> the above work since the code changes will be substantial (especially for
>> cgroups v2), we'll try to work off master (or 1.11.x) and upstream our
>> long-standing internal patches to minimize the delta between OSS and our
>> internal branch.
>>
>> Let me know if folks have any questions. IMO it would be good for users
>> to hold off on going into the attic so that we can land this work at least.
>>
>> Ben
>>
>

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Benjamin Mahler]

> The Python 3 upgrade shouldn't be too difficult; happy to help out. Make
> sure you duplicate your configuration so that CMake still works (happy to
> help there also). Just message (privately or publicly).

Yeah I think shatil mentioned the source translation was rather
straightforward, but the complexity is in the build dependencies (protobuf
/ grpc) and the scheduler / executor bindings (see below).

> Do you require both Python 2 and 3 bindings to work, or can we make a
clean
> migration to 3? I ask because there are breaking changes in C/C++ bindings
> going from 2 to 3, and supporting both will require conditionals rather
> than replacements of code blocks here and there. Dependencies may also end
> up incompatible between the two Python versions since some dropped Python
> 2.7 support a long time ago.

There are two areas of python code in our repo to consider:

1. Python code unrelated to scheduler / executor bindings (e.g. CLI, test
runner, etc), we can go directly to Python 3. Don't need 2 + 3
compatibility AFAICT.

2. Python scheduler / executor bindings, this is an older API that
we "replaced" with a newer HTTP API many years ago. I believe most
users have since adopted the HTTP API, but within X we still use both the
older CPython bindings and JNI bindings. At least for ourselves, we will
need an upgrade story, e.g.:

  a. Ideally, python 2 and python 3 works using the same bindings /
libmesos to simplify upgrades.
  b. Or, separate python 2 and python 3 bindings are available that work
with the same updated libmesos, this allows users to potentially de-couple
the scheduler / executor upgrade from their libmesos upgrade (upgrade
libmesos first, then upgrade executor or scheduler).
  c. Or, the python bindings are upgraded to python 3 only (upgrade
libmesos + executor/scheduler at the same time).

Is (a) even possible? It seems the simplest from an upgrade perspective.
If we choose (c), how will we do our python executor upgrade given we
deploy libmesos and the executor binary to our fleet separately?

On Sat, Jan 13, 2024 at 7:32 PM Qian Zhang  wrote:

> Thanks Ben! I have let Shane know this to hold off on going into the attic,
> and happy to help on the Cgroups v2 support :-)
>
>
> Regards,
> Qian Zhang
>
>
> On Sat, Jan 13, 2024 at 8:48 AM Samuel Marks  wrote:
>
> > On latest commit 5109b9069b62510ab6d0cc0c78a9ed8327d3986a `fd -epy | wc
> -l`
> > shows 73 files.
> >
> > mesos/src/python/cli/src/mesos/http.py requires a trivial change to
> support
> > Python 2 & 3. Everything else in that dir is fine.
> >
> > mesos/src/python/cli_new/lib/cli/util.py requires two lines to be
> > conditioned on Python 2/3 to resolve the now removed `imp` builtin
> module.
> >
> > mesos/src/python/cli/src/mesos/futures.py needs cancel_futures
> implemented
> > or stubbed with a `NotImplementedError` thrown
> >
> > Then you're down to 17 files left incompatible with Python 2 & 3.
> >
> > mesos/support has 15 of these files; quickly reading `rg -Ftpy import`
> > shows nothing interesting. Should be mostly trivial. Take care though to
> > remove distutils; as that was removed in Python 3.12.
> >
> > mesos/src/examples/python contains the final 2 Python files. A cursory
> > glance I can't see anything Python 2 & 3 incompatible.
> >
> > (happy to send the PR/patch or you can)
> >
> > Samuel Marks
> > Charity  | consultancy <
> https://offscale.io>
> > | open-source  | LinkedIn
> > 
> >
> >
> > On Fri, Jan 12, 2024 at 6:46 PM Shatil Rafiullah 
> > wrote:
> >
> > > Do you require both Python 2 and 3 bindings to work, or can we make a
> > > clean migration to 3? I ask because there are breaking changes in C/C++
> > > bindings going from 2 to 3, and supporting both will require
> conditionals
> > > rather than replacements of code blocks here and there. Dependencies
> may
> > > also end up incompatible between the two Python versions since some
> > dropped
> > > Python 2.7 support a long time ago.
> > >
> > > On Fri, Jan 12, 2024 at 3:18 PM Samuel Marks 
> wrote:
> > >
> > >> The Python 3 upgrade shouldn't be too difficult; happy to help out.
> Make
> > >> sure you duplicate your configuration so that CMake still works (happy
> > to
> > >> help there also). Just message (privately or publicly).
> > >>
> > >> Good to see interest in Mesos remaining,
> > >>
> > >> Samuel Marks
> > >> Charity
> > >> <
> >
> https://urldefense.com/v3/__https://sydneyscientific.org__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSXruBk3U$
> > >
> > >> | consultancy
> > >> <
> >
> https://urldefense.com/v3/__https://offscale.io__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSQf69uCY$
> > >
> > >> | open-source
> > >> <
> >
> https://urldefense.com/v3/__https://github.com/offscale__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSR5dWm9A$
> > >
> 

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Qian Zhang]

Thanks Ben! I have let Shane know this to hold off on going into the attic,
and happy to help on the Cgroups v2 support :-)


Regards,
Qian Zhang


On Sat, Jan 13, 2024 at 8:48 AM Samuel Marks  wrote:

> On latest commit 5109b9069b62510ab6d0cc0c78a9ed8327d3986a `fd -epy | wc -l`
> shows 73 files.
>
> mesos/src/python/cli/src/mesos/http.py requires a trivial change to support
> Python 2 & 3. Everything else in that dir is fine.
>
> mesos/src/python/cli_new/lib/cli/util.py requires two lines to be
> conditioned on Python 2/3 to resolve the now removed `imp` builtin module.
>
> mesos/src/python/cli/src/mesos/futures.py needs cancel_futures implemented
> or stubbed with a `NotImplementedError` thrown
>
> Then you're down to 17 files left incompatible with Python 2 & 3.
>
> mesos/support has 15 of these files; quickly reading `rg -Ftpy import`
> shows nothing interesting. Should be mostly trivial. Take care though to
> remove distutils; as that was removed in Python 3.12.
>
> mesos/src/examples/python contains the final 2 Python files. A cursory
> glance I can't see anything Python 2 & 3 incompatible.
>
> (happy to send the PR/patch or you can)
>
> Samuel Marks
> Charity  | consultancy 
> | open-source  | LinkedIn
> 
>
>
> On Fri, Jan 12, 2024 at 6:46 PM Shatil Rafiullah 
> wrote:
>
> > Do you require both Python 2 and 3 bindings to work, or can we make a
> > clean migration to 3? I ask because there are breaking changes in C/C++
> > bindings going from 2 to 3, and supporting both will require conditionals
> > rather than replacements of code blocks here and there. Dependencies may
> > also end up incompatible between the two Python versions since some
> dropped
> > Python 2.7 support a long time ago.
> >
> > On Fri, Jan 12, 2024 at 3:18 PM Samuel Marks  wrote:
> >
> >> The Python 3 upgrade shouldn't be too difficult; happy to help out. Make
> >> sure you duplicate your configuration so that CMake still works (happy
> to
> >> help there also). Just message (privately or publicly).
> >>
> >> Good to see interest in Mesos remaining,
> >>
> >> Samuel Marks
> >> Charity
> >> <
> https://urldefense.com/v3/__https://sydneyscientific.org__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSXruBk3U$
> >
> >> | consultancy
> >> <
> https://urldefense.com/v3/__https://offscale.io__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSQf69uCY$
> >
> >> | open-source
> >> <
> https://urldefense.com/v3/__https://github.com/offscale__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbSR5dWm9A$
> >
> >> | LinkedIn
> >> <
> https://urldefense.com/v3/__https://linkedin.com/in/samuelmarks__;!!PWjfaQ!uCG12YNoPBcCb2z5v__gdjEEdxzUQsTntmDTSOVDMeG_sbq2zT58dS9IisTDUqIVlh18jPbS0q7dfzk$
> >
> >>
> >>
> >> On Fri, Jan 12, 2024 at 6:01 PM Benjamin Mahler 
> >> wrote:
> >>
> >>> +user@
> >>>
> >>> On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler 
> >>> wrote:
> >>>
> >>> > As part of upgrading to CentOS 9 at X/Twitter, Shatil / Devin (cc'ed)
> >>> will
> >>> > be working on:
> >>> >
> >>> > * Upgrading to Python 3
> >>> > * Cgroups v2 support
> >>> >
> >>> > We will attempt to upstream this work for the benefit of other users.
> >>> >
> >>> > In addition, we have several long-standing internal patches that
> should
> >>> > have been upstreamed but weren't. We currently deploy from an
> internal
> >>> > 1.9.x branch with these additional patches on top of OSS 1.9.x. To
> >>> simplify
> >>> > the above work since the code changes will be substantial (especially
> >>> for
> >>> > cgroups v2), we'll try to work off master (or 1.11.x) and upstream
> our
> >>> > long-standing internal patches to minimize the delta between OSS and
> >>> our
> >>> > internal branch.
> >>> >
> >>> > Let me know if folks have any questions. IMO it would be good for
> >>> users to
> >>> > hold off on going into the attic so that we can land this work at
> >>> least.
> >>> >
> >>> > Ben
> >>> >
> >>>
> >>
>

Re: Can you help provide a future for Apache Mesos?

[Qian Zhang]

Hi Shane,

Please hold off on moving Mesos into the attic, Ben and his team members
will contribute some substantial code changes to Mesos, thanks Ben and your
team!


Regards,
Qian Zhang


On Tue, Nov 14, 2023 at 3:17 PM Charles-François Natali 
wrote:

> Still using Mesos - it's stable, boring - in a good way - and great for
> our specific use case.
>
> I'm a committer, happy to continue reviewing and merging small changes or
> address security issues.
>
> Cheers,
>
>
>
>
>
> On Mon, Nov 13, 2023, 13:34 Andreas Peters  wrote:
>
>> I'm still with Mesos and can do what I done the last years. Keep an eye
>> at issues and give support via Slack and Jira.
>>
>>
>> Am 13.11.23 um 13:51 schrieb Shane Curcuru:
>>
>> As a mature and successful project, Mesos hasn't seen much new
>> development in the past couple of years.  The question now for everyone on
>> these lists is:
>>
>> - Is Mesos still a maintained project, where even if no new features are
>> developed, there's at least a group to respond to security issues and make
>> new releases?  Or is it time to 'deprecate' Mesos, and move the project as
>> a whole to the Apache Attic? [1]
>>
>> It feels like there are still plenty of users who rely on Mesos; what we
>> need now is for enough people here to step up and volunteer to stick around
>> and be available to fix security issues in the future.
>>
>> Thanks to Qian for raising this question in March [2], where several
>> people did speak up.  I'd like to clarify what the ASF board's requirements
>> are for an 'active' Apache project.
>>
>> We don't actually need people doing active development on a project.
>> What's really needed is at least three PMC members who are monitoring the
>> project's lists and issues, and who could be available in the future *if* a
>> serious security issue or other major bug were discovered.
>>
>> So we're not looking for people with time to do active development - just
>> enough reliable volunteers who could monitor for major issues that are
>> reported, and make a new release if security fixes are needed.  Does that
>> help, and does that make sense?
>>
>> We will also be running a Roll Call of the PMC [3] now, so the board can
>> understand how many PMC members (who have access to security issue details,
>> for example) could still stick around to monitor lists.  Along with that
>> roll call, we'll also be reminding the existing PMC that they can vote in
>> any existing committers who will also step up and volunteer.
>>
>> * What can you do?
>>
>> If you are still using Mesos, have enough time to check the mailing
>> lists/issue tracker periodically for any security or giant breaking bugs
>> (i.e. not small bugs), and might be able to help someday with a fix or
>> making a new release of Mesos, then speak up now!  Be sure to say what
>> specific kinds of tasks you might be able to take on if they arise.
>>
>> Remember: we don't need active development, just some folks making sure
>> any security bugs are addressed in the future (if they come up).
>>
>>

Re: Cgroups v2 + Python 3 + Upstreaming X/Twitter Patches

[Benjamin Mahler]

+user@

On Fri, Jan 12, 2024 at 5:55 PM Benjamin Mahler  wrote:

> As part of upgrading to CentOS 9 at X/Twitter, Shatil / Devin (cc'ed) will
> be working on:
>
> * Upgrading to Python 3
> * Cgroups v2 support
>
> We will attempt to upstream this work for the benefit of other users.
>
> In addition, we have several long-standing internal patches that should
> have been upstreamed but weren't. We currently deploy from an internal
> 1.9.x branch with these additional patches on top of OSS 1.9.x. To simplify
> the above work since the code changes will be substantial (especially for
> cgroups v2), we'll try to work off master (or 1.11.x) and upstream our
> long-standing internal patches to minimize the delta between OSS and our
> internal branch.
>
> Let me know if folks have any questions. IMO it would be good for users to
> hold off on going into the attic so that we can land this work at least.
>
> Ben
>

Re: Can you help provide a future for Apache Mesos?

[Andreas Peters]

I'm still with Mesos and can do what I done the last years. Keep an eye 
at issues and give support via Slack and Jira.



Am 13.11.23 um 13:51 schrieb Shane Curcuru:
As a mature and successful project, Mesos hasn't seen much new 
development in the past couple of years.  The question now for 
everyone on these lists is:


- Is Mesos still a maintained project, where even if no new features 
are developed, there's at least a group to respond to security issues 
and make new releases?  Or is it time to 'deprecate' Mesos, and move 
the project as a whole to the Apache Attic? [1]


It feels like there are still plenty of users who rely on Mesos; what 
we need now is for enough people here to step up and volunteer to 
stick around and be available to fix security issues in the future.


Thanks to Qian for raising this question in March [2], where several 
people did speak up.  I'd like to clarify what the ASF board's 
requirements are for an 'active' Apache project.


We don't actually need people doing active development on a project. 
What's really needed is at least three PMC members who are monitoring 
the project's lists and issues, and who could be available in the 
future *if* a serious security issue or other major bug were discovered.


So we're not looking for people with time to do active development - 
just enough reliable volunteers who could monitor for major issues 
that are reported, and make a new release if security fixes are 
needed.  Does that help, and does that make sense?


We will also be running a Roll Call of the PMC [3] now, so the board 
can understand how many PMC members (who have access to security issue 
details, for example) could still stick around to monitor lists.  
Along with that roll call, we'll also be reminding the existing PMC 
that they can vote in any existing committers who will also step up 
and volunteer.


* What can you do?

If you are still using Mesos, have enough time to check the mailing 
lists/issue tracker periodically for any security or giant breaking 
bugs (i.e. not small bugs), and might be able to help someday with a 
fix or making a new release of Mesos, then speak up now!  Be sure to 
say what specific kinds of tasks you might be able to take on if they 
arise.


Remember: we don't need active development, just some folks making 
sure any security bugs are addressed in the future (if they come up).




OpenPGP_0x6A83F12541CFCCF9.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Next steps for Mesos

[Qian Zhang]

Hi Alexander,

Thanks for your mail and happy to know you are also using Mesos.

So my question is, is there an option to lift the requirement of 3 active
> contributors for the specific case of Mesos and postpone the decision
> on moving this project to the attic?


I think we may not be able to lift this requirement since it is an Apache
guideline for all its open source projects, and I agree with Andreas that
it is not possible to continue to maintain Mesos since we do not have
enough active committers/contributors.

Regards,
Qian Zhang


On Fri, Nov 10, 2023 at 8:41 PM Alexander Ushakov <
alex.ushakov.offic...@gmail.com> wrote:

> I am happy to know that clusterd exists. Some good news in this world.
> Thank you. I will not spam more here.
>
> On Fri, Nov 10, 2023, 15:33 Andreas Peters  wrote:
>
>> Hi Alexander,
>>
>> It seams not so easy (almost impossible) to maintain Mesos with a small
>> group of peoples under Apache. Thats why I decide to create a fork of Mesos
>> (https://github.com/m3scluster/clusterd). Have a look into the
>> changelog. Maybe some changes are interesting for you. You (and of course
>> every one else) are always welcome.
>>
>>
>> To m3s! As I know, there is only the K8 framework for DCOS. If M3S does
>> not match your requirements, I would be happy if you send me a EMail (or
>> ping me via Matrix or Slack) with the reasons. Feedback are always welcome.
>>
>>
>> Cheers,
>> Andreas
>>
>>
>>
>> Am 10.11.23 um 11:31 schrieb Alexander Sibiryakov:
>>
>> Hi Qian and others,
>>
>> We're also Mesos user, having 4-5 clusters of Mesos, running 1.4.1.
>> Some of them are powering our Scrapy Cloud product using 3K CPUs,
>> around 6-10K jobs executing in parallel, and several hundreds starting
>> per second.
>>
>> I think the situation with Mesos is that its purpose have changed with
>> the time. Initially it was widely adopted as containers orchestration
>> platform run a variety of applications. Currently there are mature,
>> future rich and battle-tested alternatives like Kubernetes, especially
>> the managed offers. So Mesos due its simplicity, concentrating mainly
>> on orchestration, is out of the competition in this market.
>>
>> But, there are still very little frameworks for building cloud
>> systems. As it is stated on the main page
>>
>> Apache Mesos abstracts CPU, memory, storage, and other compute resources 
>> away from machines (physical or virtual), enabling fault-tolerant and 
>> elastic distributed systems to easily be built and run effectively.
>>
>> These days Mesos is still a good solution for those who need to
>> orchestrate a specific workload at scale. Its operational model with
>> customisable schedulers receiving resource offers fits perfectly when
>> there is a queue of jobs which needs to be executed on a limited
>> amount of hardware. Kubernetes isn't really designed for that. But,
>> this is a concern of cloud builders, which is a rare occasion today.
>> Due to the complexity of the cloud systems, very few people on the
>> planet can design and build them. Meaning you should not expect the
>> same amount of active contributors as for other projects. So my
>> question is, is there an option to lift the requirement of 3 active
>> contributors for the specific case of Mesos and postpone the decision
>> on moving this project to the attic?
>>
>> A.
>>
>> On 2023/03/18 01:57:00 Qian Zhang wrote:
>>
>> Hi all,
>>
>> I'd like to restart the discussion around the future of the Mesos project.
>> As you may already be aware, the Mesos community has been inactive for the
>> last few years, there were only 3 contributors last year, that's obviously
>> not enough to keep the project moving forward. I think we need at least 3
>> active committers/PMC members and some active contributors to keep the
>> project alive, or we may have to move it to attic 
>> .
>>
>> Call for action: If you are the current committer/PMC member and still have
>> the capacity to maintain the project, or if you are willing to actively
>> contribute to the project as a contributor, please reply to this email,
>> thanks!
>>
>>
>> Regards,
>> Qian Zhang
>>
>>
>>

Re: Next steps for Mesos

[Andreas Peters]

Hi Alexander,

It seams not so easy (almost impossible) to maintain Mesos with a small 
group of peoples under Apache. Thats why I decide to create a fork of 
Mesos (https://github.com/m3scluster/clusterd). Have a look into the 
changelog. Maybe some changes are interesting for you. You (and of 
course every one else) are always welcome.



To m3s! As I know, there is only the K8 framework for DCOS. If M3S does 
not match your requirements, I would be happy if you send me a EMail (or 
ping me via Matrix or Slack) with the reasons. Feedback are always welcome.



Cheers,
Andreas



Am 10.11.23 um 11:31 schrieb Alexander Sibiryakov:

Hi Qian and others,

We're also Mesos user, having 4-5 clusters of Mesos, running 1.4.1.
Some of them are powering our Scrapy Cloud product using 3K CPUs,
around 6-10K jobs executing in parallel, and several hundreds starting
per second.

I think the situation with Mesos is that its purpose have changed with
the time. Initially it was widely adopted as containers orchestration
platform run a variety of applications. Currently there are mature,
future rich and battle-tested alternatives like Kubernetes, especially
the managed offers. So Mesos due its simplicity, concentrating mainly
on orchestration, is out of the competition in this market.

But, there are still very little frameworks for building cloud
systems. As it is stated on the main page

Apache Mesos abstracts CPU, memory, storage, and other compute resources away 
from machines (physical or virtual), enabling fault-tolerant and elastic 
distributed systems to easily be built and run effectively.

These days Mesos is still a good solution for those who need to
orchestrate a specific workload at scale. Its operational model with
customisable schedulers receiving resource offers fits perfectly when
there is a queue of jobs which needs to be executed on a limited
amount of hardware. Kubernetes isn't really designed for that. But,
this is a concern of cloud builders, which is a rare occasion today.
Due to the complexity of the cloud systems, very few people on the
planet can design and build them. Meaning you should not expect the
same amount of active contributors as for other projects. So my
question is, is there an option to lift the requirement of 3 active
contributors for the specific case of Mesos and postpone the decision
on moving this project to the attic?

A.

On 2023/03/18 01:57:00 Qian Zhang wrote:

Hi all,

I'd like to restart the discussion around the future of the Mesos project.
As you may already be aware, the Mesos community has been inactive for the
last few years, there were only 3 contributors last year, that's obviously
not enough to keep the project moving forward. I think we need at least 3
active committers/PMC members and some active contributors to keep the
project alive, or we may have to move it to attic
.

Call for action: If you are the current committer/PMC member and still have
the capacity to maintain the project, or if you are willing to actively
contribute to the project as a contributor, please reply to this email,
thanks!


Regards,
Qian Zhang



OpenPGP_0x6A83F12541CFCCF9.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Next steps for Mesos

[Alexander Ushakov]

Hello. Except M3S, do we have K8S distro as Mesos frameworks?

On Fri, Nov 10, 2023, 13:32 Alexander Sibiryakov 
wrote:

> Hi Qian and others,
>
> We're also Mesos user, having 4-5 clusters of Mesos, running 1.4.1.
> Some of them are powering our Scrapy Cloud product using 3K CPUs,
> around 6-10K jobs executing in parallel, and several hundreds starting
> per second.
>
> I think the situation with Mesos is that its purpose have changed with
> the time. Initially it was widely adopted as containers orchestration
> platform run a variety of applications. Currently there are mature,
> future rich and battle-tested alternatives like Kubernetes, especially
> the managed offers. So Mesos due its simplicity, concentrating mainly
> on orchestration, is out of the competition in this market.
>
> But, there are still very little frameworks for building cloud
> systems. As it is stated on the main page
> > Apache Mesos abstracts CPU, memory, storage, and other compute resources
> away from machines (physical or virtual), enabling fault-tolerant and
> elastic distributed systems to easily be built and run effectively.
>
> These days Mesos is still a good solution for those who need to
> orchestrate a specific workload at scale. Its operational model with
> customisable schedulers receiving resource offers fits perfectly when
> there is a queue of jobs which needs to be executed on a limited
> amount of hardware. Kubernetes isn't really designed for that. But,
> this is a concern of cloud builders, which is a rare occasion today.
> Due to the complexity of the cloud systems, very few people on the
> planet can design and build them. Meaning you should not expect the
> same amount of active contributors as for other projects. So my
> question is, is there an option to lift the requirement of 3 active
> contributors for the specific case of Mesos and postpone the decision
> on moving this project to the attic?
>
> A.
>
> On 2023/03/18 01:57:00 Qian Zhang wrote:
> > Hi all,
> >
> > I'd like to restart the discussion around the future of the Mesos
> project.
> > As you may already be aware, the Mesos community has been inactive for
> the
> > last few years, there were only 3 contributors last year, that's
> obviously
> > not enough to keep the project moving forward. I think we need at least 3
> > active committers/PMC members and some active contributors to keep the
> > project alive, or we may have to move it to attic
> > .
> >
> > Call for action: If you are the current committer/PMC member and still
> have
> > the capacity to maintain the project, or if you are willing to actively
> > contribute to the project as a contributor, please reply to this email,
> > thanks!
> >
> >
> > Regards,
> > Qian Zhang
> >
>

RE: Next steps for Mesos

[Alexander Sibiryakov]

Hi Qian and others,

We're also Mesos user, having 4-5 clusters of Mesos, running 1.4.1.
Some of them are powering our Scrapy Cloud product using 3K CPUs,
around 6-10K jobs executing in parallel, and several hundreds starting
per second.

I think the situation with Mesos is that its purpose have changed with
the time. Initially it was widely adopted as containers orchestration
platform run a variety of applications. Currently there are mature,
future rich and battle-tested alternatives like Kubernetes, especially
the managed offers. So Mesos due its simplicity, concentrating mainly
on orchestration, is out of the competition in this market.

But, there are still very little frameworks for building cloud
systems. As it is stated on the main page
> Apache Mesos abstracts CPU, memory, storage, and other compute resources away 
> from machines (physical or virtual), enabling fault-tolerant and elastic 
> distributed systems to easily be built and run effectively.

These days Mesos is still a good solution for those who need to
orchestrate a specific workload at scale. Its operational model with
customisable schedulers receiving resource offers fits perfectly when
there is a queue of jobs which needs to be executed on a limited
amount of hardware. Kubernetes isn't really designed for that. But,
this is a concern of cloud builders, which is a rare occasion today.
Due to the complexity of the cloud systems, very few people on the
planet can design and build them. Meaning you should not expect the
same amount of active contributors as for other projects. So my
question is, is there an option to lift the requirement of 3 active
contributors for the specific case of Mesos and postpone the decision
on moving this project to the attic?

A.

On 2023/03/18 01:57:00 Qian Zhang wrote:
> Hi all,
>
> I'd like to restart the discussion around the future of the Mesos project.
> As you may already be aware, the Mesos community has been inactive for the
> last few years, there were only 3 contributors last year, that's obviously
> not enough to keep the project moving forward. I think we need at least 3
> active committers/PMC members and some active contributors to keep the
> project alive, or we may have to move it to attic
> .
>
> Call for action: If you are the current committer/PMC member and still have
> the capacity to maintain the project, or if you are willing to actively
> contribute to the project as a contributor, please reply to this email,
> thanks!
>
>
> Regards,
> Qian Zhang
>

Re: Next steps for Mesos

[Qian Zhang]

>
> Qian, it might be worth having a more explicit email asking users to chime
> in as this email was tailored more for contributors.


Yes, we can have such email, but I think it does not affect whether we
should move Mesos to attic or not, since the most important factor is
whether we have enough active committers. Quoted from
https://attic.apache.org/:

When should a project move to the Attic?

Projects whose PMC are unable to muster 3 votes for a release, who have no
active committers or are unable to fulfill their reporting duties to the
board are all good candidates for the Attic.

I am happy to see there are still some companies using Mesos now, but in
this mail thread, so far there are just several contributors interested in
contributing to Mesos and only one committer Benjamin Mahler (no guaranteed
time), I think that's not enough to keep this project going, so we may have
to move Mesos to attic.


Regards,
Qian Zhang


On Tue, Mar 21, 2023 at 2:56 AM Benjamin Mahler  wrote:

> Also if you are still a user of mesos, please chime in.
> Qian, it might be worth having a more explicit email asking users to chime
> in as this email was tailored more for contributors.
>
> Twitter is still using mesos heavily, we upgraded from a branch based off
> of 1.2.x to 1.9.x in 2021, but haven't upgraded to 1.11.x yet. We do have a
> lot of patches carried on our branch that have not been upstreamed. I would
> like to upstream them to avoid relying on many custom patches and to
> get closer to HEAD, but it will take time and quite a bit of work, and it's
> not a priority at the moment.
>
> On the contribution side, at this point if I were to continue contributing,
> it would be on a volunteer basis, and I can't guarantee having enough time
> to do so.
>
> On Fri, Mar 17, 2023 at 9:57 PM Qian Zhang  wrote:
>
> > Hi all,
> >
> > I'd like to restart the discussion around the future of the Mesos
> project.
> > As you may already be aware, the Mesos community has been inactive for
> the
> > last few years, there were only 3 contributors last year, that's
> obviously
> > not enough to keep the project moving forward. I think we need at least 3
> > active committers/PMC members and some active contributors to keep the
> > project alive, or we may have to move it to attic
> > .
> >
> > Call for action: If you are the current committer/PMC member and still
> > have the capacity to maintain the project, or if you are willing to
> > actively contribute to the project as a contributor, please reply to this
> > email, thanks!
> >
> >
> > Regards,
> > Qian Zhang
> >
>

Re: Future transfer of MesosCon 2015 videos

[Vinod Kone]

Thanks Dave for driving this. 

Thanks,
Vinod

> On Mar 26, 2023, at 11:57 AM, Dave Lester  wrote:
> 
> I assume the clarification is about MesosCon 2014 videos. I believe Twitter 
> owns the copyright to the videos which were recorded without cost to the 
> event by a Twitter staff member and published to the company's "Twitter 
> University" YouTube channel. I don't believe those videos were licensed so 
> we'd need their sign-off before copying anything.
> 
> It doesn't sound like there's a concern or objection regarding the proposal 
> to migrate MesosCon 2015 videos to LF YouTube channel, but I encourage folks 
> to chime-in if they have additional questions and feedback.
> 
>> On 2023/03/26 10:21:49 Marc wrote:
>> 
>> What is the problem with just copying them?
>> 
>>> 
>>> Clarifying my earlier message: MesosCon 2015 videos will be migrated to
>>> the LF YouTube channel unless a concern is raised within 72 hours.
>>> 
>>> I believe all MesosCon 2015 videos were released under a Creative
>>> Commons Attribution license (this can be confirmed by viewing the notice
>>> beside individual videos or in their descriptions).
>>> 
>>> Unfortunately, while video from the conference's first event MesosCon
>>> 2014 was recorded
>>> (https://www.youtube.com/playlist?list=PLDVc2EaAVPg9kp8cFzjR1Yxj96I4U5EG
>>> N) I assume that Twitter owns the rights to the recordings. If someone
>>> still working at Twitter can get the OK to migrate these as well I'm
>>> happy to make the appropriate LF connections.
>>> 
>> 

RE: Future transfer of MesosCon 2015 videos

[Dave Lester]

I assume the clarification is about MesosCon 2014 videos. I believe Twitter 
owns the copyright to the videos which were recorded without cost to the event 
by a Twitter staff member and published to the company's "Twitter University" 
YouTube channel. I don't believe those videos were licensed so we'd need their 
sign-off before copying anything.

It doesn't sound like there's a concern or objection regarding the proposal to 
migrate MesosCon 2015 videos to LF YouTube channel, but I encourage folks to 
chime-in if they have additional questions and feedback.

On 2023/03/26 10:21:49 Marc wrote:
> 
> What is the problem with just copying them?
> 
> > 
> > Clarifying my earlier message: MesosCon 2015 videos will be migrated to
> > the LF YouTube channel unless a concern is raised within 72 hours.
> > 
> > I believe all MesosCon 2015 videos were released under a Creative
> > Commons Attribution license (this can be confirmed by viewing the notice
> > beside individual videos or in their descriptions).
> > 
> > Unfortunately, while video from the conference's first event MesosCon
> > 2014 was recorded
> > (https://www.youtube.com/playlist?list=PLDVc2EaAVPg9kp8cFzjR1Yxj96I4U5EG
> > N) I assume that Twitter owns the rights to the recordings. If someone
> > still working at Twitter can get the OK to migrate these as well I'm
> > happy to make the appropriate LF connections.
> > 
> 

RE: Future transfer of MesosCon 2015 videos

[Marc]

What is the problem with just copying them?

> 
> Clarifying my earlier message: MesosCon 2015 videos will be migrated to
> the LF YouTube channel unless a concern is raised within 72 hours.
> 
> I believe all MesosCon 2015 videos were released under a Creative
> Commons Attribution license (this can be confirmed by viewing the notice
> beside individual videos or in their descriptions).
> 
> Unfortunately, while video from the conference's first event MesosCon
> 2014 was recorded
> (https://www.youtube.com/playlist?list=PLDVc2EaAVPg9kp8cFzjR1Yxj96I4U5EG
> N) I assume that Twitter owns the rights to the recordings. If someone
> still working at Twitter can get the OK to migrate these as well I'm
> happy to make the appropriate LF connections.
> 

Re: Future transfer of MesosCon 2015 videos

[Dave Lester]

Clarifying my earlier message: MesosCon 2015 videos will be migrated to the
LF YouTube channel unless a concern is raised within 72 hours.

I believe all MesosCon 2015 videos were released under a Creative Commons
Attribution license (this can be confirmed by viewing the notice beside
individual videos or in their descriptions).

Unfortunately, while video from the conference's first event MesosCon 2014
was recorded (
https://www.youtube.com/playlist?list=PLDVc2EaAVPg9kp8cFzjR1Yxj96I4U5EGN) I
assume that Twitter owns the rights to the recordings. If someone still
working at Twitter can get the OK to migrate these as well I'm happy to
make the appropriate LF connections.

Best,
Dave

On Sat, Mar 25, 2023 at 5:14 PM Dave Lester  wrote:

> As an update: The Linux Foundation has offered to migrate these videos so
> that MesosCon 2015 videos are moved to the same LF YouTube channel as 2016
> and 2017.
>
> I'll give this 72 hours for folks to chime-in with any additional
> feedback. Assuming we have consensus we'll proceed with the migration.
>
> Best,
> Dave
>
> On Mon, Mar 13, 2023 at 11:19 AM Dave Lester  wrote:
>
>> I’m looking into options for moving video of MesosCon 2015 presentations
>> (the project's community conference that took place in Seattle with 700+
>> attendees) from their current stand-alone YouTube channel (
>> https://www.youtube.com/@mesoscon881) to a larger channel that’s more
>> official.
>>
>> Motivation
>> Apache Mesos became a top-level ASF project 10 years ago and I’d like
>> these presentation videos to be accessible for many more years. To ensure
>> that they aren’t lost or accidentally deleted I believe they should be
>> saved to an official channel. Migration becomes less likely and more
>> difficult with time so I’m prioritizing this now.
>>
>> Anticipated Impact
>> Minimal. In the options I’m currently exploring the links will change but
>> videos will remain discoverable via YouTube search. Previous YouTube view
>> counts will likely be lost. Once the videos are uploaded to a new channel
>> the previous MesosCon channel will be deleted.
>>
>> Paths Being Explored
>> We’ve been given the green light to use The Apache Software Foundation
>> YouTube channel and would likely post videos in a separate event playlist.
>> I also plan to contact The Linux Foundation who managed the event to see if
>> they’d prefer to host the videos themselves (the LF already hosts video
>> from MesosCon 2016 and 2017).
>>
>> Your feedback is welcome! I’ll continue to work on this in the coming
>> weeks and will report back with an updated link once the transfer is
>> complete.
>>
>> Best,
>> Dave Lester
>> Apache Mesos PMC Member and Co-chair of MesosCon 2015
>>
>

Re: Future transfer of MesosCon 2015 videos

[Dave Lester]

As an update: The Linux Foundation has offered to migrate these videos so
that MesosCon 2015 videos are moved to the same LF YouTube channel as 2016
and 2017.

I'll give this 72 hours for folks to chime-in with any additional feedback.
Assuming we have consensus we'll proceed with the migration.

Best,
Dave

On Mon, Mar 13, 2023 at 11:19 AM Dave Lester  wrote:

> I’m looking into options for moving video of MesosCon 2015 presentations
> (the project's community conference that took place in Seattle with 700+
> attendees) from their current stand-alone YouTube channel (
> https://www.youtube.com/@mesoscon881) to a larger channel that’s more
> official.
>
> Motivation
> Apache Mesos became a top-level ASF project 10 years ago and I’d like
> these presentation videos to be accessible for many more years. To ensure
> that they aren’t lost or accidentally deleted I believe they should be
> saved to an official channel. Migration becomes less likely and more
> difficult with time so I’m prioritizing this now.
>
> Anticipated Impact
> Minimal. In the options I’m currently exploring the links will change but
> videos will remain discoverable via YouTube search. Previous YouTube view
> counts will likely be lost. Once the videos are uploaded to a new channel
> the previous MesosCon channel will be deleted.
>
> Paths Being Explored
> We’ve been given the green light to use The Apache Software Foundation
> YouTube channel and would likely post videos in a separate event playlist.
> I also plan to contact The Linux Foundation who managed the event to see if
> they’d prefer to host the videos themselves (the LF already hosts video
> from MesosCon 2016 and 2017).
>
> Your feedback is welcome! I’ll continue to work on this in the coming
> weeks and will report back with an updated link once the transfer is
> complete.
>
> Best,
> Dave Lester
> Apache Mesos PMC Member and Co-chair of MesosCon 2015
>

RE: Next steps for Mesos

[Marcel Neuhausler]

Hello everyone,

At Institutional Shareholder Services we just rolled out additional Mesos 
clusters in two of our data-centers. Those are based on Mesos 1.11.0 running on 
Debian 11 (using cgroups v1).

Obviously I personally would like to see the community grow again, and also 
more than happy to contribute. Unfortunately it does seem like the 
Apache-process with all it different rules, policies, 
contributor/commiter/PMC-hierarchies and requirements does not provide enough 
flexibility needed right now to "jump-start"/resurrect the Mesos project. I 
also feel that the Mesos-brand/name itself could benefit from a refresher. Plus 
there are different ideas on how to slim-down/overhaul the source-code/project 
itself. Guess we are also considering maintaining our own branch, ideally as 
open-source.

Cheers,
--Marcel


On 2023/03/18 01:57:00 Qian Zhang wrote:
> Hi all,
> 
> I'd like to restart the discussion around the future of the Mesos project.
> As you may already be aware, the Mesos community has been inactive for the
> last few years, there were only 3 contributors last year, that's obviously
> not enough to keep the project moving forward. I think we need at least 3
> active committers/PMC members and some active contributors to keep the
> project alive, or we may have to move it to attic
> .
> 
> Call for action: If you are the current committer/PMC member and still have
> the capacity to maintain the project, or if you are willing to actively
> contribute to the project as a contributor, please reply to this email,
> thanks!
> 
> 
> Regards,
> Qian Zhang
>

Re: Next steps for Mesos

[Dan Leary]

We're using mesos 1.11 straight out of the box on ubuntu 18.04 at touchplan.io 
running our own bespoke framework.  Would like to get it to ubuntu 22.04.  We 
have limited resources to commit to mesos development, but it's not totally out 
of the question.

-Dan


From: Benjamin Mahler 
Sent: Monday, March 20, 2023 2:55 PM
To: user@mesos.apache.org 
Cc: mesos ; priv...@mesos.apache.org 

Subject: Re: Next steps for Mesos

Also if you are still a user of mesos, please chime in.
Qian, it might be worth having a more explicit email asking users to chime in 
as this email was tailored more for contributors.

Twitter is still using mesos heavily, we upgraded from a branch based off of 
1.2.x to 1.9.x in 2021, but haven't upgraded to 1.11.x yet. We do have a lot of 
patches carried on our branch that have not been upstreamed. I would like to 
upstream them to avoid relying on many custom patches and to get closer to 
HEAD, but it will take time and quite a bit of work, and it's not a priority at 
the moment.

On the contribution side, at this point if I were to continue contributing, it 
would be on a volunteer basis, and I can't guarantee having enough time to do 
so.

On Fri, Mar 17, 2023 at 9:57 PM Qian Zhang 
mailto:zhq527...@gmail.com>> wrote:
Hi all,

I'd like to restart the discussion around the future of the Mesos project. As 
you may already be aware, the Mesos community has been inactive for the last 
few years, there were only 3 contributors last year, that's obviously not 
enough to keep the project moving forward. I think we need at least 3 active 
committers/PMC members and some active contributors to keep the project alive, 
or we may have to move it to attic<https://attic.apache.org/>.

Call for action: If you are the current committer/PMC member and still have the 
capacity to maintain the project, or if you are willing to actively contribute 
to the project as a contributor, please reply to this email, thanks!


Regards,
Qian Zhang

Re: Next steps for Mesos

[Andreas Peters]

Hi,

as you know Qian, I'm still on board. 

Andreas


On 18.03.23 02:57, Qian Zhang wrote:

Hi all,

I'd like to restart the discussion around the future of the Mesos project.
As you may already be aware, the Mesos community has been inactive for the
last few years, there were only 3 contributors last year, that's obviously
not enough to keep the project moving forward. I think we need at least 3
active committers/PMC members and some active contributors to keep the
project alive, or we may have to move it to attic
.

Call for action: If you are the current committer/PMC member and still have
the capacity to maintain the project, or if you are willing to actively
contribute to the project as a contributor, please reply to this email,
thanks!


Regards,
Qian Zhang



--
AVENTER UG (haftungsbeschraenkt)
Köllner Chaussee 144
25337 Kölln-Reisiek

Phone: (+49)4121 - 235582 0
E-Mail: a...@aventer.biz
Internet: https://www.aventer.biz
Git: https://www.github.com/AVENTER-UG

Geschäftsführer/CEO: Andreas Peters
Unternehmenssitz/City: Kölln-Reisiek
Handelsregister beim Amtsgericht/Legal Court: Itzehoe
Handelsregister-Nummer/Company Registration Number: HRB 9995 PI


OpenPGP_0x6A83F12541CFCCF9.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Re: Next steps for Mesos

[Thomas Langé via user]

Hello,

Criteo is still an active user of Mesos, running it worldwide for most of its 
production workloads.

We currently run a fork of Mesos 1.9.x (with some patches that were not 
upstreamed but not that much), and we don't plan to upgrade to the latest 
version for now.

We will continue to propose patches regularly upstream when possible, but can't 
really commit on actively contributing on particular needs in Mesos ecosystem.

Regards,

Thomas Langé

From: Benjamin Mahler 
Sent: Monday, 20 March 2023 19:55
To: user@mesos.apache.org 
Cc: mesos ; priv...@mesos.apache.org 

Subject: [BULK]Re: Next steps for Mesos

Also if you are still a user of mesos, please chime in.
Qian, it might be worth having a more explicit email asking users to chime in 
as this email was tailored more for contributors.

Twitter is still using mesos heavily, we upgraded from a branch based off of 
1.2.x to 1.9.x in 2021, but haven't upgraded to 1.11.x yet. We do have a lot of 
patches carried on our branch that have not been upstreamed. I would like to 
upstream them to avoid relying on many custom patches and to get closer to 
HEAD, but it will take time and quite a bit of work, and it's not a priority at 
the moment.

On the contribution side, at this point if I were to continue contributing, it 
would be on a volunteer basis, and I can't guarantee having enough time to do 
so.

On Fri, Mar 17, 2023 at 9:57 PM Qian Zhang 
mailto:zhq527...@gmail.com>> wrote:
Hi all,

I'd like to restart the discussion around the future of the Mesos project. As 
you may already be aware, the Mesos community has been inactive for the last 
few years, there were only 3 contributors last year, that's obviously not 
enough to keep the project moving forward. I think we need at least 3 active 
committers/PMC members and some active contributors to keep the project alive, 
or we may have to move it to 
attic<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fattic.apache.org%2F=05%7C01%7Ct.lange%40criteo.com%7C6e782bd9b402421896d608db2974e0de%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C0%7C638149354183246959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=2QLjvfO3KRuvcwcZCEnFFwWGLaBz%2BIY7Yi2K%2Bw1Lm5A%3D=0>.

Call for action: If you are the current committer/PMC member and still have the 
capacity to maintain the project, or if you are willing to actively contribute 
to the project as a contributor, please reply to this email, thanks!


Regards,
Qian Zhang

RE: Next steps for Mesos

[GATOUILLAT Pierre Damien (PRESTA EXT)]

Hi,

We are using mesos/marathon here, version 1.9.x under RHEL7. Migrating to 
1.11.x as we migrate to RHEL8.  I wonder if it is safe to compile the actual 
master branch to use in production. (1.12 version)

Regards,
Pierre

De : Benjamin Mahler 
Envoyé : lundi 20 mars 2023 19:56
À : user@mesos.apache.org
Cc : mesos ; priv...@mesos.apache.org
Objet : Re: Next steps for Mesos

Also if you are still a user of mesos, please chime in.
Qian, it might be worth having a more explicit email asking users to chime in 
as this email was tailored more for contributors.

Twitter is still using mesos heavily, we upgraded from a branch based off of 
1.2.x to 1.9.x in 2021, but haven't upgraded to 1.11.x yet. We do have a lot of 
patches carried on our branch that have not been upstreamed. I would like to 
upstream them to avoid relying on many custom patches and to get closer to 
HEAD, but it will take time and quite a bit of work, and it's not a priority at 
the moment.

On the contribution side, at this point if I were to continue contributing, it 
would be on a volunteer basis, and I can't guarantee having enough time to do 
so.

On Fri, Mar 17, 2023 at 9:57 PM Qian Zhang 
mailto:zhq527...@gmail.com>> wrote:
Hi all,

I'd like to restart the discussion around the future of the Mesos project. As 
you may already be aware, the Mesos community has been inactive for the last 
few years, there were only 3 contributors last year, that's obviously not 
enough to keep the project moving forward. I think we need at least 3 active 
committers/PMC members and some active contributors to keep the project alive, 
or we may have to move it to attic<https://attic.apache.org/>.

Call for action: If you are the current committer/PMC member and still have the 
capacity to maintain the project, or if you are willing to actively contribute 
to the project as a contributor, please reply to this email, thanks!


Regards,
Qian Zhang
***
Ce message et toutes les pièces jointes sont confidentiels et établis à 
l'intention exclusive
de son ou ses destinataires. Si vous avez reçu ce message par erreur, merci 
d'en avertir
immédiatement l'émetteur et de détruire le message. Toute modification, 
édition, utilisation ou
diffusion non autorisée est interdite. L'émetteur décline toute responsabilité 
au titre de ce
message s'il a été modifié, déformé, falsifié, infecté par un virus ou encore 
édité ou diffusé sans autorisation.
***
***
This message and any attachments are confidential and intended for the named 
addressee(s) only.
If you have received this message in error, please notify immediately the 
sender, then delete
the message. Any unauthorized modification, edition, use or dissemination is 
prohibited.
The sender shall not be liable for this message if it has been modified, 
altered, falsified, infected
by a virus or even edited or disseminated without authorization.
***

Re: Next steps for Mesos

[Benjamin Mahler]

Also if you are still a user of mesos, please chime in.
Qian, it might be worth having a more explicit email asking users to chime
in as this email was tailored more for contributors.

Twitter is still using mesos heavily, we upgraded from a branch based off
of 1.2.x to 1.9.x in 2021, but haven't upgraded to 1.11.x yet. We do have a
lot of patches carried on our branch that have not been upstreamed. I would
like to upstream them to avoid relying on many custom patches and to
get closer to HEAD, but it will take time and quite a bit of work, and it's
not a priority at the moment.

On the contribution side, at this point if I were to continue contributing,
it would be on a volunteer basis, and I can't guarantee having enough time
to do so.

On Fri, Mar 17, 2023 at 9:57 PM Qian Zhang  wrote:

> Hi all,
>
> I'd like to restart the discussion around the future of the Mesos project.
> As you may already be aware, the Mesos community has been inactive for the
> last few years, there were only 3 contributors last year, that's obviously
> not enough to keep the project moving forward. I think we need at least 3
> active committers/PMC members and some active contributors to keep the
> project alive, or we may have to move it to attic
> .
>
> Call for action: If you are the current committer/PMC member and still
> have the capacity to maintain the project, or if you are willing to
> actively contribute to the project as a contributor, please reply to this
> email, thanks!
>
>
> Regards,
> Qian Zhang
>

Re: Future transfer of MesosCon 2015 videos

[Qian Zhang]

Thanks Dave for taking care of this!

I'd prefer to host the MesosCon 2015 videos together with the videos of
other MesosCons so we will have a single place for all videos.


Regards,
Qian Zhang


On Tue, Mar 14, 2023 at 2:20 AM Dave Lester  wrote:

> I’m looking into options for moving video of MesosCon 2015 presentations
> (the project's community conference that took place in Seattle with 700+
> attendees) from their current stand-alone YouTube channel (
> https://www.youtube.com/@mesoscon881) to a larger channel that’s more
> official.
>
> Motivation
> Apache Mesos became a top-level ASF project 10 years ago and I’d like these
> presentation videos to be accessible for many more years. To ensure that
> they aren’t lost or accidentally deleted I believe they should be saved to
> an official channel. Migration becomes less likely and more difficult with
> time so I’m prioritizing this now.
>
> Anticipated Impact
> Minimal. In the options I’m currently exploring the links will change but
> videos will remain discoverable via YouTube search. Previous YouTube view
> counts will likely be lost. Once the videos are uploaded to a new channel
> the previous MesosCon channel will be deleted.
>
> Paths Being Explored
> We’ve been given the green light to use The Apache Software Foundation
> YouTube channel and would likely post videos in a separate event playlist.
> I also plan to contact The Linux Foundation who managed the event to see if
> they’d prefer to host the videos themselves (the LF already hosts video
> from MesosCon 2016 and 2017).
>
> Your feedback is welcome! I’ll continue to work on this in the coming weeks
> and will report back with an updated link once the transfer is complete.
>
> Best,
> Dave Lester
> Apache Mesos PMC Member and Co-chair of MesosCon 2015
>

Re: [BULK]Re: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

[Dan Leary]

Thanks, I'll give that a try.
Perhaps I'll file a feature request to auto-update the zk endpoints on a
reconfig event so the mesos masters don't have to be restarted.


On Thu, Mar 10, 2022 at 12:49 PM Thomas Langé  wrote:

> Hi,
>
> You answer is in your last message:
> >Perhaps a mesos-master needs to be terminated and then restarted with an
> updated zk:// list as
> > each zk participant gets reconfig'ed?
>
> From what I understand, when your issue happens, your ZK cluster is
> healthy but Mesos masters fails to connect.
> It seems to be because Mesos masters are still configured to contact the 3
> "legacy nodes". As long as they are in the ZK cluster, they will forward
> your request to ZK leader, so the whole setup works. When you remove them,
> mesos-master cannot know how to reach a valid ZK member to access the
> cluster.
> So, you need to update the --zk parameter to always contain members of the
> cluster (Mesos won't read ZK configuration to fetch new members and
> auto-update its "--zk endpoints").
>
> To summarize, dynamic reconfiguration is a purely ZK feature and Mesos is
> not aware of those changes.
>
> Bw,
>
> Thomas
> --
> *From:* Dan Leary 
> *Sent:* Thursday, 10 March 2022 16:16
> *To:* user@mesos.apache.org 
> *Subject:* [BULK]Re: [BULK]Re: Mesos and Zookeeper Dynamic
> Reconfiguration?
>
> Thomas-
>
> Encouraging news.  Appreciate the response.
>
> I've tried both non-incremental and incremental reconfigs with the same
> result.
> With 3 zk participants (quorum 2) we first add 3 observers.
> Non-incrementally we then remove a participant then add an observer as
> participant.
> Repeat twice, last time the current leading participant is the one removed.
> At this point the 3 mesos-masters all seem fine.
> My bespoke framework is fine too, it sees CONNECT, RECONNECT, and RECONFIG
> events and gets the updated list of zk participants just fine.
> But when we terminate the original zk servers that are now running as
> non-voting followers, the mesos-masters all seem to keep trying to
> reconnect to the now-dead former zk participants.
> Eventually heartbeats fail and the whole cluster shuts down.
> The masters log messages like:
>
> 2022-03-08 13:26:45,964:30032(0x7f25a3048700):ZOO_INFO@zookeeper_init@827:
> Initiating client connection,
> host=localhost:2181,localhost:2182,localhost:2183 sessionTimeout=1
> watcher=0x7f25ba3af67e sessionId=0 sessionPasswd=
> context=0x7f255c000bf8 flags=0
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2183] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2182
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2182%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=qXPSmRhHYp42VVlQWw3sMku%2Bs%2F6X95791AigZoctI2k%3D=0>]
> zk retcode=-4, errno=111(Connection refused): server refused to accept the
> client
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2181] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2181
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2181%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=rgCQjUjTKN%2BW8mw3iAN4TP3iUBJ2DaumoGC0OT0t0FY%3D=0>]
> zk retcode=-4, errno=111(Connection refused): server refused to accept the
> client
> 2022-03-08
> 13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2183
> <https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2183%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=XskL4ZT00cdVBYN7Md5cnbPD%2Fdfks%2FVv%2Bbq4PJIEHt8%3D=0>]
> zk retcode=-4, errno=111(Connection refused): server refused to accept the
> client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700)

Re: [BULK]Re: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

[Thomas Langé]

Hi,

You answer is in your last message:
>Perhaps a mesos-master needs to be terminated and then restarted with an 
>updated zk:// list as
> each zk participant gets reconfig'ed?

>From what I understand, when your issue happens, your ZK cluster is healthy 
>but Mesos masters fails to connect.
It seems to be because Mesos masters are still configured to contact the 3 
"legacy nodes". As long as they are in the ZK cluster, they will forward your 
request to ZK leader, so the whole setup works. When you remove them, 
mesos-master cannot know how to reach a valid ZK member to access the cluster.
So, you need to update the --zk parameter to always contain members of the 
cluster (Mesos won't read ZK configuration to fetch new members and auto-update 
its "--zk endpoints").

To summarize, dynamic reconfiguration is a purely ZK feature and Mesos is not 
aware of those changes.

Bw,

Thomas

From: Dan Leary 
Sent: Thursday, 10 March 2022 16:16
To: user@mesos.apache.org 
Subject: [BULK]Re: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

Thomas-

Encouraging news.  Appreciate the response.

I've tried both non-incremental and incremental reconfigs with the same result.
With 3 zk participants (quorum 2) we first add 3 observers.
Non-incrementally we then remove a participant then add an observer as 
participant.
Repeat twice, last time the current leading participant is the one removed.
At this point the 3 mesos-masters all seem fine.
My bespoke framework is fine too, it sees CONNECT, RECONNECT, and RECONFIG 
events and gets the updated list of zk participants just fine.
But when we terminate the original zk servers that are now running as 
non-voting followers, the mesos-masters all seem to keep trying to reconnect to 
the now-dead former zk participants.
Eventually heartbeats fail and the whole cluster shuts down.
The masters log messages like:

2022-03-08 13:26:45,964:30032(0x7f25a3048700):ZOO_INFO@zookeeper_init@827: 
Initiating client connection, host=localhost:2181,localhost:2182,localhost:2183 
sessionTimeout=1 watcher=0x7f25ba3af67e sessionId=0 sessionPasswd= 
context=0x7f255c000bf8 flags=0
2022-03-08 
13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket [::1:2183] zk retcode=-4, errno=111(Connection refused): server refused 
to accept the client
2022-03-08 
13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket 
[127.0.0.1:2182<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2182%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=qXPSmRhHYp42VVlQWw3sMku%2Bs%2F6X95791AigZoctI2k%3D=0>]
 zk retcode=-4, errno=111(Connection refused): server refused to accept the 
client
2022-03-08 
13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket [::1:2181] zk retcode=-4, errno=111(Connection refused): server refused 
to accept the client
2022-03-08 
13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket 
[127.0.0.1:2181<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2181%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=rgCQjUjTKN%2BW8mw3iAN4TP3iUBJ2DaumoGC0OT0t0FY%3D=0>]
 zk retcode=-4, errno=111(Connection refused): server refused to accept the 
client
2022-03-08 
13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket 
[127.0.0.1:2183<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2183%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=XskL4ZT00cdVBYN7Md5cnbPD%2Fdfks%2FVv%2Bbq4PJIEHt8%3D=0>]
 zk retcode=-4, errno=111(Connection refused): server refused to accept the 
client
2022-03-08 
13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket 
[127.0.0.1:2182<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2F127.0.0.1%3A2182%2F=04%7C01%7Ct.lange%40criteo.com%7Ce4d5ad56e22d4724dedc08da02a8f292%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C1%7C637825221883469947%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=qXPSmRhHYp42VVlQWw3sMku%2Bs%2F6X95791AigZoctI2k%3D=0>]
 zk retcode=-4, errno=111(Connection refused): server refused to accept the 
client
2022-03-08 
13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758: 
Socket [::1:2182] zk retcode=-4, errno=111(Con

Re: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

[Dan Leary]

Thomas-

Encouraging news.  Appreciate the response.

I've tried both non-incremental and incremental reconfigs with the same
result.
With 3 zk participants (quorum 2) we first add 3 observers.
Non-incrementally we then remove a participant then add an observer as
participant.
Repeat twice, last time the current leading participant is the one removed.
At this point the 3 mesos-masters all seem fine.
My bespoke framework is fine too, it sees CONNECT, RECONNECT, and RECONFIG
events and gets the updated list of zk participants just fine.
But when we terminate the original zk servers that are now running as
non-voting followers, the mesos-masters all seem to keep trying to
reconnect to the now-dead former zk participants.
Eventually heartbeats fail and the whole cluster shuts down.
The masters log messages like:

2022-03-08 13:26:45,964:30032(0x7f25a3048700):ZOO_INFO@zookeeper_init@827:
> Initiating client connection,
> host=localhost:2181,localhost:2182,localhost:2183 sessionTimeout=1
> watcher=0x7f25ba3af67e sessionId=0 sessionPasswd=
> context=0x7f255c000bf8 flags=0
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2183] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2182] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
> 2022-03-08
> 13:26:45,964:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2181] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2181] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f25565ea700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2183] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2182] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2182] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2181] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2181] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [::1:2183] zk retcode=-4, errno=111(Connection refused): server
> refused to accept the client
> 2022-03-08
> 13:26:45,965:30032(0x7f2557ded700):ZOO_ERROR@handle_socket_error_msg@1758:
> Socket [127.0.0.1:2183] zk retcode=-4, errno=111(Connection refused):
> server refused to accept the client
>

Where ports 2181, 2182, 2183 are the old participants, the new participants
are on ports 2184, 2185, 2186  (single host test environment).
Perhaps a mesos-master needs to be terminated and then restarted with an
updated zk:// list as each zk participant gets reconfig'ed?

-Dan


On Thu, Mar 10, 2022 at 5:15 AM Thomas Langé  wrote:

> Hi,
>
> We don't run mesos 1.11 but we use Zookeeper with dynamic reconfiguration
> capability without any issue for Mesos 1.9. The only thing that should be
> handled carefully is the addition/removal of Zookeeper members when using
> dynamic reconf feature.
>
> What do you mean by "mesos-master can handle a dynamic reconfiguration of
> the zk ensemble" ? To my understanding, Mesos will only connect to ZK to
> elect a leader through ZK primitives; I don't think there is a correlation
> with how ZK members are set in the cluster.
>
> How do you remove/add members to the ZK member list? The issue you
> encounter might come from inconsistencies in ZK cluster.
>
> Regards,
>
> Thomas
> --
> *From:* Charles-François Natali 
> *Sent:* Wednesday, 9 March 2022 23:44
> *To:* user 
> *Subject:* [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?
>
> Hi Dan,
>
> I don't think anyone has been looking at this, and i doubt we will, since
> we are quite low on resources.
>
>
> Cheers,
>
>
>
>
> On Tue, Mar 8, 2022, 19:01 Dan Leary  wrote:
>
> Been doing some testing with mesos 1.11.0 and zookee

Re: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

[Thomas Langé]

Hi,

We don't run mesos 1.11 but we use Zookeeper with dynamic reconfiguration 
capability without any issue for Mesos 1.9. The only thing that should be 
handled carefully is the addition/removal of Zookeeper members when using 
dynamic reconf feature.

What do you mean by "mesos-master can handle a dynamic reconfiguration of the 
zk ensemble" ? To my understanding, Mesos will only connect to ZK to elect a 
leader through ZK primitives; I don't think there is a correlation with how ZK 
members are set in the cluster.

How do you remove/add members to the ZK member list? The issue you encounter 
might come from inconsistencies in ZK cluster.

Regards,

Thomas

From: Charles-François Natali 
Sent: Wednesday, 9 March 2022 23:44
To: user 
Subject: [BULK]Re: Mesos and Zookeeper Dynamic Reconfiguration?

Hi Dan,

I don't think anyone has been looking at this, and i doubt we will, since we 
are quite low on resources.


Cheers,




On Tue, Mar 8, 2022, 19:01 Dan Leary 
mailto:d...@touchplan.io>> wrote:
Been doing some testing with mesos 1.11.0 and zookeeper's "dynamic 
reconfiguration" capability.
https://zookeeper.apache.org/doc/r3.6.3/zookeeperReconfig.html<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzookeeper.apache.org%2Fdoc%2Fr3.6.3%2FzookeeperReconfig.html=04%7C01%7Ct.lange%40criteo.com%7C070fc8a5cd6341e9a91008da021e7876%7C2a35d8fd574d48e3927c8c398e225a01%7C1%7C0%7C637824627127329223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=AjPUBCzFNsu0twnGptmACWDH8%2FTUktvVYKarGBRtGJI%3D=0>

Seems prima facie like mesos-master can handle a dynamic reconfig of the zk 
ensemble up to the point
where a new set of participants has been added to the ensemble and the old 
participants
have been demoted to non-voting followers.  But when the non-voting follower 
processes are
terminated the master logs seem to indicate that the masters keep trying and 
failing to reconnect
to the old zk leader, even though they've apparently received updates with the 
new ensemble participants.

Anybody have any insight into this?
Any plans to support zk dynamic reconfiguration in the future?
Seems like it could make for easier O/S maintenance of one's master/zk cluster 
hosts.

-Dan

Re: Mesos and Zookeeper Dynamic Reconfiguration?

[Charles-François Natali]

Hi Dan,

I don't think anyone has been looking at this, and i doubt we will, since
we are quite low on resources.


Cheers,




On Tue, Mar 8, 2022, 19:01 Dan Leary  wrote:

> Been doing some testing with mesos 1.11.0 and zookeeper's "dynamic
> reconfiguration" capability.
> https://zookeeper.apache.org/doc/r3.6.3/zookeeperReconfig.html
>
> Seems prima facie like mesos-master can handle a dynamic reconfig of the
> zk ensemble up to the point
> where a new set of participants has been added to the ensemble and the old
> participants
> have been demoted to non-voting followers.  But when the non-voting
> follower processes are
> terminated the master logs seem to indicate that the masters keep trying
> and failing to reconnect
> to the old zk leader, even though they've apparently received updates with
> the new ensemble participants.
>
> Anybody have any insight into this?
> Any plans to support zk dynamic reconfiguration in the future?
> Seems like it could make for easier O/S maintenance of one's master/zk
> cluster hosts.
>
> -Dan
>
>

Re: Using TLS in Mesos 1.9

[Ajay V]

Thank you for the response Charles. Password protected key files are
supported. When running the startup scripts, the stdin prompts for the key
password. This, is however not very friendly.
I was wondering if there was an option to supply it from a file or some
other nicer alternatives.

Worst case, I plan to use the decrypted method you pointed out.

Regards,
Ajay

On Fri, Dec 3, 2021 at 12:51 AM Charles-François Natali 
wrote:

> Hi Ajay,
>
> I haven't used TLS much with Mesos but I don't think password
> protected key files are supported - I'm not sure how useful that would
> be in practice anyway.
> I think your best bet is to decrypt it using e.g. openssl and provide
> that decrypted key file instead.
>
> Cheers,
>
> Charles
>
>
>
>
> Le mer. 1 déc. 2021 à 04:51, Ajay V  a écrit :
> >
> > Hi Mesos user group,
> >
> > I was experimenting with TLS in mesos and was wondering what is the best
> way the key password is supplied when starting master and agents. I see
> there are environment variables to supply the key file
> (LIBPROCESS_SSL_KEY_FILE) but could not find a variable to supply the
> password.
> >
> > When scripting the start scripts, is there a way to provide this
> password from a file or are there other options?
> >
> > Regards,
> > Ajay
>
-- 
Regards,
Ajay

Re: Using TLS in Mesos 1.9

[Charles-François Natali]

Hi Ajay,

I haven't used TLS much with Mesos but I don't think password
protected key files are supported - I'm not sure how useful that would
be in practice anyway.
I think your best bet is to decrypt it using e.g. openssl and provide
that decrypted key file instead.

Cheers,

Charles




Le mer. 1 déc. 2021 à 04:51, Ajay V  a écrit :
>
> Hi Mesos user group,
>
> I was experimenting with TLS in mesos and was wondering what is the best way 
> the key password is supplied when starting master and agents. I see there are 
> environment variables to supply the key file (LIBPROCESS_SSL_KEY_FILE) but 
> could not find a variable to supply the password.
>
> When scripting the start scripts, is there a way to provide this password 
> from a file or are there other options?
>
> Regards,
> Ajay

Re: Welcome Charles-François Natali as Mesos Committer and PMC Member!

[Renán Del Valle]

This is great news.

Congratulations to Charles-François and thank you very much for your 
contributions to Mesos!


- Renán

On 8/15/21 12:32 PM, Andrei Sekretenko wrote:

Hi all,
Please welcome Charles-François as a committer and PMC member of the
Apache Mesos project!

Charles started contributing to Mesos a bit more than a year ago.
During this time, he has discovered and fixed a significant number of
issues in all corners of Mesos, from libprocess and the build system
to the cgroups isolator, thus becoming the most active contributor
since November 2020.

Also, Charles has been helping a lot with JIRA triage, mentoring other
contributors and moving forward a number of technical discussions.

Charles, thanks for all your contributions so far and looking forward to
continuing to work with you on the project!

- Andrei

Re: marathon bug(?)

[Charles-François Natali]

On Mon, 28 Jun 2021, 20:41 Marc,  wrote

> > I think it's too late for that, your best bet is probably to pick a fork
> > which is still maintained.
>
> Why late? Login accounts do not die not?  Is not the right thing that
> Qian Zhang gets control of accounts like https://github.com/apache/mesos,
> https://github.com/mesosphere/marathon and
> https://github.com/mesosphere/mesos-dns?
>


Accounts don't die but communities do - giving anyone control of accounts
won't magically revive them.

Also, from a diversification point of view having a single person in charge
of all these is probably a bad idea - lack of diversification of probably
one of the factors behind Mesos failure.

Really, you'd be better off moving on :).

RE: marathon bug(?)

[Marc]

>   There are now forks being created of mesos-dns and marathon to
> update code. Maybe it is better to have these changes done on the
> original repositories for now.
>   With whom can we discuss this to make this happen?
> 
> 
> 
> I think it's too late for that, your best bet is probably to pick a fork
> which is still maintained.

Why late? Login accounts do not die not?  Is not the right thing that Qian 
Zhang gets control of accounts like https://github.com/apache/mesos, 
https://github.com/mesosphere/marathon and 
https://github.com/mesosphere/mesos-dns?

Re: marathon bug(?)

[Qian Zhang]

Hi Marc,

Here are the issue tracker and support info of Marathon:
https://github.com/mesosphere/marathon/issues
https://mesosphere.github.io/marathon/support.html

You may want to report issues there, but I am not sure if D2IQ folks still
maintains Marathon.


Regards,
Qian Zhang


On Tue, Jun 22, 2021 at 3:50 PM Marc  wrote:

>
> Where should marathon bugs be reported?
>
> I have switched from marathon 1.9 to 1.11.24
>
> I have a task with dedicated ip address and I used to restart a such a
> task via the gui by 'changing' the config and click something like 'change
> and deploy'.
> This 'change and deploy' is not working any more, it does nothing.
>
> PS. Choosing the restart does not work because the restart first creates a
> new task and then kills the old, which of course never works with a
> dedicated ip. (I reported this before)
>
>
>

Re: *****SPAM***** Re: State of the Project

[Charles-François Natali]

Hey,

Could we please try to stay on topic?


Thanks,



On Mon, 31 May 2021, 20:55 Zahoor,  wrote:

> hmmm... Ethereum has a popular client in golang and attracts many rookie
> developers every day.
> But still one of the most complex and nicely maintained software on Earth.
>
> On Mon, May 31, 2021 at 7:08 PM Marc  wrote:
>
>> >
>> > Better to rewrite/redesign Mesos with a more popular language (like
>> > golang) to attract more developers.
>> > Just a mind voice.
>> >
>> > ../Zahoor
>>
>> H, I would argue exactly the opposite.
>> Going to these easier entry level languages attracts rookies coders and
>> rookie thinking. I have seen some really weird design and errors in
>> csi-ceph and influx.
>>
>
>
> --
> ./zahoor
>
> Web: http://zahoor.in
> Twit: @jmohamedzahoor
>

Re: *****SPAM***** Re: State of the Project

[Zahoor]

hmmm... Ethereum has a popular client in golang and attracts many rookie
developers every day.
But still one of the most complex and nicely maintained software on Earth.

On Mon, May 31, 2021 at 7:08 PM Marc  wrote:

> >
> > Better to rewrite/redesign Mesos with a more popular language (like
> > golang) to attract more developers.
> > Just a mind voice.
> >
> > ../Zahoor
>
> H, I would argue exactly the opposite.
> Going to these easier entry level languages attracts rookies coders and
> rookie thinking. I have seen some really weird design and errors in
> csi-ceph and influx.
>


-- 
./zahoor

Web: http://zahoor.in
Twit: @jmohamedzahoor

RE: *****SPAM***** Re: State of the Project

[Marc]

> 
> Better to rewrite/redesign Mesos with a more popular language (like
> golang) to attract more developers.
> Just a mind voice.
> 
> ../Zahoor

H, I would argue exactly the opposite. 
Going to these easier entry level languages attracts rookies coders and rookie 
thinking. I have seen some really weird design and errors in csi-ceph and 
influx. 

Re: State of the Project

[Qian Zhang]

>
> Yes I think it's important to mention, in response to Javi's point,
> that one doesn't need to be an hard-core C++ dev to contribute.


Exactly! To be honest I did not have much C++ programming experience when I
started to contribute to Mesos. But when I read Mesos code, I felt it's
easy to understand and has very good design. Although Mesos is running in
multi-thread mode, you actually do not need to take care of the
locking/race condition in most cases (thanks to the actor mode with
libprocess). So I'd encourage everyone to read Mesos code and let us know
which area you'd like to contribute to :)


Regards,
Qian Zhang


On Mon, May 31, 2021 at 3:08 AM Charles-François Natali 
wrote:

> Le dim. 30 mai 2021 à 16:09, Qian Zhang  a écrit :
> > [...] So given the
> > active committers and contributors that we have in the community, I do
> not
> > think we can do anything big in the short term, instead we should do
> small
> > things to gradually activate the community. Here are what in my mind:
> > 1. Review and merge the outstanding PRs.
> > 2. Review the tickets in JIRA and select some high priority ones to work
> on.
> > 3. Add at least one new committer.
>
> Yes I think it's important to mention, in response to Javi's point,
> that one doesn't need to be an hard-core C++ dev to contribute.
> The code base is actually very clean and easy to read, the main
> problem is the use of libprocess/actor model which takes some getting
> used to, especially for people who're more used to a reactor, green
> thread, etc models. The libprocess doc [1] gives a good overview. The
> stout doc [2] is also worth a read although nothing surprising about
> its design.
>
> But in any case I think there's a lot of valuable work which doesn't
> require any C++, for example as Qian mentions going through the huge
> backlog of JIRA issues.
> I know it doesn't sound like the most exciting thing but it would
> actually help a lot to do some triage, try to reproduce bugs, close
> stale tickets, respond to user questions etc.
>
> I remember seeing a few other people answering Qian's call for
> contributors a couple months ago [3], it'd be great if they could
> reach out if they're still interested - if not it's fine, I know we're
> all busy with our lives :).
>
> Cheers,
>
> Charles
>
>
> [1] https://github.com/apache/mesos/tree/master/3rdparty/libprocess
> [2] https://github.com/apache/mesos/tree/master/3rdparty/stout
> [3]
> https://mail-archives.apache.org/mod_mbox/mesos-dev/202103.mbox/%3CCABY6VOb%3DT8VxehVaS1YBrC5_odEwKhZzj3R4o3b-ykCytDw3JA%40mail.gmail.com%3E
>
>
> >
> > Please let me know for any comments / suggestions, thanks!
> >
> >
> > Regards,
> > Qian Zhang
> >
> >
> > On Sun, May 30, 2021 at 7:59 PM Zahoor  wrote:
> >
> > > Hi
> > >
> > > Better to rewrite/redesign Mesos with a more popular language (like
> > > golang) to attract more developers.
> > > Just a mind voice.
> > >
> > > ../Zahoor
> > >
> > >
> > > On Sun, May 30, 2021 at 4:08 PM Javi Roman 
> > > wrote:
> > >
> > >> Totally agree that the main problem with this project is trying to
> > >> increase the developer community.
> > >>
> > >> From my point of view, attracting new developers to a project of this
> > >> complexity is difficult (C++ low level developers, creating Java and
> Python
> > >> bindings is not easy). However, if we try to broaden the objectives
> of the
> > >> project we may be able to attract other developers (not only C++
> > >> developers) who can help.
> > >>
> > >> One idea I have always had is to incorporate the concept and
> technology
> > >> of D2IQ DC/OS [1], in this way we would continue the abandoned work
> of D2IQ
> > >> by extending Apache Mesos to a more user-friendly technology and
> broaden
> > >> the base of developers with interest in (ReactJS, Go, Scala,
> databases).
> > >>
> > >> I would be interested in contributing in this line, being able to
> apply
> > >> my knowledge in other areas, beyond C++ (which unfortunately I am not
> > >> proficient in).
> > >>
> > >> [1] https://github.com/dcos
> > >> --
> > >> Javi Roman
> > >>
> > >> Twitter: @javiromanrh
> > >> GitHub: github.com/javiroman
> > >> Linkedin: es.linkedin.com/in/javiroman
> > >> Big Data Blog: dataintensive.info
> > >>
> > >>
> > >> On Sat, May 29, 2021 at 12:47 PM Charles-François Natali <
> > >> cf.nat...@gmail.com> wrote:
> > >>
> > >>> Hi Renan,
> > >>>
> > >>> > Renaming the topic because apparently we need to have this
> discussion
> > >>> again.
> > >>>
> > >>> Thanks for bringing this up again, because it is indeed still a
> problem.
> > >>>
> > >>> > 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 

Re: State of the Project

[Charles-François Natali]

Le dim. 30 mai 2021 à 16:09, Qian Zhang  a écrit :
> [...] So given the
> active committers and contributors that we have in the community, I do not
> think we can do anything big in the short term, instead we should do small
> things to gradually activate the community. Here are what in my mind:
> 1. Review and merge the outstanding PRs.
> 2. Review the tickets in JIRA and select some high priority ones to work on.
> 3. Add at least one new committer.

Yes I think it's important to mention, in response to Javi's point,
that one doesn't need to be an hard-core C++ dev to contribute.
The code base is actually very clean and easy to read, the main
problem is the use of libprocess/actor model which takes some getting
used to, especially for people who're more used to a reactor, green
thread, etc models. The libprocess doc [1] gives a good overview. The
stout doc [2] is also worth a read although nothing surprising about
its design.

But in any case I think there's a lot of valuable work which doesn't
require any C++, for example as Qian mentions going through the huge
backlog of JIRA issues.
I know it doesn't sound like the most exciting thing but it would
actually help a lot to do some triage, try to reproduce bugs, close
stale tickets, respond to user questions etc.

I remember seeing a few other people answering Qian's call for
contributors a couple months ago [3], it'd be great if they could
reach out if they're still interested - if not it's fine, I know we're
all busy with our lives :).

Cheers,

Charles


[1] https://github.com/apache/mesos/tree/master/3rdparty/libprocess
[2] https://github.com/apache/mesos/tree/master/3rdparty/stout
[3] 
https://mail-archives.apache.org/mod_mbox/mesos-dev/202103.mbox/%3CCABY6VOb%3DT8VxehVaS1YBrC5_odEwKhZzj3R4o3b-ykCytDw3JA%40mail.gmail.com%3E


>
> Please let me know for any comments / suggestions, thanks!
>
>
> Regards,
> Qian Zhang
>
>
> On Sun, May 30, 2021 at 7:59 PM Zahoor  wrote:
>
> > Hi
> >
> > Better to rewrite/redesign Mesos with a more popular language (like
> > golang) to attract more developers.
> > Just a mind voice.
> >
> > ../Zahoor
> >
> >
> > On Sun, May 30, 2021 at 4:08 PM Javi Roman 
> > wrote:
> >
> >> Totally agree that the main problem with this project is trying to
> >> increase the developer community.
> >>
> >> From my point of view, attracting new developers to a project of this
> >> complexity is difficult (C++ low level developers, creating Java and Python
> >> bindings is not easy). However, if we try to broaden the objectives of the
> >> project we may be able to attract other developers (not only C++
> >> developers) who can help.
> >>
> >> One idea I have always had is to incorporate the concept and technology
> >> of D2IQ DC/OS [1], in this way we would continue the abandoned work of D2IQ
> >> by extending Apache Mesos to a more user-friendly technology and broaden
> >> the base of developers with interest in (ReactJS, Go, Scala, databases).
> >>
> >> I would be interested in contributing in this line, being able to apply
> >> my knowledge in other areas, beyond C++ (which unfortunately I am not
> >> proficient in).
> >>
> >> [1] https://github.com/dcos
> >> --
> >> Javi Roman
> >>
> >> Twitter: @javiromanrh
> >> GitHub: github.com/javiroman
> >> Linkedin: es.linkedin.com/in/javiroman
> >> Big Data Blog: dataintensive.info
> >>
> >>
> >> On Sat, May 29, 2021 at 12:47 PM Charles-François Natali <
> >> cf.nat...@gmail.com> wrote:
> >>
> >>> Hi Renan,
> >>>
> >>> > Renaming the topic because apparently we need to have this discussion
> >>> again.
> >>>
> >>> Thanks for bringing this up again, because it is indeed still a problem.
> >>>
> >>> > 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].
> >>> >
> >>>
> >>> I must say I'm also a bit confused.
> >>> The new project chair was elected exactly a month ago [1].
> >>> Since then, the only thing I have seen - there might be more going on
> >>> being the scenes - is a single thread calling for input on new
> >>> technical direction [2], which as several people mentioned before is
> >>> not the most important issue the project is facing right now.
> >>> As far as I can tell, nothing as been done by the PMC/project chair to
> >>> address the more fundamental issue of the health of the community.
> >>> Now, Andrei has been doing a great job at reviewing MRs, but as
> >>> mentioned before he only has so much time available, and the project
> >>> can't have only one active committer.
> >>> So it would be good to hear from the project chair what they are
> >>> planning to do, if 

Re: State of the Project

[Qian Zhang]

Sorry for the late response, I was just back from a business trip and
started reviewing the PRs.

I think the current state is, from the PMC side, Andrei S and I can do the
reviews (and maybe Andrei B and Ben Mahler as well?), and Charles
and Andreas are doing code contributions (thank you!). So given the
active committers and contributors that we have in the community, I do not
think we can do anything big in the short term, instead we should do small
things to gradually activate the community. Here are what in my mind:
1. Review and merge the outstanding PRs.
2. Review the tickets in JIRA and select some high priority ones to work on.
3. Add at least one new committer.

Please let me know for any comments / suggestions, thanks!


Regards,
Qian Zhang


On Sun, May 30, 2021 at 7:59 PM Zahoor  wrote:

> Hi
>
> Better to rewrite/redesign Mesos with a more popular language (like
> golang) to attract more developers.
> Just a mind voice.
>
> ../Zahoor
>
>
> On Sun, May 30, 2021 at 4:08 PM Javi Roman 
> wrote:
>
>> Totally agree that the main problem with this project is trying to
>> increase the developer community.
>>
>> From my point of view, attracting new developers to a project of this
>> complexity is difficult (C++ low level developers, creating Java and Python
>> bindings is not easy). However, if we try to broaden the objectives of the
>> project we may be able to attract other developers (not only C++
>> developers) who can help.
>>
>> One idea I have always had is to incorporate the concept and technology
>> of D2IQ DC/OS [1], in this way we would continue the abandoned work of D2IQ
>> by extending Apache Mesos to a more user-friendly technology and broaden
>> the base of developers with interest in (ReactJS, Go, Scala, databases).
>>
>> I would be interested in contributing in this line, being able to apply
>> my knowledge in other areas, beyond C++ (which unfortunately I am not
>> proficient in).
>>
>> [1] https://github.com/dcos
>> --
>> Javi Roman
>>
>> Twitter: @javiromanrh
>> GitHub: github.com/javiroman
>> Linkedin: es.linkedin.com/in/javiroman
>> Big Data Blog: dataintensive.info
>>
>>
>> On Sat, May 29, 2021 at 12:47 PM Charles-François Natali <
>> cf.nat...@gmail.com> wrote:
>>
>>> Hi Renan,
>>>
>>> > Renaming the topic because apparently we need to have this discussion
>>> again.
>>>
>>> Thanks for bringing this up again, because it is indeed still a problem.
>>>
>>> > 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].
>>> >
>>>
>>> I must say I'm also a bit confused.
>>> The new project chair was elected exactly a month ago [1].
>>> Since then, the only thing I have seen - there might be more going on
>>> being the scenes - is a single thread calling for input on new
>>> technical direction [2], which as several people mentioned before is
>>> not the most important issue the project is facing right now.
>>> As far as I can tell, nothing as been done by the PMC/project chair to
>>> address the more fundamental issue of the health of the community.
>>> Now, Andrei has been doing a great job at reviewing MRs, but as
>>> mentioned before he only has so much time available, and the project
>>> can't have only one active committer.
>>> So it would be good to hear from the project chair what they are
>>> planning to do, if anything, to address this situation.
>>> From some private conversations I know that they have been busy with
>>> other obligations in the past month so maybe it's only a bad timing
>>> and just a transient state, however I don't think it's viable to
>>> continue if even the project chair doesn't have any time to dedicate
>>> to the project - not even replying to this thread.
>>>
>>> > 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.
>>>
>>> I'm not familiar with the ASF but yes it does sounds like a possible
>>> course of action?
>>>
>>> Cheers,
>>>
>>> Charles
>>>
>>>
>>>
>>> [1]
>>> https://mail-archives.apache.org/mod_mbox/mesos-dev/202104.mbox/%3CCAE0xwObaHPiSFM3KrY1SL--E864L48o_LF2E7PP2%3DUu3rk99gQ%40mail.gmail.com%3E
>>> [2]
>>> https://mail-archives.apache.org/mod_mbox/mesos-dev/202105.mbox/%3CCABY6VOaOxSp%2BeMJm_jSTdY%3DD5Qp%3DT%2B89Cvaxqw7GLbFYr1qzew%40mail.gmail.com%3E
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > -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  a
>>> écrit :
>>> > >>> several fixing bugs which basically make Mesos unusable on 

Re: State of the Project

[Zahoor]

Hi

Better to rewrite/redesign Mesos with a more popular language (like golang)
to attract more developers.
Just a mind voice.

../Zahoor


On Sun, May 30, 2021 at 4:08 PM Javi Roman  wrote:

> Totally agree that the main problem with this project is trying to
> increase the developer community.
>
> From my point of view, attracting new developers to a project of this
> complexity is difficult (C++ low level developers, creating Java and Python
> bindings is not easy). However, if we try to broaden the objectives of the
> project we may be able to attract other developers (not only C++
> developers) who can help.
>
> One idea I have always had is to incorporate the concept and technology of
> D2IQ DC/OS [1], in this way we would continue the abandoned work of D2IQ by
> extending Apache Mesos to a more user-friendly technology and broaden the
> base of developers with interest in (ReactJS, Go, Scala, databases).
>
> I would be interested in contributing in this line, being able to apply my
> knowledge in other areas, beyond C++ (which unfortunately I am not
> proficient in).
>
> [1] https://github.com/dcos
> --
> Javi Roman
>
> Twitter: @javiromanrh
> GitHub: github.com/javiroman
> Linkedin: es.linkedin.com/in/javiroman
> Big Data Blog: dataintensive.info
>
>
> On Sat, May 29, 2021 at 12:47 PM Charles-François Natali <
> cf.nat...@gmail.com> wrote:
>
>> Hi Renan,
>>
>> > Renaming the topic because apparently we need to have this discussion
>> again.
>>
>> Thanks for bringing this up again, because it is indeed still a problem.
>>
>> > 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].
>> >
>>
>> I must say I'm also a bit confused.
>> The new project chair was elected exactly a month ago [1].
>> Since then, the only thing I have seen - there might be more going on
>> being the scenes - is a single thread calling for input on new
>> technical direction [2], which as several people mentioned before is
>> not the most important issue the project is facing right now.
>> As far as I can tell, nothing as been done by the PMC/project chair to
>> address the more fundamental issue of the health of the community.
>> Now, Andrei has been doing a great job at reviewing MRs, but as
>> mentioned before he only has so much time available, and the project
>> can't have only one active committer.
>> So it would be good to hear from the project chair what they are
>> planning to do, if anything, to address this situation.
>> From some private conversations I know that they have been busy with
>> other obligations in the past month so maybe it's only a bad timing
>> and just a transient state, however I don't think it's viable to
>> continue if even the project chair doesn't have any time to dedicate
>> to the project - not even replying to this thread.
>>
>> > 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.
>>
>> I'm not familiar with the ASF but yes it does sounds like a possible
>> course of action?
>>
>> Cheers,
>>
>> Charles
>>
>>
>>
>> [1]
>> https://mail-archives.apache.org/mod_mbox/mesos-dev/202104.mbox/%3CCAE0xwObaHPiSFM3KrY1SL--E864L48o_LF2E7PP2%3DUu3rk99gQ%40mail.gmail.com%3E
>> [2]
>> https://mail-archives.apache.org/mod_mbox/mesos-dev/202105.mbox/%3CCABY6VOaOxSp%2BeMJm_jSTdY%3DD5Qp%3DT%2B89Cvaxqw7GLbFYr1qzew%40mail.gmail.com%3E
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> >
>> > -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  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 

Re: State of the Project

[Javi Roman]

Totally agree that the main problem with this project is trying to increase
the developer community.

>From my point of view, attracting new developers to a project of this
complexity is difficult (C++ low level developers, creating Java and Python
bindings is not easy). However, if we try to broaden the objectives of the
project we may be able to attract other developers (not only C++
developers) who can help.

One idea I have always had is to incorporate the concept and technology of
D2IQ DC/OS [1], in this way we would continue the abandoned work of D2IQ by
extending Apache Mesos to a more user-friendly technology and broaden the
base of developers with interest in (ReactJS, Go, Scala, databases).

I would be interested in contributing in this line, being able to apply my
knowledge in other areas, beyond C++ (which unfortunately I am not
proficient in).

[1] https://github.com/dcos
--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info


On Sat, May 29, 2021 at 12:47 PM Charles-François Natali <
cf.nat...@gmail.com> wrote:

> Hi Renan,
>
> > Renaming the topic because apparently we need to have this discussion
> again.
>
> Thanks for bringing this up again, because it is indeed still a problem.
>
> > 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].
> >
>
> I must say I'm also a bit confused.
> The new project chair was elected exactly a month ago [1].
> Since then, the only thing I have seen - there might be more going on
> being the scenes - is a single thread calling for input on new
> technical direction [2], which as several people mentioned before is
> not the most important issue the project is facing right now.
> As far as I can tell, nothing as been done by the PMC/project chair to
> address the more fundamental issue of the health of the community.
> Now, Andrei has been doing a great job at reviewing MRs, but as
> mentioned before he only has so much time available, and the project
> can't have only one active committer.
> So it would be good to hear from the project chair what they are
> planning to do, if anything, to address this situation.
> From some private conversations I know that they have been busy with
> other obligations in the past month so maybe it's only a bad timing
> and just a transient state, however I don't think it's viable to
> continue if even the project chair doesn't have any time to dedicate
> to the project - not even replying to this thread.
>
> > 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.
>
> I'm not familiar with the ASF but yes it does sounds like a possible
> course of action?
>
> Cheers,
>
> Charles
>
>
>
> [1]
> https://mail-archives.apache.org/mod_mbox/mesos-dev/202104.mbox/%3CCAE0xwObaHPiSFM3KrY1SL--E864L48o_LF2E7PP2%3DUu3rk99gQ%40mail.gmail.com%3E
> [2]
> https://mail-archives.apache.org/mod_mbox/mesos-dev/202105.mbox/%3CCABY6VOaOxSp%2BeMJm_jSTdY%3DD5Qp%3DT%2B89Cvaxqw7GLbFYr1qzew%40mail.gmail.com%3E
>
>
>
>
>
>
>
>
>
> >
> > -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  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 

Re: State of the Project

[Charles-François Natali]

Hi Renan,

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

Thanks for bringing this up again, because it is indeed still a problem.

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

I must say I'm also a bit confused.
The new project chair was elected exactly a month ago [1].
Since then, the only thing I have seen - there might be more going on
being the scenes - is a single thread calling for input on new
technical direction [2], which as several people mentioned before is
not the most important issue the project is facing right now.
As far as I can tell, nothing as been done by the PMC/project chair to
address the more fundamental issue of the health of the community.
Now, Andrei has been doing a great job at reviewing MRs, but as
mentioned before he only has so much time available, and the project
can't have only one active committer.
So it would be good to hear from the project chair what they are
planning to do, if anything, to address this situation.
>From some private conversations I know that they have been busy with
other obligations in the past month so maybe it's only a bad timing
and just a transient state, however I don't think it's viable to
continue if even the project chair doesn't have any time to dedicate
to the project - not even replying to this thread.

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

I'm not familiar with the ASF but yes it does sounds like a possible
course of action?

Cheers,

Charles



[1] 
https://mail-archives.apache.org/mod_mbox/mesos-dev/202104.mbox/%3CCAE0xwObaHPiSFM3KrY1SL--E864L48o_LF2E7PP2%3DUu3rk99gQ%40mail.gmail.com%3E
[2] 
https://mail-archives.apache.org/mod_mbox/mesos-dev/202105.mbox/%3CCABY6VOaOxSp%2BeMJm_jSTdY%3DD5Qp%3DT%2B89Cvaxqw7GLbFYr1qzew%40mail.gmail.com%3E









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

Re: [BULK]Discuss the possible technical directions of Mesos

[Charles-François Natali]

Hey,

Le lun. 24 mai 2021 à 14:12, Qian Zhang  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 
> 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  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
> > >
> >

Re: [BULK]Discuss the possible technical directions of Mesos

[Qian Zhang]

Hi Charles,

I agree that we should re-activate the community first, both Andrei and I
can help review patches, we have complementary Mesos knowledge, he can help
on the patches for Mesos master/allocator and I can do for Mesos
agent/containerizer.

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


Regards,
Qian Zhang


On Fri, May 21, 2021 at 2:57 AM Charles-François Natali 
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  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
> >
>

Re: [BULK]Discuss the possible technical directions of Mesos

[Charles-François Natali]

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

Re: [BULK]Discuss the possible technical directions of Mesos

[Gregoire Seux]

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

Re: Discuss the possible technical directions of Mesos

[Andreas Peters]

Hi Qian,

great list and good ideas. Maybe we can also add some new features to
the mesos_cli?

> I feel that we should not position Mesos as a generic container
> orchestrator, instead we should find a specific scenario for it, maybe HPC
> is a good direction? 

My customers always tell me, they like and still use Mesos because it do
not give them borders. They can use containers but they don't have to.
And (maybe that's the biggest advantage), they can develope there own
framework for there specific case. So, I think, HPC is definitely a very
interesting direction, but we should not be too specific. :-)


Cheers,
Andreas



OpenPGP_signature
Description: OpenPGP digital signature

Re: New PMC Chair

[Qian Zhang]

Hi Marc,

I will take the lead on this project. My plan is to collect the
requirements from the community and then come up with a roadmap plan which
I will send here to discuss.

Please feel free to let me know for any comments / suggestions, thanks!

Regards,
Qian Zhang


On Fri, Apr 30, 2021 at 4:36 PM Marc  wrote:

> I do not really understand what this means, and how it affects (the future
> of) the mesos project. Can anyone elaborate on that?
>
>
>
> > -Original Message-
> > From: Vinod Kone
> > Sent: 29 April 2021 16:35
> > To: dev ; user 
> > Subject: New PMC Chair
> >
> > Hi community,
> >
> > Just wanted to let you all know that the board passed the resolution to
> > elect a new PMC chair!
> >
> > Hearty congratulations to Qian Zhang for becoming the new Apache Mesos
> > PMC chair and VP of the project.
> >
> > Thanks,
>

RE: New PMC Chair

[Marc]

I do not really understand what this means, and how it affects (the future of) 
the mesos project. Can anyone elaborate on that?



> -Original Message-
> From: Vinod Kone
> Sent: 29 April 2021 16:35
> To: dev ; user 
> Subject: New PMC Chair
> 
> Hi community,
> 
> Just wanted to let you all know that the board passed the resolution to
> elect a new PMC chair!
> 
> Hearty congratulations to Qian Zhang for becoming the new Apache Mesos
> PMC chair and VP of the project.
> 
> Thanks,

Re: [BULK]Re: New PMC Chair

[Qian Zhang]

Thanks Vinod! Really appreciate your contributions and guidance to this
great project.

It's a huge honor to be the new PMC chair, I will try my best to work with
the community and make Mesos better.


Regards,
Qian Zhang


On Fri, Apr 30, 2021 at 1:16 AM Thomas Langé  wrote:

> That's really good news! Well done!
>
> Thomas
> --
> *From:* Charles-François Natali 
> *Sent:* Thursday, 29 April 2021 19:12
> *To:* user 
> *Cc:* dev ; Vinod Kone 
> *Subject:* [BULK]Re: New PMC Chair
>
> Congratulations!
>
>
>
> On Thu, 29 Apr 2021, 23:37 Andreas Peters,  wrote:
>
> Great to hear. :-)
>
> Am 29.04.21 um 16:35 schrieb Vinod Kone:
> > Hi community,
> >
> > Just wanted to let you all know that the board passed the resolution to
> > elect a new PMC chair!
> >
> > Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> > PMC chair and VP of the project.
> >
> > Thanks,
> >
>
>

Re: [BULK]Re: New PMC Chair

[Sam Chen]

Congrats ! Well deserved!


On Fri, 30 Apr 2021 at 01:49 Grégoire Seux  wrote:

> Congratulations!
>
> -- ​
> Grégoire
>
> --
> *From:* Andreas Peters
> *Sent:* Thursday, April 29, 2021 6:36 PM
> *To:* d...@mesos.apache.org; Vinod Kone; user
> *Subject:* [BULK]Re: New PMC Chair
>
> Great to hear. :-)
>
> Am 29.04.21 um 16:35 schrieb Vinod Kone:
> > Hi community,
> >
> > Just wanted to let you all know that the board passed the resolution to
> > elect a new PMC chair!
> >
> > Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> > PMC chair and VP of the project.
> >
> > Thanks,
> >
>
>

Re: [BULK]Re: New PMC Chair

[Haijiang Chen]

Congratulations Qian. Well deserved!!

--Haijiang

On Fri, Apr 30, 2021 at 1:49 AM Grégoire Seux  wrote:

> Congratulations!
>
> -- ​
> Grégoire
>
> --
> *From:* Andreas Peters
> *Sent:* Thursday, April 29, 2021 6:36 PM
> *To:* d...@mesos.apache.org; Vinod Kone; user
> *Subject:* [BULK]Re: New PMC Chair
>
> Great to hear. :-)
>
> Am 29.04.21 um 16:35 schrieb Vinod Kone:
> > Hi community,
> >
> > Just wanted to let you all know that the board passed the resolution to
> > elect a new PMC chair!
> >
> > Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> > PMC chair and VP of the project.
> >
> > Thanks,
> >
>
>

Re: [BULK]Re: New PMC Chair

[Grégoire Seux]

Congratulations!

-- ​
Grégoire


From: Andreas Peters
Sent: Thursday, April 29, 2021 6:36 PM
To: d...@mesos.apache.org; Vinod Kone; user
Subject: [BULK]Re: New PMC Chair

Great to hear. :-)

Am 29.04.21 um 16:35 schrieb Vinod Kone:
> Hi community,
>
> Just wanted to let you all know that the board passed the resolution to
> elect a new PMC chair!
>
> Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> PMC chair and VP of the project.
>
> Thanks,
>

Re: [BULK]Re: New PMC Chair

[Thomas Langé]

That's really good news! Well done!

Thomas

From: Charles-François Natali 
Sent: Thursday, 29 April 2021 19:12
To: user 
Cc: dev ; Vinod Kone 
Subject: [BULK]Re: New PMC Chair

Congratulations!



On Thu, 29 Apr 2021, 23:37 Andreas Peters, 
mailto:a...@aventer.biz>> wrote:
Great to hear. :-)

Am 29.04.21 um 16:35 schrieb Vinod Kone:
> Hi community,
>
> Just wanted to let you all know that the board passed the resolution to
> elect a new PMC chair!
>
> Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> PMC chair and VP of the project.
>
> Thanks,
>

Re: New PMC Chair

[Charles-François Natali]

Congratulations!



On Thu, 29 Apr 2021, 23:37 Andreas Peters,  wrote:

> Great to hear. :-)
>
> Am 29.04.21 um 16:35 schrieb Vinod Kone:
> > Hi community,
> >
> > Just wanted to let you all know that the board passed the resolution to
> > elect a new PMC chair!
> >
> > Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> > PMC chair and VP of the project.
> >
> > Thanks,
> >
>
>

Re: New PMC Chair

[Andreas Peters]

Great to hear. :-)

Am 29.04.21 um 16:35 schrieb Vinod Kone:
> Hi community,
>
> Just wanted to let you all know that the board passed the resolution to
> elect a new PMC chair!
>
> Hearty congratulations to *Qian Zhang* for becoming the new Apache Mesos
> PMC chair and VP of the project.
>
> Thanks,
>



OpenPGP_signature
Description: OpenPGP digital signature

Re: [VOTE] Move Apache Mesos to Attic

[DhilipKumar Sankaranarayanan]

+1

All the very best everyone,
really sad to see this great project go to attic :-( also excited about
it's potential forks.

Regards,
Dhilip

On Tue, 6 Apr, 2021, 3:07 PM Benjamin Mahler,  wrote:

> +1 (binding)
>
> Thanks to all who contributed to the project.
>
> On Mon, Apr 5, 2021 at 1:58 PM Vinod Kone  wrote:
>
>> Hi folks,
>>
>> Based on the recent conversations
>> <
>> https://lists.apache.org/thread.html/raed89cc5ab78531c48f56aa1989e1e7eb05f89a6941e38e9bc8803ff%40%3Cuser.mesos.apache.org%3E
>> >
>> on our mailing list, it seems to me that the majority consensus among the
>> existing PMC is to move the project to the attic <
>> https://attic.apache.org/>
>> and let the interested community members collaborate on a fork in Github.
>>
>> I would like to call a vote to dissolve the PMC and move the project to
>> the
>> attic.
>>
>> Please reply to this thread with your vote. Only binding votes from
>> PMC/committers count towards the final tally but everyone in the community
>> is encouraged to vote. See process here
>> .
>>
>> Thanks,
>>
>

RE: Future technical direction of Mesos?

[Marc]

> I'm asking, because I'm under impression that an (unconscious) view of
> some/many of the PMC is that Mesos is not  - and will never be -
> solving any task that Kubernetes is not solving now and will not be
> solving in the foreseeable future. _If_ one views Mesos+something as a
> "contender in a container orchestration war" then that "battle" is
> clearly lost.

I have been wondering about this. Not having any knowledge of kubernetes. At 
the time I decided to 'use' mesos it was my understanding that multiple 
networks (multihome tasks) were not possible with kubernetes. 

I saw some video where the mesos development team explained why there was a 
need to create a mesos containerizer because the docker one was not stable 
enough. Has kubernetes their own containerizer?

What should I think when I read about such things: "Kubernetes and Mesos employ 
different tactics to handle the same problem. Mesos is more ambitious, as 
Kubernetes equates to just a single node of Mesos’ entire solution."[1]

And last but not least, from a commercial aspect is it not better to be able to 
have choice? Ending up with only kubernetes will result in another tool for 
google to force their standards.

If I may continue your bad analogy. Apple is still making iphones although they 
clearly lost against the android platform. ;)


[1]
https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/

Re: [VOTE] Move Apache Mesos to Attic

[Gastón Kleiman]

+1

I had a great time working with you all and with the community! Hope our
paths cross again in the future!

On Mon, Apr 5, 2021 at 10:58 AM Vinod Kone  wrote:

> Hi folks,
>
> Based on the recent conversations
> 
> on our mailing list, it seems to me that the majority consensus among the
> existing PMC is to move the project to the attic
>  and let the interested community members
> collaborate on a fork in Github.
>
> I would like to call a vote to dissolve the PMC and move the project to
> the attic.
>
> Please reply to this thread with your vote. Only binding votes from
> PMC/committers count towards the final tally but everyone in the community
> is encouraged to vote. See process here
> .
>
> Thanks,
>

Re: [VOTE] Move Apache Mesos to Attic

[Kevin Klues]

+1 (binding)

While it is of course sad to see things come to an end here, I do encourage
those of you who wish to see Mesos live on to try and breath new life into
it as a standalone project on github.
In that sense, this is more of a new beginning than an end.
The king is dead, long live the king!

Kevin

Am Di., 6. Apr. 2021 um 21:07 Uhr schrieb Benjamin Mahler <
bmah...@apache.org>:

> +1 (binding)
>
> Thanks to all who contributed to the project.
>
> On Mon, Apr 5, 2021 at 1:58 PM Vinod Kone  wrote:
>
>> Hi folks,
>>
>> Based on the recent conversations
>> <
>> https://lists.apache.org/thread.html/raed89cc5ab78531c48f56aa1989e1e7eb05f89a6941e38e9bc8803ff%40%3Cuser.mesos.apache.org%3E
>> >
>> on our mailing list, it seems to me that the majority consensus among the
>> existing PMC is to move the project to the attic <
>> https://attic.apache.org/>
>> and let the interested community members collaborate on a fork in Github.
>>
>> I would like to call a vote to dissolve the PMC and move the project to
>> the
>> attic.
>>
>> Please reply to this thread with your vote. Only binding votes from
>> PMC/committers count towards the final tally but everyone in the community
>> is encouraged to vote. See process here
>> .
>>
>> Thanks,
>>
>

-- 
~Kevin

Re: [VOTE] Move Apache Mesos to Attic

[Benjamin Mahler]

+1 (binding)

Thanks to all who contributed to the project.

On Mon, Apr 5, 2021 at 1:58 PM Vinod Kone  wrote:

> Hi folks,
>
> Based on the recent conversations
> <
> https://lists.apache.org/thread.html/raed89cc5ab78531c48f56aa1989e1e7eb05f89a6941e38e9bc8803ff%40%3Cuser.mesos.apache.org%3E
> >
> on our mailing list, it seems to me that the majority consensus among the
> existing PMC is to move the project to the attic <
> https://attic.apache.org/>
> and let the interested community members collaborate on a fork in Github.
>
> I would like to call a vote to dissolve the PMC and move the project to the
> attic.
>
> Please reply to this thread with your vote. Only binding votes from
> PMC/committers count towards the final tally but everyone in the community
> is encouraged to vote. See process here
> .
>
> Thanks,
>

Re: [VOTE] Move Apache Mesos to Attic

[Gastón Kleiman]

+1

I had a great time working with you all and with the community! Hope our
paths cross again in the future!

On Mon, Apr 5, 2021 at 10:58 AM Vinod Kone  wrote:

> Hi folks,
>
> Based on the recent conversations
> 
> on our mailing list, it seems to me that the majority consensus among the
> existing PMC is to move the project to the attic
>  and let the interested community members
> collaborate on a fork in Github.
>
> I would like to call a vote to dissolve the PMC and move the project to
> the attic.
>
> Please reply to this thread with your vote. Only binding votes from
> PMC/committers count towards the final tally but everyone in the community
> is encouraged to vote. See process here
> .
>
> Thanks,
>

Re: [VOTE] Move Apache Mesos to Attic

[Meng Zhu]

+1

It has been a pleasure working with you all!

On Mon, Apr 5, 2021 at 10:58 AM Vinod Kone  wrote:

> Hi folks,
>
> Based on the recent conversations
> <
> https://lists.apache.org/thread.html/raed89cc5ab78531c48f56aa1989e1e7eb05f89a6941e38e9bc8803ff%40%3Cuser.mesos.apache.org%3E
> >
> on our mailing list, it seems to me that the majority consensus among the
> existing PMC is to move the project to the attic <
> https://attic.apache.org/>
> and let the interested community members collaborate on a fork in Github.
>
> I would like to call a vote to dissolve the PMC and move the project to the
> attic.
>
> Please reply to this thread with your vote. Only binding votes from
> PMC/committers count towards the final tally but everyone in the community
> is encouraged to vote. See process here
> .
>
> Thanks,
>

Re: [VOTE] Move Apache Mesos to Attic

[Jie Yu]

+1

It was great working with you all.

On Tue, Apr 6, 2021 at 7:13 AM Till Toenshoff  wrote:

>
>
> On 5. Apr 2021, at 19:58, Vinod Kone  wrote:
>
> Hi folks,
>
> Based on the recent conversations
> 
> on our mailing list, it seems to me that the majority consensus among the
> existing PMC is to move the project to the attic
>  and let the interested community members
> collaborate on a fork in Github.
>
> I would like to call a vote to dissolve the PMC and move the project to
> the attic.
>
> Please reply to this thread with your vote. Only binding votes from
> PMC/committers count towards the final tally but everyone in the community
> is encouraged to vote. See process here
> .
>
> Thanks,
>
>
>
>
> +1 for move to attic.
>

Re: [VOTE] Move Apache Mesos to Attic

[Till Toenshoff]

> On 5. Apr 2021, at 19:58, Vinod Kone  wrote:
> 
> Hi folks,
> 
> Based on the recent conversations 
> 
>  on our mailing list, it seems to me that the majority consensus among the 
> existing PMC is to move the project to the attic  
> and let the interested community members collaborate on a fork in Github.
> 
> I would like to call a vote to dissolve the PMC and move the project to the 
> attic. 
> 
> Please reply to this thread with your vote. Only binding votes from 
> PMC/committers count towards the final tally but everyone in the community is 
> encouraged to vote. See process here .
> 
> Thanks,



+1 for move to attic.

RE: Call for new committers

[Marc]

Good! Very nice to read!



> -Original Message-
> Sent: 05 April 2021 12:09
> To: user@mesos.apache.org
> Cc: mesos 
> Subject: Re: Call for new committers
> 
> Hi, I would like to contribute actively within my possibilities.
> 
> I'm the Fedora Mesos package maintainer
> (https://src.fedoraproject.org/rpms/mesos), and PPMC of Apache Myriad
> (YARN on Mesos) (unfortunately retired).
> 
> Probably I can contribute in different ways.
> 
> 
> --
> Javi Roman
> 
> Twitter: @javiromanrh
> GitHub: github.com/javiroman <http://github.com/javiroman>
> Linkedin: es.linkedin.com/in/javiroman
> <http://es.linkedin.com/in/javiroman>
> Big Data Blog: dataintensive.info <http://dataintensive.info>
> 
> 
> 
> On Sun, Mar 14, 2021 at 1:00 PM Qian Zhang  <mailto:zhq527...@gmail.com> > wrote:
> 
> 
>   Hi folks,
> 
>   Please reply to this mail if you plan to actively contribute to
> Mesos and want to become a new Mesos committer, thanks!
> 
> 
>   Regards,
>   Qian Zhang

Re: Call for new committers

[Javi Roman]

Hi, I would like to contribute actively within my possibilities.

I'm the Fedora Mesos package maintainer (
https://src.fedoraproject.org/rpms/mesos), and PPMC of Apache Myriad (YARN
on Mesos) (unfortunately retired).

Probably I can contribute in different ways.


--
Javi Roman

Twitter: @javiromanrh
GitHub: github.com/javiroman
Linkedin: es.linkedin.com/in/javiroman
Big Data Blog: dataintensive.info


On Sun, Mar 14, 2021 at 1:00 PM Qian Zhang  wrote:

> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a new Mesos committer, thanks!
>
>
> Regards,
> Qian Zhang
>

RE: Just saw - Call for new committers

[Marc]

> > I found rexray to be a bit buggy with releasing rbd's on time, making
> it difficult for tasks to move to different hosts. But I tested this
> maybe more than a year ago.
> 
> It's still buggy in that point. But in our case, it does not happen
> often.
> 
> > You can give it a try. Be carefull using the original csi driver, it
> overwrites your /etc/ceph/ceph.conf
> > https://github.com/f1-outsourcing/csiceph/tree/master
> 
> I will try in the next days and give you feedback.
> 
> Can you show me the "mesos csi plugin json" u use for ceph?

[@~]# cat /etc/mesos-csi/csi-ceph.json
{
  "type": "rbd.csi.ceph.io",
  "endpoints": [
{
  "csi_service": "NODE_SERVICE",
  "endpoint": "unix:///tmp/mesos-csi-uuh6Ra/endpoint.sock"
}
  ],
  "target_path_root": "/mnt/mesos-unman-plugin"
}

RE: Just saw - Call for new committers

[Marc]

> > Any interest in using csi with ceph for stateful tasks?
> 
> I would! We already use ceph in mesos but via rexray. I was thinking to
> take a deeper look into to csi driver therefore I can remove rexray from
> our stack.
> 
> 

I found rexray to be a bit buggy with releasing rbd's on time, making it 
difficult for tasks to move to different hosts. But I tested this maybe more 
than a year ago.

Because I want to limit linux capabilities on tasks I have decided to configure 
the external/unmanaged csidriver.


[@c04 mesos-csi]# tail /etc/rc.local

# mesos csi nfs plugin
/usr/libexec/csi/csinfs-start.sh
# mesos csi ceph plugin
/usr/libexec/csi/csiceph-start.sh


[@c04 mesos-csi]# cat /usr/libexec/csi/csiceph-start.sh
#!/bin/bash
#

umask 0077

export CSI_DEFUSERID="app.mesos.test"
export CSI_DEFUSERKEY="KE=="

mkdir /tmp/mesos-csi-uuh6Ra 2>/dev/null
cd /tmp/mesos-csi-uuh6Ra
/usr/libexec/csi/csiceph -endpoint 'unix:///tmp/mesos-csi-uuh6Ra/endpoint.sock' 
-nodeid $HOSTNAME -type rbd -drivername ceph-csi-rbd -v 10 
-log_file=./csiceph-plugin.log -logtostderr=false >stdout 2>stderr &

You can give it a try. Be carefull using the original csi driver, it overwrites 
your /etc/ceph/ceph.conf
https://github.com/f1-outsourcing/csiceph/tree/master

RE: Just saw - Call for new committers

[Marc]

> I saw that Qian Zhang was calling about new commiters. Well, I already
> ask one month ago on slack if I can help the Mesos project. :-) Benjamin
> told me I should subscribe these Mailinglist, but what should I say, I
> missed the confirmation mail and was wondering why the mailinglist is so
> silent. :-)

Yes it is. Great place to send yourself messages and meditate! :)

> To me; Mesos is a important part of my own company. I drive it for all
> of our own services but I also help customers to install and run it in
> there environment. 

Any interest in using csi with ceph for stateful tasks? It is really nice to 
see that these tasks are able to take their storage to whatever hosts their 
deployed on.
I was asking the developers of the cephcsi a while ago to change their code so 
it actually works as a csi driver and not as a kubernetes driver. And they are 
willing to do some work to create the required functionality for the slrp. 
I currently test a bit with preprovisioned rbd images in tasks via mvp. (I had 
to change code of csiceph driver for that to get it to work)

>I also developed a mesos kafka framework and I'm the
> developer of the "Mesos Executor" (and soon the Mesos Operator) for
> Apache Airflow 2.x. Yeah I know, thats just small things. But I'm
> willing to learn and grow.

You know anything of the Marathon? They implemented csi secrets driver via some 
proprietary secrets solution, not using the default mesos secrets. (ao. that is 
why I had to change the cephcsi driver)

> So... Here I'm and it would be my pleasure to help. :-)
> 
You have my appreciation!

Re: [BULK]Re: Call for new committers

[Thomas Langé]

Hello,

Still interested as well.

Thomas

From: Charles-François Natali 
Sent: Monday, 15 March 2021 09:53
To: user 
Subject: [BULK]Re: Call for new committers

Hi,

I'm still interested.

Would it be possible to get a rough roadmap of the proposed course of action?

So far there's been several email threads asking for feature requests, 
contributors etc, but AFAICT no feedback, so it's hard to know exactly what's 
going on, and I imagine it would make it easier for people to step up if there 
was a clear direction.

Cheers,



On Sun, 14 Mar 2021, 13:05 Stéphane Cottin, 
mailto:stephane.cot...@vixns.com>> wrote:
Hi,

I will contribute to mesos and would like to become a Mesos committer.

Stéphane

On 14 Mar 2021, at 12:59, Qian Zhang wrote:

> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a new Mesos committer, thanks!
>
>
> Regards,
> Qian Zhang

Re: Next Steps

[Vinod Kone]

>
>
> How many man hours where spend on mesos in 2020, 2019 and 2018?
>
>
Roughly 5-6 ppl (in 2020),10-11 (in 2019), 16-18 (in 2018)

RE: Next Steps

[Marc]

> 
> Most existing PMC members who have chimed in so far seemed to be in
> favor of moving the project to Attic. The exception is Qian (who is
> willing to step up to be the new PMC chair, thanks Qian!). The main
> argument for this seems to be that it'll be hard to re-activate the
> project at this juncture with new PMC members / committers. Also that it

Yes, Qian great to read this, thanks!

> signals the current state of the project more accurately.
> 
> Re-activate:
> There are some active users in the community who would like to see this
> project stay alive and are even willing to step up to become committers
> / contributors. Some of these users are working for companies who are
> using Mesos in production. They would like to know potential new roadmap
> (there is a separate thread going on for this) and manpower needed (my
> take is 6-8 ppl to cover different areas of the project).
> 

How many man hours where spend on mesos in 2020, 2019 and 2018?

Re: Next Steps

[Vinod Kone]

Hi folks,

Sorry for the radio silence on my part for the last couple weeks. My Apache
emails were not getting delivered to my inbox due to some filter mixup on
my end. Sorry about that.

I've read through the various threads and here's how I summarize the
situation. We basically have 2 camps

*Attic:*
Most existing PMC members who have chimed in so far seemed to be in favor
of moving the project to Attic. The exception is Qian (who is willing to
step up to be the new PMC chair, thanks Qian!). The main argument for this
seems to be that it'll be hard to re-activate the project at this juncture
with new PMC members / committers. Also that it signals the current state
of the project more accurately.

*Re-activate:*
There are some active users in the community who would like to see this
project stay alive and are even willing to step up to become committers /
contributors. Some of these users are working for companies who are using
Mesos in production. They would like to know potential new roadmap (there
is a separate thread going on for this) and manpower needed (my take is 6-8
ppl to cover different areas of the project).

*My take:*

In addition to the public threads, we've had a thread on our private
mailing list to see which of the current committers are interested in being
active. And so far that thread has gotten *0* responses. This is
unfortunate because, except for Qian no existing committer/PMC members are
willing or able to contribute or mentor new contributors.

Additionally, the current guidelines
<http://mesos.apache.org/documentation/latest/committers/> we have for
adding new committers is a pretty high bar and I don't think any of the
current contributors would be immediately eligible to be voted in as
committers. This means we either need to change the guidelines or we should
have some existing committers mentor some of the contributors into
committers. Given the lack of commitment from most of the existing PMC,
this will fall solely on Qian's shoulders which is quite a burden.

Since the existing committers are unable or unwilling to mentor new
contributors into new committers, I think moving the project to attic is
the right move. If there is no objection to this, I'm happy to call a vote
for this.

We could still explore the possibility of activating "
https://github.com/mesos/mesos; as the one true fork outside of ASF so that
the interested parties can still contribute and collaborate. And if the
project continues to thrive here, we can reach back out to ASF to
re-activate the project, down the line.

Thanks,


On Sat, Feb 27, 2021 at 7:45 AM Damien GERARD  wrote:

> On 2021-02-26 09:05 PM, Charles-François Natali wrote:
> > As mentioned before I'd also be happy to contribute.
> >
> > Concretely, what's the next step to move this forward?
> >
> > On Fri, 26 Feb 2021, 11:15 Thomas Langé,  wrote:
> >
> >> Hello,
> >>
> >> I'm part of Criteo team as well, and as Grégoire said, we plan to
> >> support Mesos internally for some time. I would like to
> >> propose my help as well as a committer, and contribute as much as I
> >> can to this project.
>
> At Rakuten we also have a couple of clusters. As also mentionned before,
> happy to contribute.
> But yeah, need a plan of action :p
>
>
> >>
> >> Br,
> >>
> >> Thomas
> >>
> >> -
> >>
> >> From: Grégoire Seux 
> >> Sent: Friday, 26 February 2021 11:12
> >> To: priv...@mesos.apache.org ; dev
> >> ; user 
> >> Subject: Re: Next Steps
> >>
> >> Hello all,
> >>
> >> here at Criteo, we heavily use Mesos and plan to do so for a
> >> foreseeable future alongside other alternatives.
> >> I am ok to become committer and help the project if you are looking
> >> for contributors.
> >> It seems finding committers will be doable but finding a PMC chair
> >> will be difficult.
> >>
> >> To give some context on our usage, Criteo is running 12 Mesos
> >> cluster running a light fork of Mesos 1.9.x.
> >> Each cluster has 10+ distinct marathons frameworks, a flink
> >> framework, an instance of Aurora and an in-house framework.
> >> We strongly appreciate the ability to scale the number of nodes
> >> (3500 on the largest cluster and growing), the simplicity of the
> >> project overall and the extensibility through modules.
> >>
> >> --
> >>
> >> Grégoire
>
> --
> Damien GERARD
>

RE: Call for new committers

[Marc]

Feedback is rare here, it would be nice if that would change for the better 
with the new team. I would like to know how much time has been put into mesos 
in the past, in order to better judge if the 'new team' is able to meet this 
'requirement'. Is this strange to ask? Seems sort of logical to me.


> -Original Message-
> Sent: 15 March 2021 09:53
> To: user 
> Subject: Re: Call for new committers
> 
> Hi,
> 
> I'm still interested.
> 
> Would it be possible to get a rough roadmap of the proposed course of
> action?
> 
> So far there's been several email threads asking for feature requests,
> contributors etc, but AFAICT no feedback, so it's hard to know exactly
> what's going on, and I imagine it would make it easier for people to
> step up if there was a clear direction.
> 
> Cheers,
> 
> 
> 
> On Sun, 14 Mar 2021, 13:05 Stéphane Cottin,  <mailto:stephane.cot...@vixns.com> > wrote:
> 
> 
>   Hi,
> 
>   I will contribute to mesos and would like to become a Mesos
> committer.
> 
>   Stéphane
> 
>   On 14 Mar 2021, at 12:59, Qian Zhang wrote:
> 
>   > Hi folks,
>   >
>   > Please reply to this mail if you plan to actively contribute to
> Mesos and
>   > want to become a new Mesos committer, thanks!
>   >
>   >
>   > Regards,
>   > Qian Zhang
> 

Re: [BULK]Re: Call for new committers

[Grégoire Seux]

Hello,

still interested as well

-- ​
Grégoire

From: Charles-François Natali 
Sent: Monday, March 15, 2021 9:53 AM
To: user 
Subject: [BULK]Re: Call for new committers

Hi,

I'm still interested.

Would it be possible to get a rough roadmap of the proposed course of action?

So far there's been several email threads asking for feature requests, 
contributors etc, but AFAICT no feedback, so it's hard to know exactly what's 
going on, and I imagine it would make it easier for people to step up if there 
was a clear direction.

Cheers,



On Sun, 14 Mar 2021, 13:05 Stéphane Cottin, 
mailto:stephane.cot...@vixns.com>> wrote:
Hi,

I will contribute to mesos and would like to become a Mesos committer.

Stéphane

On 14 Mar 2021, at 12:59, Qian Zhang wrote:

> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a new Mesos committer, thanks!
>
>
> Regards,
> Qian Zhang

Re: Call for new committers

[Charles-François Natali]

Hi,

I'm still interested.

Would it be possible to get a rough roadmap of the proposed course of
action?

So far there's been several email threads asking for feature requests,
contributors etc, but AFAICT no feedback, so it's hard to know exactly
what's going on, and I imagine it would make it easier for people to step
up if there was a clear direction.

Cheers,



On Sun, 14 Mar 2021, 13:05 Stéphane Cottin, 
wrote:

> Hi,
>
> I will contribute to mesos and would like to become a Mesos committer.
>
> Stéphane
>
> On 14 Mar 2021, at 12:59, Qian Zhang wrote:
>
> > Hi folks,
> >
> > Please reply to this mail if you plan to actively contribute to Mesos and
> > want to become a new Mesos committer, thanks!
> >
> >
> > Regards,
> > Qian Zhang
>

Re: Call for new committers

[Stéphane Cottin]

Hi,

I will contribute to mesos and would like to become a Mesos committer.

Stéphane

On 14 Mar 2021, at 12:59, Qian Zhang wrote:

> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a new Mesos committer, thanks!
>
>
> Regards,
> Qian Zhang

RE: Feature requests for Mesos

[Marc]

> 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

[Charles-François Natali]

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

RE: Feature requests for Mesos

[Marc]

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

[Marc]

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

[Andrei Sekretenko]

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

[Benjamin Mahler]

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

[Marc]

* 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: [BULK]Re: [BULK]Call for active contributors

[Charles-François Natali]

Also in - looking forward to contribute further.

Le jeu. 4 mars 2021 à 16:50, Tomek Janiszewski  a écrit :
>
> I'm in
> I can help with ARM CI, UI and some C++
>
> czw., 4 mar 2021 o 16:04 Thomas Langé  napisał(a):
>>
>> Same for me, I'm available to share my knowledge and actively contribute to 
>> Mesos project.
>>
>> Thomas
>> 
>> From: Haijiang Chen 
>> Sent: Thursday, 4 March 2021 16:01
>> To: user@mesos.apache.org 
>> Cc: mesos 
>> Subject: [BULK]Re: [BULK]Call for active contributors
>>
>> I am willing to contribute to Mesos on windows based on my current 
>> experiences.
>>
>> - Haijiang
>>
>> On Thu, Mar 4, 2021 at 10:56 PM Grégoire Seux  wrote:
>>
>> Already answered to the other thread. I'm in.
>>
>> --
>> Grégoire
>> 
>> From: Qian Zhang 
>> Sent: Thursday, March 4, 2021 3:38 PM
>> To: mesos ; user 
>> Subject: [BULK]Call for active contributors
>>
>> Hi folks,
>>
>> Please reply to this mail if you plan to actively contribute to Mesos and 
>> want to become a committer and PMC member in future.
>>
>>
>> Regards,
>> Qian Zhang

Re: [BULK]Re: [BULK]Call for active contributors

[Tomek Janiszewski]

I'm in
I can help with ARM CI, UI and some C++

czw., 4 mar 2021 o 16:04 Thomas Langé  napisał(a):

> Same for me, I'm available to share my knowledge and actively contribute
> to Mesos project.
>
> Thomas
> --
> *From:* Haijiang Chen 
> *Sent:* Thursday, 4 March 2021 16:01
> *To:* user@mesos.apache.org 
> *Cc:* mesos 
> *Subject:* [BULK]Re: [BULK]Call for active contributors
>
> I am willing to contribute to Mesos on windows based on my current
> experiences.
>
> - Haijiang
>
> On Thu, Mar 4, 2021 at 10:56 PM Grégoire Seux  wrote:
>
> Already answered to the other thread. I'm in.
>
> -- ​
> Grégoire
> --
> *From:* Qian Zhang 
> *Sent:* Thursday, March 4, 2021 3:38 PM
> *To:* mesos ; user 
> *Subject:* [BULK]Call for active contributors
>
> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a committer and PMC member in future.
>
>
> Regards,
> Qian Zhang
>
>

RE: mesos docs / tutorials

[Marc]

Hi Andrei, 

If you have still some old video's or other stuff at d2iq that could help new 
users, I would not mind hosting them, or maybe put them on youtube. If indeed 
mesos continues to stumble on for a while, it is nice to assist new users to 
easily get started to try and build a more active community.


> -Original Message-
> Sent: 04 March 2021 16:38
> To: user 
> Subject: Re: mesos docs / tutorials
> 
> Hi Marc,
> IIUC, this link used to point to documentation of Mesosphere DC/OS
> (which is no longer actively developed by D2IQ), and contains no docs
> for Apache Mesos.
> 
> 
> Is this link (or any similar link) present somewhere on the Mesos
> website https://mesos.apache.org/ ?
> Somehow I cannot find anything like this by searching the website
> sources in the Apache Mesos repository.
> 

Re: mesos docs / tutorials

[Andrei Sekretenko]

Hi Marc,
IIUC, this link used to point to documentation of Mesosphere DC/OS (which
is no longer actively developed by D2IQ), and contains no docs for Apache
Mesos.

Is this link (or any similar link) present somewhere on the Mesos website
https://mesos.apache.org/ ?
Somehow I cannot find anything like this by searching the website sources
in the Apache Mesos repository.



On Wed, Mar 3, 2021 at 11:07 PM Marc  wrote:

>
> What is going to be done with the mesos docs like:
>  http://mesosphere.io/learn
>
>
>
>
>
>

-- 
--
Andrei Sekretenko

Re: [BULK]Re: [BULK]Call for active contributors

[Thomas Langé]

Same for me, I'm available to share my knowledge and actively contribute to 
Mesos project.

Thomas

From: Haijiang Chen 
Sent: Thursday, 4 March 2021 16:01
To: user@mesos.apache.org 
Cc: mesos 
Subject: [BULK]Re: [BULK]Call for active contributors

I am willing to contribute to Mesos on windows based on my current experiences.

- Haijiang

On Thu, Mar 4, 2021 at 10:56 PM Grégoire Seux 
mailto:g.s...@criteo.com>> wrote:
Already answered to the other thread. I'm in.

-- ​
Grégoire

From: Qian Zhang mailto:zhq527...@gmail.com>>
Sent: Thursday, March 4, 2021 3:38 PM
To: mesos mailto:d...@mesos.apache.org>>; user 
mailto:user@mesos.apache.org>>
Subject: [BULK]Call for active contributors

Hi folks,

Please reply to this mail if you plan to actively contribute to Mesos and want 
to become a committer and PMC member in future.


Regards,
Qian Zhang

Re: [BULK]Call for active contributors

[Haijiang Chen]

I am willing to contribute to Mesos on windows based on my current
experiences.

- Haijiang

On Thu, Mar 4, 2021 at 10:56 PM Grégoire Seux  wrote:

> Already answered to the other thread. I'm in.
>
> -- ​
> Grégoire
> --
> *From:* Qian Zhang 
> *Sent:* Thursday, March 4, 2021 3:38 PM
> *To:* mesos ; user 
> *Subject:* [BULK]Call for active contributors
>
> Hi folks,
>
> Please reply to this mail if you plan to actively contribute to Mesos and
> want to become a committer and PMC member in future.
>
>
> Regards,
> Qian Zhang
>

Re: [BULK]Call for active contributors

[Grégoire Seux]

Already answered to the other thread. I'm in.

-- ​
Grégoire

From: Qian Zhang 
Sent: Thursday, March 4, 2021 3:38 PM
To: mesos ; user 
Subject: [BULK]Call for active contributors

Hi folks,

Please reply to this mail if you plan to actively contribute to Mesos and want 
to become a committer and PMC member in future.


Regards,
Qian Zhang

RE: no environment variables in standalone container

[Marc]

> 
> {
>   "type": "rbd.csi.ceph.io",
>   "uris": [
> { "value": "file:///usr/libexec/csi/config.json", "cache": false }
>   ],
>   "environment": {
> "variables": [
>   {"name":"CSI_DEFUSERID","type":"VALUE","value":""},
>   {"name":"CSI_DEFUSERKEY","type":"VALUE","value":""}
>   ]},
>   "containers": [
> {
>   "services": [ "NODE_SERVICE" ],
>   "command": {
 
should be here

> "value": "/usr/libexec/csi/csiceph -endpoint $CSI_ENDPOINT -
> nodeid $HOSTNAME -type rbd -drivername ceph-csi-rbd -v 10 -
> log_file=./csiceph-plugin.log -logtostderr=false"
>   },
>   "resources": [
> {"name": "cpus", "type": "SCALAR", "scalar": {"value": 0.1}},
> {"name": "mem", "type": "SCALAR", "scalar": {"value": 256}},
> {"name": "disk", "type": "SCALAR", "scalar": {"value": 10}}
>   ]
> }
>   ]
> }