> 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
>
>
