Got it, thanks Michael.
Regards,
Qian Zhang (张乾)
Developer, IBM Platform Computing
Phone: 86-29-68797144 | Tie-Line: 87144
IBM
E-mail: [email protected]
Chat: zhq527725 陕西省西安市高新区
高新六路42号中清大
厦3层
“An educated man should know everything about Xian,
Shaanxi
something and something about everything" Province
710075
China
From: Michael Park <[email protected]>
To: [email protected]
Date: 09/01/2015 11:21
Subject: Re: Is dynamic reservation per role or per framework
Persistent volume is indeed also per role, however that's not explicit.
What I mean is that because persistent volume can only be created on
reserved resources, it happens to inherit whatever characteristics
reservations have.
Suppose we were to change dynamic reservation to be per-framework.
Persistent volumes created on dynamic reservations would be per-framework
at that point, but the ones created on static reservations would still be
per-role. So rather than persistent volumes explicitly being per-role, it's
an artifact of the fact that all reservations currently are per-role.
If the ACL is set up correctly, then yes, the other framework would not be
able to destroy it.
On Sun, Aug 30, 2015 at 8:22 PM Qian AZ Zhang <[email protected]> wrote:
> Thanks Michael for the detailed clarification, it is much clear to me now
> :-)
>
> And I have a further question regarding persistent volume: I think,
> similar with dynamic reservation, persistent volume is also per role now,
> so that means a persistent volume created by a framework can be offered
to
> another framework in the same role, right? I assume the other framework
can
> not destroy the persistent volume due to ACL.
>
>
> Regards,
> *Qian Zhang (张乾)*
> Developer, IBM Platform Computing
> ------------------------------
> *Phone:* 86-29-68797144 | *Tie-Line:* 87144
> * E-mail:* *[email protected]* <[email protected]>
> * Chat:* zhq527725
>
> *“An educated man should know everything about something and something
> about everything"*
> [image: IBM]
>
> 陕西省西安市高新区
> 高新六路42号中清大厦3层
> Xian, Shaanxi Province 710075
> China
>
>
>
> [image: Inactive hide details for Michael Park ---08/31/2015
> 03:58:25---Hello Qian, Yes, dynamic reservation (at least currently) is
pe]Michael
> Park ---08/31/2015 03:58:25---Hello Qian, Yes, dynamic reservation (at
> least currently) is per role, rather than the
>
> From: Michael Park <[email protected]>
> To: [email protected]
> Date: 08/31/2015 03:58
> Subject: Re: Is dynamic reservation per role or per framework
> ------------------------------
>
>
>
>
> Hello Qian,
>
> Yes, dynamic reservation (at least currently) is per role, rather than
the
> framework level. The main motivation for such a design was based on the
> following thought: "dynamic reservation should simply be a dynamic
version
> of the existing static reservation."
>
> You're absolutely right that if multiple frameworks are in the same role,
> the resources reserved for that role can be offered to any of the
> frameworks in that role. The justification for this behavior is that:
> that's what happens if we were to statically reserve resources for a
role,
> and have multiple frameworks in it anyway. If a framework requires sole
> ownership of the resources, the operator is required to create a role for
> that framework only.
>
> Having said that, I've argued for per-framework reservation. The obvious
> benefits are that (1) no need to worry about resources potentially being
> shared, (2) no need for operators to set up the ACLs to enforce sole
> ownership of resources, etc. An implied benefit is that Mesos can
> automatically unreserve the resources reserved by the framework if the
> framework leaves and exceeds its reregistration_timeout.
>
> I still believe the per-framework reservation makes more sense, and as
long
> as there's enough interest for them, we'll get to work on it as
follow-up,
> post-MVP work.
>
> Thanks,
>
> MPark.
>
> On Sun, Aug 30, 2015 at 9:35 AM Qian AZ Zhang <[email protected]>
wrote:
>
> >
> >
> > Hi,
> >
> > I took a look at dynamic reservation design doc and the related code in
> > Mesos master, it seem dynamic reservation works in role level rather
than
> > in framework level, that means a framework can only reserve some
> resources
> > for its role rather than itself. If so, then I am thinking about this
> case:
> > both Cassandra framework and HDFS framework belongs to role1, and HDFS
> > dynamically reserves some resources in a slave for role1, then I think
it
> > may be possible for allocator to offer those resources to Cassandra
since
> > it also belongs to role1, but actually HDFS expects to be offered with
> > those resources to launch its tasks.
> >
> > Please anyone correct me if my understanding above was wrong, thanks!
> >
> >
> > Regards,
> > Qian Zhang
>
>