mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Wu <jos...@mesosphere.io>
Subject Re: Review Request 63971: Defined a module interface for translating volume profiles.
Date Tue, 28 Nov 2017 00:29:00 GMT


> On Nov. 27, 2017, 3:14 p.m., Chun-Hung Hsiao wrote:
> > include/mesos/resource_provider/volume_profile.hpp
> > Lines 28 (patched)
> > <https://reviews.apache.org/r/63971/diff/1/?file=1897942#file1897942line28>
> >
> >     Currently the CSI spec is internal (under `src/`). Do we want to expose it as
a public interface?

Yeah, I have that in a separate patch (not yet posted).  I didn't want to add build changes
in this review.


> On Nov. 27, 2017, 3:14 p.m., Chun-Hung Hsiao wrote:
> > include/mesos/resource_provider/volume_profile.hpp
> > Lines 86 (patched)
> > <https://reviews.apache.org/r/63971/diff/1/?file=1897942#file1897942line86>
> >
> >     It seems to me that the purpose of this function is that SLRP can request the
capabilities/params for a given profile dynamically. The alternative is to have a function
to provide a static map between profile names and capabilities/params, and SLRP calls it once
during startup. The advantage of this function over the alternative is that when a profile
is dynamically generated, there is no need to restart SLRP.
> >     
> >     However, when a new profile is generated, SLRP still needs to be notified so
that it can report the RAW resource for the new profile. Since there is not callback mechanism
for the module, we still need to restart SLRP so that it will report the RAW resource for
the new profile.
> >     
> >     So I'd suggest that we have another function that returns a map from profile
names to capabilities/params that would be called during SLRP startup instead.

The main idea behind this module is to request profiles right before making each CSI affected
call.  We are expecting profiles to be mutable at any time, so it does not make sense to cache
profiles, especially not in the SLRP.  If there is any caching, the module implementation
will be the one to do so.

This means there will be a possibility for a race between a `CreateVolumeRequest` and a `ControllerPublishVolumeRequest`,
if the operator updates the profiles between the calls.  However, I'm assuming that updating
profiles will not change existing volumes unless the volume is re-created.


- Joseph


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


On Nov. 27, 2017, 1:33 p.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63971/
> -----------------------------------------------------------
> 
> (Updated Nov. 27, 2017, 1:33 p.m.)
> 
> 
> Review request for mesos, Chun-Hung Hsiao and Jie Yu.
> 
> 
> Bugs: MESOS-8251
>     https://issues.apache.org/jira/browse/MESOS-8251
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This module is currently intended for use by the Storage Local
> Resource Provider (SLRP), but may be used by other components if
> those components use any of the affected Container Storage Interface
> (CSI) requests. The affected calls are listed in the module's comments.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto e194093e490741acc552fd3ad328fd710b4b4435 
>   include/mesos/resource_provider/volume_profile.hpp PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/63971/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Joseph Wu
> 
>


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