mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhitao Li <zhitaoli...@gmail.com>
Subject Re: Persistent Volume API Change
Date Tue, 24 May 2016 15:58:30 GMT
I'd vote for fixing the bug directly w/o a deprecation period, because a
framework is always supposed to registered with proper principal to perform
various operations.

As long as we clearly document this in upgrade.md, operators should be able
to properly fix their framework usage and ACL, before they upgrade to a
version including this change, and behavior observed should not change.

On Mon, May 23, 2016 at 10:23 PM, Greg Mann <greg@mesosphere.io> wrote:

> Hello all,
> I'm currently working on MESOS-5005
> <https://issues.apache.org/jira/browse/MESOS-5005>, which is fixing a
> small bug in the persistent volumes API. When a new persistent volume is
> created, a `DiskInfo` message is included in the disk resources of the
> volume. Nested within another message in `DiskInfo`, there is a
> `principal`
> <https://github.com/apache/mesos/blob/master/include/mesos/mesos.proto#L713>
> field which is meant to contain the principal of the framework or operator
> responsible for creating the volume. Correct authorization of Destroy
> operations depends on the value of this `principal` field, so the
> correctness of its value should be enforced.
>
> Up until now, we have not been performing a validation check to ensure
> that the principal contained in `DiskInfo` is equal to the framework or
> operator's principal. I've prepared patches
> <https://reviews.apache.org/r/47515/> which enforce this constraint, and
> I wanted to check here on the mailing lists to see if the community thinks
> we need a deprecation period for these changes. Merging these changes would
> prevent frameworks from creating persistent volumes if they do not
> correctly set the `principal` field, which they have previously been
> permitted to omit. So, it has the potential to break frameworks. However,
> these patches are also necessary to ensure the correctness of Destroy
> operation authorization, and the lack of a check on the `principal` field
> is a bug that should be fixed. It would be great to hear from people who
> are running and/or writing frameworks that make use of persistent volumes,
> to see if those frameworks are setting this field properly.
>
> Thoughts?
>
> Cheers,
> Greg
>



-- 
Cheers,

Zhitao Li

Mime
View raw message