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 11:27:51 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?

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


- 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