marathon bug(?)

[Marc <Ma...@f1-outsourcing.eu>]

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: marathon bug(?)

[Charles-François Natali <cf...@gmail.com>]

On Tue, 29 Jun 2021, 08:42 Marc, <Ma...@f1-outsourcing.eu> wrote:

> >
> > Accounts don't die but communities do - giving anyone control of
> > accounts won't magically revive them.
>
> From what I have read here, there are still thousands of nodes running
> mesos. So I think d2iq would welcome any request that would stretch any
> kind of transition period. It would just look bad for any new client they
> get, if d2iq has a bad reputation for dumping support/products without any
> warning or appropriate migration solution. Don't you agree?
>


I agree it would look bad, but it's exactly what's happened.
Just look at the repositories, they haven't been updated this year. The
only commits in Mesos this year have been from non D2iQ employees.
Worse than that, following their press release that they were deprecating
the Mesos stack, they didn't even bother communicating with the community,
try to coordinate for a potential community take over, etc. Or even update
the project website.

The only reason the discussion on the future of Mesos started is because I
previously emailed the then PMC chair - who was a D2iQ employee - to ask
what they were planning.
At the time I even said the company I work for would be willing to take
some support contract but it didn't seem to be interesting.

So I really wouldn't expect anything since D2iQ - the company - had
seemingly lost all interest in Mesos. Which is fine from a business point
of view, but the community and project management were just terrible.

Note that I'm specifically talking about D2iQ the company, not individual
employees, some of which are doing their best to help keep us going forward.

Cheers,




> > Also, from a diversification point of view having a single person in
> > charge of all these is probably a bad idea -
>
> As opposed to having no control at all?
>
> > lack of diversification of probably one of the factors behind Mesos
> failure.
>
> I do not see mesos as a failure. I think if there was any failure, it has
> been more related to mesosphere/d2iq business strategy.
> Eg. I still think it is a bit 'dumb' to offer this DCOS as a binary blob.
> The trend is that businesses want to have guaranteed stable environments
> and OS stability is not a core business of software developers.
>
> > Really, you'd be better off moving on :).
> >
>
> I agree but that is a different discussion.
>
> So question still stands: Anyone on this list knows who is in control of
> the current source repositories?
>
>
>

RE: marathon bug(?)

[Marc <Ma...@f1-outsourcing.eu>]

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

From what I have read here, there are still thousands of nodes running mesos. So I think d2iq would welcome any request that would stretch any kind of transition period. It would just look bad for any new client they get, if d2iq has a bad reputation for dumping support/products without any warning or appropriate migration solution. Don't you agree?

> Also, from a diversification point of view having a single person in
> charge of all these is probably a bad idea - 

As opposed to having no control at all? 

> lack of diversification of probably one of the factors behind Mesos failure.

I do not see mesos as a failure. I think if there was any failure, it has been more related to mesosphere/d2iq business strategy. 
Eg. I still think it is a bit 'dumb' to offer this DCOS as a binary blob. The trend is that businesses want to have guaranteed stable environments and OS stability is not a core business of software developers. 

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

I agree but that is a different discussion. 

So question still stands: Anyone on this list knows who is in control of the current source repositories?

Re: marathon bug(?)

[Charles-François Natali <cf...@gmail.com>]

On Mon, 28 Jun 2021, 20:41 Marc, <Ma...@f1-outsourcing.eu> 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 <Ma...@f1-outsourcing.eu>]

> 	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(?)

[Charles-François Natali <cf...@gmail.com>]

On Mon, 28 Jun 2021, 13:46 Marc, <Ma...@f1-outsourcing.eu> wrote:

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

RE: marathon bug(?)

[Marc <Ma...@f1-outsourcing.eu>]

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

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?

Re: marathon bug(?)

[Qian Zhang <zh...@gmail.com>]

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 <Ma...@f1-outsourcing.eu> 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)
>
>
>