mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Park" <mcyp...@gmail.com>
Subject Re: Review Request 39018: Added JSON parsing for Resources.
Date Tue, 03 Nov 2015 21:35:20 GMT


> On Oct. 18, 2015, 6:18 p.m., Michael Park wrote:
> > src/common/resources.cpp, lines 482-532
> > <https://reviews.apache.org/r/39018/diff/13/?file=1098334#file1098334line482>
> >
> >     How about a structure like the following?
> >     
> >     ```cpp
> >     Resources result;
> >     
> >     // Populate `result` based on which format.
> >     Try<JSON::Array> resourcesJSON = JSON::parse<JSON::Array>(text);
> >     if (resourcesJSON.isSome()) {
> >       result = internal::convertJSON(resourcesJSON.get(), defaultRole);
> >     } else {
> >       foreach (...) {
> >         ...
> >         result += resource.get();
> >       }
> >     }
> >     
> >     // Validate the result regardless of what format
> >     Option<Error> validate = validateCommandLineResources(result);
> >     if (validate.isSome()) {
> >       return validate.get();
> >     }
> >     
> >     return result;
> >     ```
> >     
> >     `validateCommandLineResources` is as suggested before, with the `conflictingTypes`
logic encapsulated within it.
> >     
> >     I noticed we only perform the minimal validation necessary for the semicolon-delimited
string format currently.
> >     That is, we only do the `conflictingTypes` check. While this is sufficient in
the current state of the format,
> >     I think it simplifies the code to just do the full check. It's also future-proof
if we need to extend the string format later on.
> 
> Greg Mann wrote:
>     Yep I agree that this is cleaner. I implemented it and unfortunately, since `internal::convertJSON`
returns a `Try<Resources>`, we have to unwrap the Try before assigning it to `result`.
We could get around this by wrapping the `if ... else` block in a lambda and assigning the
result to a `Try<Resources> result`. In that case, however, we end up wrapping the old-style
parsed resources in a `Try` unnecessarily, so we do extra work either way. I think the current
version (without the lambda) is a bit more readable, so I went with that one.

This is totally fine. It's no worse than what we do in the old-style resources where we unwrap
each of the `Try<Resource>` to build the `result`:
```cpp
Try<Resource> resource = Resources::parse(name, pair[1], role);
if (resource.isError()) {
  return Error(resource.error());
}

result += resource.get();
```
Pragramatically speaking, we also only do this on start-up for command-line parsing and maybe
in tests. Not a big deal if we're not perf-optimized here.


- Michael


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


On Oct. 20, 2015, 6:09 a.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39018/
> -----------------------------------------------------------
> 
> (Updated Oct. 20, 2015, 6:09 a.m.)
> 
> 
> Review request for mesos, Adam B, Alexander Rukletsov, Jie Yu, and Michael Park.
> 
> 
> Bugs: MESOS-2467
>     https://issues.apache.org/jira/browse/MESOS-2467
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This includes code changes necessary for JSON parsing of Resources. Documentation changes
will be posted soon in another review (https://reviews.apache.org/r/39102/).
> 
> 
> Diffs
> -----
> 
>   include/mesos/resources.hpp 6c3a065945eb56dc88df9c977e5ca11d4cbcbf61 
>   include/mesos/v1/resources.hpp fe8925ac851b74d1b37919f00afc7ed816f47ea5 
>   src/common/resources.cpp 601388c35a1bff37c58e753d1870d53b8d0af2d1 
>   src/tests/resources_tests.cpp 6584fc6c39e6ffe9f8085576677dcc669f127697 
>   src/v1/resources.cpp dc868903472f8f3a1ddc56092e3f8f81d953ce39 
> 
> Diff: https://reviews.apache.org/r/39018/diff/
> 
> 
> Testing
> -------
> 
> New code was added to `ResourcesTest.ParsingFromJSON`, and two new tests were added:
`ResourcesTest.ParsingFromJSONWithRoles` and `ResourcesTest.ParsingFromJSONError`. These attempt
to test common error scenarios that might show up in user-supplied JSON.
> 
> `make check` was used to confirm that all tests pass, with one notable failure (ResourcesTest.ParsingFromJSONError)
related to a picojson issue tracked here: https://issues.apache.org/jira/browse/MESOS-3698
> 
> The original resources parsing format is used throughout many other tests (check `src/tests/sorter_tests.cpp`,
for example), so it's clear that the original parsing continues to work correctly.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>


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