Re: Question on status update retry in agent

Do you have logs? Which acknowledgements did the agent receive? Which TASK_RUNNING in the sequence was it re-sending? On Tue, Apr 10, 2018 at 6:41 PM, Benjamin Mahler wrote: > > Issue is that, *old executor reference is hold by slave* (assuming it > did not receive

Re: Question on status update retry in agent

> Issue is that, *old executor reference is hold by slave* (assuming it did not receive acknowledgement, whereas master and scheduler have processed the status updates), so it continues to retry TASK_RUNNING infinitely. The agent only retries so long as it does not get an acknowledgement, is the

Re: Volume ownership and permission

Hi Marc, I have shared the design doc to ensure anyone (no sign-in required) with the link can comment, can you try again? Regards, Qian Zhang On Tue, Apr 10, 2018 at 1:04 PM, Marc Roos wrote: > > Cannot access it > > > > -Original Message- > From: Qian

Re: Proposal: Constrained upgrades from Mesos 1.6

-user Do you have a link to the technical details of why this needs to be done? For instance, why can't master/agent versions be used to determine which behavior is performed between the master and agent? On Tue, Apr 10, 2018 at 5:34 PM, Greg Mann wrote: > Hi all, > We are

Proposal: Constrained upgrades from Mesos 1.6

Hi all, We are currently working on patches to implement the new GROW_VOLUME and SHRINK_VOLUME operations [1]. In order to make it into Mesos 1.6, we're pursuing a workaround which affects the way these operations are accounted for in the Mesos master. These operations will be marked as

CHECK_NOTNONE / CHECK_NOTERROR

Just an FYI about some recently added CHECKs that make some minor changes to the way we write code: (1) CHECK_NOTNONE: Much like glog's CHECK_NOTNULL, sometimes you know from invariants that an Option cannot be in the none state and you want to "de-reference" it without writing logic to handle

Re: Tasks not getting killed

It's the executor's responsibility to forcefully kill a task after the task kill grace period. However, in your case it sounds like the executor is getting stuck? What is happening in the executor? If the executor is alive but doesn't implement the grace period force kill logic, the solution is to

Re: [GSoC] Google Summer of Code

Those suggestions look good to me, however I would strongly urge that they get improvements committed in an incremental way over the course of the 3 months rather than building a replacement to try to swap at the end. > The lack of recent contributions is, AFAIK, due to the complexity of Angular

Re: Release policy and 1.6 release schedule

Thanks for the reviews, y'all! I've got a few "Ship-Its" - I'll commit this later today unless I hear any objections. Cheers, Greg On Wed, Apr 4, 2018 at 11:49 AM, Greg Mann wrote: > Hey folks, > I've posted a proposed update to our documented release schedule: >

Update: Mesos 1.6.0 Release

Hey folks! I've created a dashboard for the Mesos 1.6.0 release here - take a look! Please ensure that you have set the 'Target Version' to 1.6.0 on all tickets which you intend to land in time for this release. I'm

Re: [GSoC] Google Summer of Code

Hi, I agree with submitting a project concerning the Mesos UI. For a 3 months programming project, I would suggest working on an updated UI offering a similar UX (Mesos users are not complaining about that) but with: - An updated Angular version or the use of a new framework (for our use case,

[GSoC] Google Summer of Code

Hi It looks like Apache Foundation was selected to Google Summer of Code https://summerofcode.withgoogle.com/organizations/5718432427802624/ Do we plan to submit any project related to Mesos. I was thinking about a project to refresh Mesos UI (catch up with features, upgrade to latest Angular (or

Volume ownership and permission

Hi Folks, I am working on MESOS-8767 to improve Mesos volume support regarding volume ownership and permission, here is the design doc . Please feel