You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@mesos.apache.org by John Omernik <jo...@omernik.com> on 2015/12/11 16:34:56 UTC

Dynamic Reservations and --roles

I am following http://mesos.apache.org/documentation/latest/reservation/ to
learn how to do dynamic reservations.  I don't want to statically assign
roles, therefore, I started my slaves only with the (*) resources.

I used the HTTP endpoints to reserve some resources.  And it returned
successful. In addition, I've checked the /slaves endpoint and indeed the
resources are allocated.

Now when I try to uses those roles, I get an error:

sched.cpp:1024] Got error 'Role 'dev' is not present in the master's
--roles'

Ok, so looking I indeed likely need to specify --roles at startup of
master.  This got me thinking, is this an oversight or by design?  If it's
an oversight, then I will file a JIRA, if by designed, I'd like to
understand more.

What I mean is this: The whole point of /reserver /unreserve is not have to
specify the resources at slave startup.  That's great.  Then when I
reserver or unreserve, from how I understand it one of two things should
happen (This is where I need feedback)

1. If the role specified in the reserve/unreserve operation doesn't exist
in --roles on the master, it should reject the reservation on the /reserve
endpoint.  Why allow the reservation of roles if you can't use them if they
are specified

2. If the role doesn't exist in --roles, and a reservation comes through,
it should be added dynamically. This seems to make more sense to me. I.e.
adding roles doesn't require a master restart.

If there is a 3rd option here, that I am not seeing, please let me know,
otherwise I will file a JIRA to this...

John

回复： Dynamic Reservations and --roles

Posted by GradyWang <gr...@foxmail.com>.

