mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 60563: Updated `validateAndUpgradeResources` to operate on `Operation`s.
Date Sat, 01 Jul 2017 19:45:33 GMT


> On June 30, 2017, 9:44 p.m., Benjamin Bannier wrote:
> > src/common/resources_utils.cpp
> > Line 199 (original), 199 (patched)
> > <https://reviews.apache.org/r/60563/diff/1/?file=1767519#file1767519line199>
> >
> >     It seems by unconditionally calling `mutable_xyz` for `repeated` fields `xyz`
below we might add default entries to them if they were empty before. AFAICTt this might not
be what callers of this function expect.
> 
> Michael Park wrote:
>     Hm... do you mean the `mutable_resources()` calls below? I don't understand how we
would be adding default entries. Could you be more specific?
> 
> Benjamin Bannier wrote:
>     Sorry, that comment was both confused/ing and put onto a too wide scope. The issue
is specifically in the handling of the `LAUNCH` and `LAUNCH_GROUP` cases. There we first perform
validation of resources attached to some `optional` field; this seems to handle absence of
the `optional` field fine (e.g., validation of a default (empty) `repeated` list of resources
is not an error), and we also do not set the `optional` field. We then iterate to mutate the
resources under the `optional` field; there we would always default-init the `optional` field
as a possibly unintended side-effect. AFAICT the behavior here is independent from whether
one uses proto2 or proto3, but that's just from experimentation.
>     
>     I think we should guard the mutating resource access with a check on whether their
`optional` parent message is set.
>     
>     Example:
>     
>         mesos::Operation operation;
>     
>         // Per default the field is not set.
>         assert(!operation.has_launch());
>     
>         // Accessing the unset `optional` field returns a default 
>         // instance, but does not mutate the containing message.
>         operation.launch();
>         assert(!operation.has_launch());
>         assert(operation.launch().task_infos_size() == 0);
>         assert(!operation.has_launch());
>     
>         // The used mutating access changes the containing message.
>         operation.mutable_launch()->mutable_task_infos();
>         assert(operation.has_launch());
>         assert(operation.launch().task_infos_size() == 0);

Above example is assuming e.g., the following proto definitions:

    syntax = "proto2";

    package mesos;

    message Launch { repeated int32 task_infos = 1; }
    message Operation { optional Launch launch = 1; }


- Benjamin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/60563/#review179397
-----------------------------------------------------------


On July 1, 2017, 2:56 a.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/60563/
> -----------------------------------------------------------
> 
> (Updated July 1, 2017, 2:56 a.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Bugs: MESOS-7735
>     https://issues.apache.org/jira/browse/MESOS-7735
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Updated `validateAndUpgradeResources` to operate on `Operation`s.
> 
> 
> Diffs
> -----
> 
>   src/common/resources_utils.hpp 7128297c45fbf94af9384b678bf201f3d9c48b65 
>   src/common/resources_utils.cpp 3a6a57817d4b0c4f4133b0a8d2b6f4d9ea31ea6b 
> 
> 
> Diff: https://reviews.apache.org/r/60563/diff/2/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Michael Park
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message