You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Greg Mann <gr...@mesosphere.io> on 2016/05/24 05:23:50 UTC
Persistent Volume API Change
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
Re: Persistent Volume API Change
Posted by Zhitao Li <zh...@gmail.com>.
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 <gr...@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
Re: Persistent Volume API Change
Posted by Zhitao Li <zh...@gmail.com>.
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 <gr...@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