MESOS-4144 is duplicated by MESOS-3177(Dynamic Roles/Weights), you can refer to the design doc(https://docs.google.com/document/d/1OIgceqpsjV3-_LGF83IMAFnrh1Ea3Zc16w9kWWPpUj4/edit#heading=h.b0rurfixb4wg) for the details.

------------------
Regards!
Grady YQ. Wang（王勇桥）

------------------ 原始邮件 ------------------
发件人: "John Omernik";<jo...@omernik.com>;
发送时间: 2015年12月14日(星期一) 凌晨2:30
收件人: "user@mesos.apache.org"<us...@mesos.apache.org>;

主题: Re: Dynamic Reservations and --roles

I filed https://issues.apache.org/jira/browse/MESOS-4143 to address the reserve unreserve endpoints reserving roles for non-explicit rules.

I also opened https://issues.apache.org/jira/browse/MESOS-4144 to add the ability to add roles dynamically based on an API request to properly authorized principals.

Thanks!

John

On Sat, Dec 12, 2015 at 1:40 AM, Michael Park <mp...@apache.org> wrote:
This seems like a bug to me. Please file a JIRA ticket and I'll sync with Neil regarding what the behavior should be with dynamic/implicit roles in mind.

Thanks!

MPark.

On Fri, Dec 11, 2015 at 1:32 PM Vinod Kone <vi...@apache.org> wrote:

1. If the role specified in the reserve/unreserve operation doesn't exist in --roles on the master, it should reject the reservation on the /reserve endpoint. Why allow the reservation of roles if you can't use them if they are specified

2. If the role doesn't exist in --roles, and a reservation comes through, it should be added dynamically. This seems to make more sense to me. I.e. adding roles doesn't require a master restart.

There is currently work in progress to add support for implicit roles (roles not specified via --roles). But, I agree that until we add that feature the /reserve endpoint should reject reservations for unknown roles. Not sure what the rationale was to allow this. @mpark?

回复： Dynamic Reservations and --roles

Posted by GradyWang <gr...@foxmail.com>.

------------------
Regards!
Grady YQ. Wang（王勇桥）
----------------------------------------------------------------------
Software Engineer Of IBM Platform Computing
E-mail: grady.wang@foxmail.com
Mobile: +86-18182636286
WeChat ID: gradyYQwang
Address: 3/F,No.42 GAO XIN LIU ROAD,Xian,Shanxi 710075 China
If you can control yourself, then you can control everything.
----------------------------------------------------------------------

主题: Re: Dynamic Reservations and --roles

I filed https://issues.apache.org/jira/browse/MESOS-4143 to address the reserve unreserve endpoints reserving roles for non-explicit rules.

I also opened https://issues.apache.org/jira/browse/MESOS-4144 to add the ability to add roles dynamically based on an API request to properly authorized principals.

Thanks!

John

Thanks!

MPark.

On Fri, Dec 11, 2015 at 1:32 PM Vinod Kone <vi...@apache.org> wrote:

2. If the role doesn't exist in --roles, and a reservation comes through, it should be added dynamically. This seems to make more sense to me. I.e. adding roles doesn't require a master restart.

Re: Dynamic Reservations and --roles

Posted by John Omernik <jo...@omernik.com>.

I filed https://issues.apache.org/jira/browse/MESOS-4143 to address the
reserve unreserve endpoints reserving roles for non-explicit rules.

I also opened https://issues.apache.org/jira/browse/MESOS-4144 to add the
ability to add roles dynamically based on an API request to properly
authorized principals.

Thanks!

John

On Sat, Dec 12, 2015 at 1:40 AM, Michael Park <mp...@apache.org> wrote:

> This seems like a bug to me. Please file a JIRA ticket and I'll sync with
> Neil regarding what the behavior should be with dynamic/implicit roles in
> mind.
>
> Thanks!
>
> MPark.
>
>
> On Fri, Dec 11, 2015 at 1:32 PM Vinod Kone <vi...@apache.org> wrote:
>
>>
>> 1. If the role specified in the reserve/unreserve operation doesn't exist
>>> in --roles on the master, it should reject the reservation on the /reserve
>>> endpoint.  Why allow the reservation of roles if you can't use them if they
>>> are specified
>>>
>>> 2. If the role doesn't exist in --roles, and a reservation comes
>>> through, it should be added dynamically. This seems to make more sense to
>>> me. I.e. adding roles doesn't require a master restart.
>>>
>>
>> There is currently work in progress to add support for implicit roles
>> (roles not specified via --roles). But, I agree that until we add that
>> feature the /reserve endpoint should reject reservations for unknown roles.
>> Not sure what the rationale was to allow this. @mpark?
>>
>>

Re: Dynamic Reservations and --roles

Posted by Michael Park <mp...@apache.org>.

This seems like a bug to me. Please file a JIRA ticket and I'll sync with
Neil regarding what the behavior should be with dynamic/implicit roles in
mind.

Thanks!

MPark.

On Fri, Dec 11, 2015 at 1:32 PM Vinod Kone <vi...@apache.org> wrote:

>
> 1. If the role specified in the reserve/unreserve operation doesn't exist
>> in --roles on the master, it should reject the reservation on the /reserve
>> endpoint.  Why allow the reservation of roles if you can't use them if they
>> are specified
>>
>> 2. If the role doesn't exist in --roles, and a reservation comes through,
>> it should be added dynamically. This seems to make more sense to me. I.e.
>> adding roles doesn't require a master restart.
>>
>
> There is currently work in progress to add support for implicit roles
> (roles not specified via --roles). But, I agree that until we add that
> feature the /reserve endpoint should reject reservations for unknown roles.
> Not sure what the rationale was to allow this. @mpark?
>
>

Re: Dynamic Reservations and --roles

Posted by Vinod Kone <vi...@apache.org>.

> 1. If the role specified in the reserve/unreserve operation doesn't exist
> in --roles on the master, it should reject the reservation on the /reserve
> endpoint.  Why allow the reservation of roles if you can't use them if they
> are specified
>
> 2. If the role doesn't exist in --roles, and a reservation comes through,
> it should be added dynamically. This seems to make more sense to me. I.e.
> adding roles doesn't require a master restart.
>

There is currently work in progress to add support for implicit roles
(roles not specified via --roles). But, I agree that until we add that
feature the /reserve endpoint should reject reservations for unknown roles.
Not sure what the rationale was to allow this. @mpark?