Hi folks,
One question about mesos authentication and authorization.
Where could I store the credentials? In documentation, it seems the credentials
is stored in local disk.
Is there any other approach to store and manage credentials via LDAP or other
3rd party software?
Thanks,
Jared,
>
> So one thing that was brought up during offline conversations was that if
> the host reboot is associated with hardware change (e.g., a new memory
> stick):
>- With the change: the agent could run into incompatible agent info
>due to resource change and flap
>
>
I think we should look into adopting "-fvisibility=hidden" and
explicitly annotating the symbols that we want to export:
https://issues.apache.org/jira/browse/MESOS-6734
Although I agree this isn't a trivial change and it would be good to
have some tool support here, but there are lots of
There are a significant number of developer and runtime performance
benefits from turning this flag on.
In my opinion it is also a dangerous flag to turn on by default without a
strict set of rules for our codebase to ensure that we don't accidentally:
- have multiple instances of static
On Mon, Dec 12, 2016 at 1:32 PM, Joris Van Remoortere
wrote:
> It sounds like using a multi_hashmap for now allows you to clean up the
> code and avoid some bugs, without changing the existing behavior.
Because we want cache-like behavior (bounded size + LRU replacement),
It sounds like using a multi_hashmap for now allows you to clean up the
code and avoid some bugs, without changing the existing behavior.
I agree that we would want a deprecation period if we changed the behavior.
It would also be unfortunate if we said we were dis-allowing duplicate task
ids but
Hi Joris,
Fair point: I didn't deliberately set out to change the behavior for
duplicate task IDs. Rather, it was a consequence of switching from
boost::circular_buffer to using a hashmap for managing completed
tasks. Using a hashmap has a few minor advantages [1], but we can
certainly continue
It there any information that kill is the result of failed healthcheck?
TaskHealthStatus should have some details on what was wrong. When default
executor is killing task it should add a reason and details to TaskStatus.
What do you think?
pon., 12.12.2016 o 11:11 użytkownik Alex Rukletsov
Technically the task hast not failed but was killed by the executor
(because it failed a health check).
On Fri, Dec 9, 2016 at 11:27 AM, Tomek Janiszewski
wrote:
> Hi
>
> What is desired behavior when command health check failed? On Mesos 1.0.2
> when health check fails task