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