From reviews-return-92120-apmail-mesos-reviews-archive=mesos.apache.org@mesos.apache.org Tue Aug 4 14:32:14 2020 Return-Path: X-Original-To: apmail-mesos-reviews-archive@locus.apache.org Delivered-To: apmail-mesos-reviews-archive@locus.apache.org Received: from mailroute1-lw-us.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) by minotaur.apache.org (Postfix) with ESMTP id E9A4C1932D for ; Tue, 4 Aug 2020 14:32:13 +0000 (UTC) Received: from mail.apache.org (localhost [127.0.0.1]) by mailroute1-lw-us.apache.org (ASF Mail Server at mailroute1-lw-us.apache.org) with SMTP id 91B1312434C for ; Tue, 4 Aug 2020 14:32:13 +0000 (UTC) Received: (qmail 72593 invoked by uid 500); 4 Aug 2020 14:32:13 -0000 Delivered-To: apmail-mesos-reviews-archive@mesos.apache.org Received: (qmail 72551 invoked by uid 500); 4 Aug 2020 14:32:13 -0000 Mailing-List: contact reviews-help@mesos.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: reviews@mesos.apache.org Delivered-To: mailing list reviews@mesos.apache.org Received: (qmail 72532 invoked by uid 99); 4 Aug 2020 14:32:12 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Aug 2020 14:32:12 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 31E50C052B for ; Tue, 4 Aug 2020 14:32:12 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.612 X-Spam-Level: * X-Spam-Status: No, score=1.612 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.2, KAM_DMARC_STATUS=0.01, KAM_LAZY_DOMAIN_SECURITY=1, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id GvIzkv6OpSZK for ; Tue, 4 Aug 2020 14:32:09 +0000 (UTC) Received-SPF: None (mailfrom) identity=mailfrom; client-ip=95.217.165.199; helo=reviews-vm-he-fi.apache.org; envelope-from=noreply@reviews.apache.org; receiver= Received: from reviews-vm-he-fi.apache.org (static.199.165.217.95.clients.your-server.de [95.217.165.199]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTP id 4ED277FA92 for ; Tue, 4 Aug 2020 14:32:09 +0000 (UTC) Received: from reviews-vm-he-fi.apache.org (reviews-vm-he-fi.apache.org [127.0.0.1]) by reviews-vm-he-fi.apache.org (Postfix) with ESMTP id 52C3E16025E; Tue, 4 Aug 2020 14:32:08 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1775500423880473496==" MIME-Version: 1.0 Subject: Re: Review Request 72716: Added implementation of the CSI server. From: Greg Mann To: Qian Zhang , Andrei Budnik Cc: Mesos Reviewbot , Greg Mann , mesos Date: Tue, 04 Aug 2020 14:32:08 -0000 Message-ID: <20200804143208.14498.95307@reviews-vm-he-fi.apache.org> X-ReviewBoard-URL: https://reviews.apache.org/ Auto-Submitted: auto-generated Sender: Greg Mann X-ReviewGroup: mesos X-Auto-Response-Suppress: DR, RN, OOF, AutoReply X-ReviewRequest-URL: https://reviews.apache.org/r/72716/ X-Sender: Greg Mann References: <20200729152713.20915.97430@reviews-vm-he-fi.apache.org> In-Reply-To: <20200729152713.20915.97430@reviews-vm-he-fi.apache.org> X-ReviewBoard-Diff-For: src/slave/csi_server.cpp Reply-To: Greg Mann X-ReviewRequest-Repository: mesos --===============1775500423880473496== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > On July 29, 2020, 3:27 p.m., Qian Zhang wrote: > > src/slave/csi_server.cpp > > Lines 244-245 (patched) > > > > > > Do we have to use `started` and `initializationCallbacks`? Can we do the similar with https://github.com/apache/mesos/blob/1.10.0/src/csi/v1_volume_manager.cpp#L1336 ? > > Greg Mann wrote: > The reason it's more complicated here is because we may add more "initialization logic" after server construction if publish/unpublish calls are made before the server is started. So we need an approach which will allow us to add more function calls which are executed during startup. I explored another approach while coding but this is what I ended up settling on, but I'm happy to explore other options if we can think of something better. > > Qian Zhang wrote: > I see currently you put the "initialization logic" (i.e. generate auth token and intialize plugins) in the constructor of `CSIServerProcess`. Can we instead do that in `CSIServerProcess::start()` and do the following in `CSIServer::start()`. > ``` > Future CSIServer::start() > { > started = process::dispatch(process.get(), &CSIServerProcess::start); > return started; > } > ``` > > And then in `CSIServer::publishVolume` and `CSIServer::unpublishVolume` we could do the following: > ``` > Future CSIServer::publishVolume( > const Volume::Source::CSIVolume& volume) > { > return started > .then(process::defer( > process.get(), > &CSIServerProcess::publishVolume, > volume)); > } > ``` > So any publish and unpublish volume calls can only be executed after CSI server is started. HDYT? > > Greg Mann wrote: > The reason I didn't follow this approach is that it doesn't guarantee that the order of publish/unpublish calls would be maintained when initializing, but maybe that's OK? > > I think that in our current implementation of `Future` in libprocess the order would be maintained, but this isn't guaranteed by the interface. Am I being too paranoid here? :-) > > Qian Zhang wrote: > > it doesn't guarantee that the order of publish/unpublish calls would be maintained when initializing > > Could you please elaborate a bit why this is a problem? In volume manager, I see we already have a sequence per volume to make sure all CSI gRPC calls on the same volume are processed in a sequential order. Let's say the containerizer cleans up two orphan containers during recovery, 'containerA' and 'containerB', and the csi isolator ends up calling `csiManager->unnPublish(pluginName, volumeForContainerA);` and then `csiManager->unPublish(pluginName, volumeForContainerB);`. At this point, the interface offered by the `Future` class does not guarantee that the continuation associated with the first `unPublish()` call will be executed before the continuation for the second `unPublish()` call. Does that make sense? - Greg ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/72716/#review221405 ----------------------------------------------------------- On Aug. 3, 2020, 6:58 p.m., Greg Mann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/72716/ > ----------------------------------------------------------- > > (Updated Aug. 3, 2020, 6:58 p.m.) > > > Review request for mesos, Andrei Budnik and Qian Zhang. > > > Bugs: MESOS-10163 > https://issues.apache.org/jira/browse/MESOS-10163 > > > Repository: mesos > > > Description > ------- > > Added implementation of the CSI server. > > > Diffs > ----- > > src/CMakeLists.txt 4e15e3d99aa2cce2403fe07e762fef2fb4a27dea > src/Makefile.am 447db323875e4cad46000977f4a61600baff8f89 > src/slave/csi_server.cpp PRE-CREATION > > > Diff: https://reviews.apache.org/r/72716/diff/4/ > > > Testing > ------- > > Details at the end of this chain. > > > Thanks, > > Greg Mann > > --===============1775500423880473496==--