Re: Proposing change to the allocatable check in the allocator

[Jie Yu]

I would suggest we also consider the possibility of adding per framework
control on `min_allocatable_resources`.

If we want to consider supporting per-framework setting, we should probably
model this as a protobuf, rather than a free form JSON. The same protobuf
can be reused for both master flag, framework API, or even supporting
Resource Request in the future. Something like the following:

message ResourceQuantityPredicate {
  enum Type {
SCALAR_GE,
  }
  optional Type type;
  optional Value.Scalar scalar;
}
message ResourceRequirement {
  required string resource_name;
  oneof predicates {
ResourceQuantityPredicate quantity;
  }
}
message ResourceRequirementList {
  // All requirements MUST be met.
  repeated ResourceRequirement requirements;
}

// Resource request API.
message Request {
  repeated ResoruceRequrementList accepted;
}

// `allocatable()`
message MinimalAllocatableResources {
  repeated ResoruceRequrementList accepted;
}

On Mon, Jun 11, 2018 at 3:47 PM, Meng Zhu  wrote:

> Hi:
>
> The allocatable
> 
>  check in the allocator (shown below) was originally introduced to
>
> help alleviate the situation where a framework receives some resources,
> but no
>
> cpu/memory, thus cannot launch a task.
>
>
> constexpr double MIN_CPUS = 0.01;constexpr Bytes MIN_MEM = Megabytes(32);
> bool HierarchicalAllocatorProcess::allocatable(
> const Resources& resources)
> {
>   Option cpus = resources.cpus();
>   Option mem = resources.mem();
>
>   return (cpus.isSome() && cpus.get() >= MIN_CPUS) ||
>  (mem.isSome() && mem.get() >= MIN_MEM);
> }
>
>
> Issues
>
> However, there has been a couple of issues surfacing lately surrounding
> the check.
>
>-
>- - MESOS-8935 Quota limit "chopping" can lead to cpu-only and
>memory-only offers.
>
> We introduced fined-grained quota-allocation (MESOS-7099) in Mesos 1.5.
> When we
>
> allocate resources to a role, we'll "chop" the available resources of the
> agent up to the
>
> quota limit for the role. However, this has the unintended consequence of
> creating
>
> cpu-only and memory-only offers, even though there might be other agents
> with both
>
> cpu and memory resources available in the cluster.
>
>
> - MESOS-8626 The 'allocatable' check in the allocator is problematic with
> multi-role frameworks.
>
> Consider roleA reserved cpu/memory on an agent and roleB reserved disk on
> the same agent.
>
> A framework under both roleA and roleB will not be able to get the
> reserved disk due to the
>
> allocatable check. With the introduction of resource providers, the
> similar situation will
>
> become more common.
>
> Proposed change
>
> Instead of hardcoding a one-size-fits-all value in Mesos, we are proposing
> to add a new master flag
>
> min_allocatable_resources. It specifies one or more scalar resources
> quantities that define the
>
> minimum allocatable resources for the allocator. The allocator will only
> offer resources that are more
>
> than at least one of the specified resources.  The default behavior *is
> backward compatible* i.e.
>
> by default, the flag is set to “cpus:0.01|mem:32”.
>
> Usage
>
> The flag takes in either a simple text of resource(s) delimited by a bar
> (|) or a JSON array of JSON
>
> formatted resources. Note, the input should be “pure” scalar quantities
> i.e. the specified resource(s)
>
> should only have name, type (set to scalar) and scalar fields set.
>
>
> Examples:
>
>- - To eliminate cpu or memory only offer due to the quota chopping,
>- we could set the flag to “cpus:0.01;mem:32”
>-
>- - To enable offering disk only offer, we could set the flag to
>“disk:32”
>-
>- - For both, we could set the flag to “cpus:0.01;mem:32|disk:32”.
>- Then the allocator will only offer resources that at least contain
>“cpus:0.01;mem:32”
>- OR resources that at least contain “disk:32”.
>
>
> Let me know what you think! Thanks!
>
>
> -Meng
>
>

[Design Doc] External Resource Provider and CSI

[Chun-Hung Hsiao]

Folks,

As a natural extension to prior work [1, 2] to improve storage support in
Mesos,
I'm working on the general design of external resource providers,
and the specific design for external storage support through CSI [3].
The goal is to enable Mesos to manage cluster-wide resources such as EBS
volumes
and offer them to frameworks.

Please find the design doc through the following link:
https://docs.google.com/document/d/1c4allCaldqBOLlKzzgQiurvhqmPe59qqYswjtf4gf1s/edit?usp=sharing

We'll also discuss the design in tomorrow's API working group.
Thanks for your time to review and provide feedbacks for the design!

Best,
Chun-Hung

[1]
https://docs.google.com/document/d/125YWqg_5BB5OY9a6M7LZcby5RSqBwo2PZzpVLuxYXh4/edit?usp=sharing
[2]
https://docs.google.com/document/d/1D4a-GNON8PCSIUx3pVoZXg1dUB_50ZAIlDFSnZ3xx6I/edit?usp=sharing
[3] https://github.com/container-storage-interface/spec

Proposing change to the allocatable check in the allocator

[Meng Zhu]

Hi:

The allocatable

 check in the allocator (shown below) was originally introduced to

help alleviate the situation where a framework receives some resources, but
no

cpu/memory, thus cannot launch a task.


constexpr double MIN_CPUS = 0.01;constexpr Bytes MIN_MEM = Megabytes(32);
bool HierarchicalAllocatorProcess::allocatable(
const Resources& resources)
{
  Option cpus = resources.cpus();
  Option mem = resources.mem();

  return (cpus.isSome() && cpus.get() >= MIN_CPUS) ||
 (mem.isSome() && mem.get() >= MIN_MEM);
}


Issues

