[GitHub] mesos pull request #228: Adds port mapping information in NetworkInfo as par...

Github user GoelDeepak closed the pull request at: https://github.com/apache/mesos/pull/228 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is e

Re: [Containerization WG] Meeting tomorrow

Information about how to join the meeting can be found here: https://docs.google.com/document/d/1z55a7tLZFoRWVuUxz1FZwgxkHeugtc2nHR89skFXSpU/edit?usp=sharing - Jie On Wed, Aug 23, 2017 at 3:16 PM, Jie Yu wrote: > Hi, > > We'll hold the regular WG meeting tomorrow morning (9am PDT). Here is the

[Containerization WG] Meeting tomorrow

Hi, We'll hold the regular WG meeting tomorrow morning (9am PDT). Here is the tentative agenda for the sync: [Joseph] Standalone container design review https://docs.google.com/document/d/1DZVfZAOLtqd8kbiWHD4j29LzaYcNC h1k6QQnbggyTio/edit#heading=h.djaqtpndp41e [James] Network ports isolator htt

Re: Sending TASK_STARTING in the built-in executors

+1 for the change. On Wed, Aug 23, 2017 at 8:58 AM, Benno Evers wrote: > I think it's ultimately up to the executor to interpret what "running" > means exactly. The closest thing to a general definition would probably be > this from docs/high-availability-framework.md: > > > A task transitions t

Re: Offer operation reconciliation discussion notes

Please can the "reason" be the reason for the failure and NOT the reason the message was sent, e.g. "RECONCILIATION" On Wed, Aug 23, 2017 at 1:58 PM Yan Xu wrote: > Yeah a reason for failed operations is probably useful for all resource > operations. It looks like the task-style status update is

[GitHub] mesos pull request #228: Adds port mapping information in NetworkInfo as par...

GitHub user GoelDeepak opened a pull request: https://github.com/apache/mesos/pull/228 Adds port mapping information in NetworkInfo as part of `state` output. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mesosphere/mesos fix_p

Re: Offer operation reconciliation discussion notes

Yeah a reason for failed operations is probably useful for all resource operations. It looks like the task-style status update is still the best approach. --- @xujyan On Wed, Aug 23, 2017 at 11:40 AM, Jie Yu wrote: > We should continue the discussion here: > > I thi

Re: Offer operation reconciliation discussion notes

We should continue the discussion here: I think I forgot to mention one important reason that I went for the operation based reconciliation API proposal. For new operations like CREATE_VOLUME/CREATE_BLOCK, not only we need to know the end result (the resources) if it's successful, we also need to

Offer operation reconciliation discussion notes

Hi, We had a discussion on some very early proposal (see the attached slides) on providing feedback for offer operations (e.g., CREATE/DESTORY, RESERVE/UNRESERVE, etc.) with a bunch of folks from the community. Here are the notes I captured in the meeting: - One alternative approach discussed

RE: [Proposal] Use jemalloc as default memory allocator for Mesos

Hi Benno, What's the availability of both jemalloc and tcmalloc on the Windows platform? Do the products work there properly? There are solutions that I know work on Windows (from past work I've done). I'm unsure about either jemalloc and tcmalloc, however. Thanks, /Jeff -Original Messag

Re: Sending TASK_STARTING in the built-in executors

I think it's ultimately up to the executor to interpret what "running" means exactly. The closest thing to a general definition would probably be this from docs/high-availability-framework.md: > A task transitions to the `TASK_RUNNING` state after it has begun running > successfully (if the task f

Re: Sending TASK_STARTING in the built-in executors

> On Aug 23, 2017, at 2:38 AM, Benno Evers wrote: > > Hi all, > > when starting a task, an executor can send out the following status updates: > > - [optional] TASK_STARTING: Sent by the executor when it received the > launch command > - TASK_RUNNING: Sent by the executor when the task is ru

Sending TASK_STARTING in the built-in executors

Hi all, when starting a task, an executor can send out the following status updates: - [optional] TASK_STARTING: Sent by the executor when it received the launch command - TASK_RUNNING: Sent by the executor when the task is running The built-in executors currently don't send out TASK_STARTIN