Re: Maybe new feature/option for the health check

[Tomek Janiszewski]

It there but with different name:

   - delay_seconds is the amount of time to wait until starting health
   checking the task
   - grace_period_seconds is the amount of time after the task is launched
   during which health check failures are ignored. Once a health check
   succeeds for the first time, the grace period does not apply anymore. Note
   that it includes delay_seconds, i.e., setting grace_period_seconds <
   delay_seconds has no effect

http://mesos.apache.org/documentation/latest/health-checks/#common-options-1

pon., 30 wrz 2019, 22:46 użytkownik Marc Roos 
napisał:

>
> I have a few tasks that take a while before they get started. Sendmail
> eg. Is not to happy you cannot set the hostname (in marathon) and then
> gives a timeout of 1 minute. I think there is something similar when
> starting openldap. If I enable a regular health check there, it will
> fail the task before it finished launching. Maybe it is interesting to
> add an option for this initDelay?
>
>
> {
>   "path": "/api/health",
>   "portIndex": 0,
>   "protocol": "MESOS_HTTP",
>   "initDelay": 60,  <
>   "gracePeriodSeconds": 300,
>   "intervalSeconds": 60,
>   "timeoutSeconds": 20,
>   "maxConsecutiveFailures": 3
> }
>
>

Re: reservations from terminated frameworks

[Benjamin Mahler]

Hi Hendrik, currently reservations are tied to a role, not framework. In
this case, it's a static reservation which means you need to update the
agent configuration and restart it destructively (we don't currently
support a non-destructive non-additive agent resources change). If it was a
dynamic reservation, you could send an unreserve operation to the master
instead.

On Fri, Sep 27, 2019 at 11:50 AM Hendrik Haddorp 
wrote:

> Hi,
>
> I have a custom framework running on Mesos 1.8 using static reservation
> so that resources are reserved for a specific role. For some time I had
> two instances of my framework running, each using its own principal.
> Each instance reserved resources and created persistent volumes. Then I
> terminated one of the frameworks. But in the resource offers I get for
> the still running instance I still see reservations done by the
> principal of the now terminated framework. Why is that and how can get
> rid of those resources?
>
> thanks,
> Hendrik
>

Maybe new feature/option for the health check

[Marc Roos]

I have a few tasks that take a while before they get started. Sendmail 
eg. Is not to happy you cannot set the hostname (in marathon) and then 
gives a timeout of 1 minute. I think there is something similar when 
starting openldap. If I enable a regular health check there, it will 
fail the task before it finished launching. Maybe it is interesting to 
add an option for this initDelay?


{
  "path": "/api/health",
  "portIndex": 0,
  "protocol": "MESOS_HTTP",
  "initDelay": 60,  < 
  "gracePeriodSeconds": 300,
  "intervalSeconds": 60,
  "timeoutSeconds": 20,
  "maxConsecutiveFailures": 3
}

RFC: Extending supported RESERVE operations

[Benjamin Bannier]

Hi,

Mesos currently puts a number of restrictions on what a RESERVE operation can 
do (e.g., add only one refinement; no support to change a resource 
reservations) which implies restrictions elsewhere, e.g., on persistent 
volumes. In order to make reservations more flexible we came up with a design 
to support "re-reserving” (modifying a resource’s reservation role) which also 
seems to enable a number of other use cases.

The current design doc is 
https://docs.google.com/document/d/1LFh0OkOEHslmK6xqok1fCn2MOqGefvNodusOOnV66Q4/.


Cheers,

Benjamin