mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chun-Hung Hsiao <chhs...@apache.org>
Subject Re: Review Request 65594: Checkpointed profiles in storage local resource provider.
Date Tue, 24 Apr 2018 00:54:34 GMT


> On April 20, 2018, 12:57 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Lines 1003 (patched)
> > <https://reviews.apache.org/r/65594/diff/8/?file=1996911#file1996911line1007>
> >
> >     Even thought an `auto` might make sense in such a place _in general_, due to
the interface of `MapInfo` it leads to pretty dense code and maybe repeating a type here might
make this easier to read. How about
> >     
> >         // NOTE: this form requires a `using` decl above.
> >         using Profile =
> >           MapPair<string, ResourceProviderState::Storage::ProfileInfo>;
> >           
> >         foreach (const Profile& profile, storage.profiles()) {
> >           profileInfos.put(
> >               profile.first,
> >               {profile.second.capability(), profile.second.parameters()});
> >         }

Adopted your suggestion, but I use `ProfileEntry` instead of `Profile` and keep the variable
name `entry`. I'd like to make it consistent across the code that `profile` indicates a name,
`profileInfo` indicates the CSI data, and `entry` indicates a map pair.


> On April 20, 2018, 12:57 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Line 1010 (original), 1011 (patched)
> > <https://reviews.apache.org/r/65594/diff/8/?file=1996911#file1996911line1015>
> >
> >     Nit: _pending operations_ should be specific enough as this list is neither
exhaustive today nor will remain in the future.
> 
> Chun-Hung Hsiao wrote:
>     I'm specifically talking about `CREATE_VOLUME` and `CREATE_BLOCK` here. `DESTROY_VOLUME`
and `DESTROY_BLOCK` don't need the profile info.

Removed them from the comments as suggested as the explicitness here doesn't bring much more
clarity.


> On April 20, 2018, 12:57 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Lines 3276 (patched)
> > <https://reviews.apache.org/r/65594/diff/8/?file=1996911#file1996911line3318>
> >
> >     Should we capture this?
> >     
> >         ProfileInfo& profile_ = *(storage->mutable_profiles())[profile];
> >         
> >     No strong opinion, it seems hard to make interacting with proto maps nice.

I'll do `ProfileInfo& profileInfo_ = ...`.


- Chun-Hung


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


On April 12, 2018, 3:35 a.m., Chun-Hung Hsiao wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/65594/
> -----------------------------------------------------------
> 
> (Updated April 12, 2018, 3:35 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, James DeFelice, Jie Yu, and Joseph Wu.
> 
> 
> Bugs: MESOS-8492
>     https://issues.apache.org/jira/browse/MESOS-8492
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> SLRP now checkpoints profiles associated with storage pools, and does
> not depend on the `DiskProfileAdaptor` module to return the set of
> previously-known profiles during recovery.
> 
> 
> Diffs
> -----
> 
>   src/resource_provider/state.proto 8577b58b8cdb63b3daddf06ea5d12f80f9d42f2b 
>   src/resource_provider/storage/provider.cpp a07620d1c4bf618f669575b3e183bf598da905a6

> 
> 
> Diff: https://reviews.apache.org/r/65594/diff/8/
> 
> 
> Testing
> -------
> 
> sudo make check
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>


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