However, there has been a couple of issues surfacing lately surrounding the
check.

   -
   - - MESOS-8935 Quota limit "chopping" can lead to cpu-only and
   memory-only offers.

We introduced fined-grained quota-allocation (MESOS-7099) in Mesos 1.5.
When we

allocate resources to a role, we'll "chop" the available resources of the
agent up to the

quota limit for the role. However, this has the unintended consequence of
creating

cpu-only and memory-only offers, even though there might be other agents
with both

cpu and memory resources available in the cluster.


- MESOS-8626 The 'allocatable' check in the allocator is problematic with
multi-role frameworks.

Consider roleA reserved cpu/memory on an agent and roleB reserved disk on
the same agent.

A framework under both roleA and roleB will not be able to get the reserved
disk due to the

allocatable check. With the introduction of resource providers, the similar
situation will

become more common.

Proposed change

Instead of hardcoding a one-size-fits-all value in Mesos, we are proposing
to add a new master flag

min_allocatable_resources. It specifies one or more scalar resources
quantities that define the

minimum allocatable resources for the allocator. The allocator will only
offer resources that are more

than at least one of the specified resources.  The default behavior *is
backward compatible* i.e.

by default, the flag is set to “cpus:0.01|mem:32”.

Usage

The flag takes in either a simple text of resource(s) delimited by a bar
(|) or a JSON array of JSON

formatted resources. Note, the input should be “pure” scalar quantities
i.e. the specified resource(s)

should only have name, type (set to scalar) and scalar fields set.


Examples:

   - - To eliminate cpu or memory only offer due to the quota chopping,
   - we could set the flag to “cpus:0.01;mem:32”
   -
   - - To enable offering disk only offer, we could set the flag to
   “disk:32”
   -
   - - For both, we could set the flag to “cpus:0.01;mem:32|disk:32”.
   - Then the allocator will only offer resources that at least contain
   “cpus:0.01;mem:32”
   - OR resources that at least contain “disk:32”.


Let me know what you think! Thanks!


-Meng

Re: Follow up on instructions on CMake and VSCode support

[James Peach]

> On Jun 11, 2018, at 1:24 PM, Andrew Schwartzmeyer  
> wrote:
> 
> Ah, so with VS Code it's _mostly_ automatic; I don't actually use VS
> Code much myself, though Akash does.
> 
> I have a review up here https://reviews.apache.org/r/67308/ that goes
> over setting up and using Cquery (which is _also_ used by VS Code, but
> in the background) with Emacs, and was hoping to get someone who uses it
> with Vim to fill that in too. Really it should add support for any
> editor which supports LSP.

FWIW I had pretty good luck with a .cquery file:
http://jorgar.tumblr.com/post/174319627674/mesos-config-for-cquery


> On 06/11/2018 1:17 pm, Zhitao Li wrote: 
> 
>> Hi Andrew, 
>> 
>> I remembered that you gave an pretty exciting talk about setting up CMake 
>> and VSCode to parse Mesos code base. I'm quite curious on setting that up 
>> myself. 
>> 
>> Can you share any instructions/notes about that? 
>> 
>> Thanks!
>> 
>> -- 
>> 
>> Cheers,
>> 
>> Zhitao Li

Re: Follow up on instructions on CMake and VSCode support

[Andrew Schwartzmeyer]

 Ah, so with VS Code it's _mostly_ automatic; I don't actually use VS
Code much myself, though Akash does.

I have a review up here https://reviews.apache.org/r/67308/ that goes
over setting up and using Cquery (which is _also_ used by VS Code, but
in the background) with Emacs, and was hoping to get someone who uses it
with Vim to fill that in too. Really it should add support for any
editor which supports LSP.

On 06/11/2018 1:17 pm, Zhitao Li wrote: 

> Hi Andrew, 
> 
> I remembered that you gave an pretty exciting talk about setting up CMake and 
> VSCode to parse Mesos code base. I'm quite curious on setting that up myself. 
> 
> Can you share any instructions/notes about that? 
> 
> Thanks!
> 
> -- 
> 
> Cheers,
> 
> Zhitao Li
 

Follow up on instructions on CMake and VSCode support

[Zhitao Li]

Hi Andrew,

I remembered that you gave an pretty exciting talk about setting up CMake
and VSCode to parse Mesos code base. I'm quite curious on setting that up
myself.

Can you share any instructions/notes about that?

Thanks!

-- 
Cheers,

Zhitao Li

[GitHub] mesos pull request #296: Add xiao wei.

[sharego]

Github user sharego commented on a diff in the pull request:

https://github.com/apache/mesos/pull/296#discussion_r194521400
  
--- Diff: docs/contributors.yaml ---
@@ -825,3 +825,11 @@
 - xingz...@cn.ibm.com
   jira_user: dongdong
   reviewboard_user: dongdong
+
+- name: xiao wei
--- End diff --

ok, get it


---

[GitHub] mesos pull request #296: Add xiao wei.

[jieyu]

Github user jieyu commented on a diff in the pull request:

https://github.com/apache/mesos/pull/296#discussion_r194518563
  
--- Diff: docs/contributors.yaml ---
@@ -825,3 +825,11 @@
 - xingz...@cn.ibm.com
   jira_user: dongdong
   reviewboard_user: dongdong
+
+- name: xiao wei
--- End diff --

Can you sort based on first name?


---

[GitHub] mesos pull request #296: Add xiao wei.

[sharego]

GitHub user sharego opened a pull request:

https://github.com/apache/mesos/pull/296

Add xiao wei.

Add xiao wei

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sharego/mesos xiaowei

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/296.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #296


commit 859a2081fd78ae1dd9268e06b23d4b5044e90dc1
Author: xiaowei 
Date:   2018-06-11T18:43:29Z

Add xiao wei.




---