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 69520: Set up the `Resource.DiskInfo.Source.vendor` field in SLRP.
Date Thu, 13 Dec 2018 20:01:32 GMT


> On Dec. 13, 2018, 12:15 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Lines 251 (patched)
> > <https://reviews.apache.org/r/69520/diff/1/?file=2112537#file2112537line251>
> >
> >     Could we order `vendor` before `id` in the arg list?

I put the arguments in this order because the "general" case is that the `vendor` field can
be inferred from `info`, in this case if we switch the order we'll have to always pass in
a `None`.
The only exception is that when we read a resource checkpoint we'll pass it in explicitly.

Does this justify the order or do you think it would make the code more readible if I switch
the order and pass in an `None` below?


> On Dec. 13, 2018, 12:15 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Lines 270 (patched)
> > <https://reviews.apache.org/r/69520/diff/1/?file=2112537#file2112537line270>
> >
> >     This is pretty dense, maybe instead
> >     ```
> >     if (vendor.isSome()) {
> >       source->set_vendor(vendor.get());
> >     } else {
> >       source->set_vendor(strings::join(
> >         ".", info.storage().plugin().type(), info.storage().plugin().name()));
> >     }
> >     ```
> >     
> >     Since this would be the third time we touch `source`, I think it would make
sense to store in in a variable and use it above and below.

I'll do the latter but still perfer `getOrElse`. However, I'll move this whole logic to the
caller. See below.


> On Dec. 13, 2018, 12:15 p.m., Benjamin Bannier wrote:
> > src/resource_provider/storage/provider.cpp
> > Lines 1394 (patched)
> > <https://reviews.apache.org/r/69520/diff/1/?file=2112537#file2112537line1394>
> >
> >     Why don't we have to worry about `has_vendor() == false` here?

Here I'm specifically use the property that `vendor()` would return an empty string. If we
pass in `None()` instead, the `vendor` field will be computed based on `info`, which may be
wrong if the operator swap out the CSI config during an upgrade. But maybe what I need is
to make `createRawDiskResource` darn simple and don't infer `vendor` at all.


- Chun-Hung


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


On Dec. 7, 2018, 4:34 a.m., Chun-Hung Hsiao wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/69520/
> -----------------------------------------------------------
> 
> (Updated Dec. 7, 2018, 4:34 a.m.)
> 
> 
> Review request for mesos, Benjamin Bannier, Jie Yu, and Jan Schlicht.
> 
> 
> Bugs: MESOS-9321
>     https://issues.apache.org/jira/browse/MESOS-9321
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> For a CSI-backed disk resource, this field is set to the concatenation
> of the type and name of its CSI plugin, with a dot in between. This
> enables frameworks to identify the storage backend the disk resource.
> 
> 
> Diffs
> -----
> 
>   src/resource_provider/storage/provider.cpp c137fa4f13edc58d93c03a9dd32fdf9d38b38316

> 
> 
> Diff: https://reviews.apache.org/r/69520/diff/1/
> 
> 
> Testing
> -------
> 
> Testing done later in chain.
> 
> 
> Thanks,
> 
> Chun-Hung Hsiao
> 
>


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