> On March 19, 2019, 10:17 a.m., Jan Schlicht wrote: > > src/csi/metrics.cpp > > Lines 43-44 (patched) > > <https://reviews.apache.org/r/70168/diff/6/?file=2132458#file2132458line43> > > > > While I like the idea of having a compile-time check, this feels like > > obfuscating and complicating the code. We should keep it simple.
This is because we currently don't have a type-safe way to iterate through C++ enums. Although this complicates the code, it can prevent us from forgetting to add a metric and crash the agent in the future. That said, as per discussion w/ James, this will be replaced with aggergated metrics in https://reviews.apache.org/r/70225/. Dropping. > On March 19, 2019, 10:17 a.m., Jan Schlicht wrote: > > src/csi/metrics.cpp > > Lines 46-81 (patched) > > <https://reviews.apache.org/r/70168/diff/6/?file=2132458#file2132458line46> > > > > This will only push `csi::v0::GET_PLUGIN_INFO` into `rpcs`. It will push everything into the vector, as there is no break in each case. Dropping. > On March 19, 2019, 10:17 a.m., Jan Schlicht wrote: > > src/csi/service_manager.hpp > > Lines 55 (patched) > > <https://reviews.apache.org/r/70168/diff/6/?file=2132459#file2132459line55> > > > > Remove the `explicit`. > > Benjamin Bannier wrote: > While not explicitly required by our style guide, making any constructor > `explicit` by default doesn't look like a bad idea for me as it can prevent > unintended type conversions, e.g., > ``` > struct A { A(int, int); }; > struct B { B(int, int); }; > > // Changing the return type from `A` to `B` automatically invokes a > // different constructor. > A foo() { > return {1, 1}; // Implicit construction of an `A`. > } > ``` Given that the signature is already unique and the parameter list is long, the extra `explicit` is indeed unnecessary. And in the code base we mostly only do `explicit` for constructors with one argument, with very few exceptions. So I'm fine removing it. - Chun-Hung ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70168/#review213772 ----------------------------------------------------------- On March 12, 2019, 6:59 p.m., Chun-Hung Hsiao wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/70168/ > ----------------------------------------------------------- > > (Updated March 12, 2019, 6:59 p.m.) > > > Review request for mesos, Benjamin Bannier, Jie Yu, and Jan Schlicht. > > > Bugs: MESOS-9632 > https://issues.apache.org/jira/browse/MESOS-9632 > > > Repository: mesos > > > Description > ------- > > The `ServiceManager` is agnostic to CSI versions, so can be used to > manage plugin containers for both CSI v0 and v1 plugins. Most of its > logic are adapted from the SLRP code. > > We also separate the CSI plugin metrics from SLRP metrics object so the > metrics can be accessed by `ServiceManager`. However, we do not make > `ServiceManager` own the CSI plugin metrics object because eventually we > would like to decouple metrics lifecycles from SLRP lifecycles. > > > Diffs > ----- > > src/CMakeLists.txt 3397c3b1d4e8a7900b2e5f870679cc7aa30b4be2 > src/Makefile.am d451d7cabe3bf5d4f5039cfac5de1b03ef891d07 > src/csi/metrics.hpp PRE-CREATION > src/csi/metrics.cpp PRE-CREATION > src/csi/service_manager.hpp PRE-CREATION > src/csi/service_manager.cpp PRE-CREATION > > > Diff: https://reviews.apache.org/r/70168/diff/6/ > > > Testing > ------- > > Testing done later in chain. > > > Thanks, > > Chun-Hung Hsiao > >
