From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============5264295370391874755==" MIME-Version: 1.0 From: Sasha Kotchubievsky Subject: [SPDK] Re: Preparation for SPDK 19.10 release Date: Wed, 16 Oct 2019 20:00:48 +0300 Message-ID: <052201d58443$42e7cb20$c8b76160$@dev.mellanox.co.il> In-Reply-To: E9604F29-120B-4084-8D0E-F30225B531E0@intel.com List-ID: To: spdk@lists.01.org --===============5264295370391874755== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Jim, PSB [SK] -----Original Message----- From: Harris, James R = Sent: Wednesday, October 16, 2019 6:22 PM To: Storage Performance Development Kit Subject: [SPDK] Re: Preparation for SPDK 19.10 release Hi Sasha, The CHANGELOG is built during the months leading up to the release, and Tom= ek typically does some cleanups just before the release. If you'd like to = help with finalizing the CHANGELOG before the release, please push some pat= ches! Documentation is always an area where the project could use more hel= p. [SK] Changelog is good. I'm talking about "Release notes" https://github.com/spdk/spdk/releases/tag/v19.07 I think, that's first point to see that's new in the release For the RDMA testing, I have some of the same questions as Paul. If there = are gaps in upstream per-patch or nightly tests, please help us get them cl= osed. Can you describe the tests you're running internally, how often they= take, and how often you are running them? [SK] Correct me if I'm wrong, but most of existing tests in SPDK use SoftRo= ce, or single host without actual transferring data over network. Runtime = behavior on real HW can be different. = Our verification system today tests solutions which include SPDK as buildin= g block. We work with stable version of SPDK and don't update it frequently= . It mostly focus on Mellanox's parts and less on SPDK. >From functional perspective, we test complex scenarios like OS install/boot= to/from distributed storage. We test reboots and reconnects. In addition,= we test on non-x86 platform too. For upstream SPDK (reacting on each patch) we have limited number of sanity= tests. >From my point of view, for network part the verification system should test: - Matrix of HW, SW stacks (OS, OFED) - Matrix of protocols: RDMA, TCP = - Corner cases like link failure, network congestion , SW/HW failures durin= g real traffic - Stress testing - Long tests = Thanks, -Jim =EF=BB=BFOn 10/16/19, 7:47 AM, "Luse, Paul E" wro= te: Hi Sasha, = I'm sure you'll get some other opinions as well but as the changelog no= w pretty much only contains interface and parameter changes sorted by modul= e, are you just suggesting re-organizing it to make it clearer per module w= here interface changes have occurred vs parameter changes? = Wrt testing, I love that you guys are testing this so thoroughly! I hav= e to ask though, what additional testing are you proposing that isn't alrea= dy in either the main CI or your own CI? Is there a possibility to get thes= e tests unstreamed? We really want to continue with a model of continuous i= ntegration and test without any additional testing nearing a release. The = freeze window is to provide time to prepare the release, make sure we've go= t everything in it that was intended, go through some Intel security checkl= ist stuff, etc. Ben said it best once at a summit, our releases are really= just a bookkeeping activity. = You can most definitely use that freeze window to do testing on your ow= n and submit a bug that could potentially halt the release, but I'd wouldn'= t support making that part of the process. = Thx Paul = On 10/16/19, 4:55 AM, "Sasha Kotchubievsky" wrote: = Hi Tomek, = That's great news. = = I have couple questions: = - Some of latest SPDK releases (18.10, 19.04, 19.07) were released = with serious bugs in NVME-OF RDMA. Especially latest 19.07. Is it possib= le to wait with formal release till our group in Mellanox will verify rel= ease candidate in internal verification system? I think, couple of days = will be enough for us provide a feedback to the community. - Can we add couple special sections to SPDK release notes (https://github.com/spdk/spdk/releases/tag/v19.07) ? = - Changes in interfaces - Changes in configuration parameters (including defaults) - Known bugs/issues For customers building solution on SPDK and considering upgrade, it= 's important to see changes in interfaces (including configuration par= ameters). = = Example of changes in an interface in coming 19.10 is = https://github.com/spdk/spdk/commit/9522ed36f8474c9314b76b2618e8d2d= 9de56afee #diff-2c205ae4170cbd2bbf219969f03c9c8d This commit adds a new event to bdev interface. = One of commits changed defaults was https://github.com/spdk/spdk/commit/b6b0a0ba59a21faf1a320dd3ea7079b= 282f9fc31 It changes default IOUnit size from 4K to 8K and affected existing configurations. = From my experience, having a table/list in release notes with such = changes (interfaces, parameters) can help to users to understand side-effec= ts of the upgrade. I would suggest to maintain the table in Changelog and ask for cont= ributors to update it is a part of patch. At release, this table can be just= copied to release notes. = = Best regards Sasha = -----Original Message----- From: Zawadzki, Tomasz = Sent: Wednesday, October 9, 2019 5:41 PM To: Storage Performance Development Kit Subject: [SPDK] Preparation for SPDK 19.10 release = Hello all, = The merge window for SPDK 19.10 release will close by October 24th. Please ensure all patches you believe should be included in the rel= ease are merged to master branch by this date. You can do it by adding a hashtag '19.10' in GerritHub on those pat= ches. = The current set of patches that are tagged and need to be reviewed = can be seen here: https://review.gerrithub.io/q/hashtag:%252219.10%2522+(status:open) = Starting with this release, process used so far for Maintenance rel= eases (ex. 19.04.1) will be applied to main releases. On October 24th new= branch 'v19.10.x' will be created, and a patch on it will be tagged as rel= ease candidate. Then, on October 31th, a formal release will take place tagging the= last patch on the branch as SPDK 19.10. = Between release candidate and formal release, only critical fixes s= hall be backported to the 'v19.10.x' branch. = Development can continue without disruptions on 'master' branch. = Thanks, Tomek _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org = = _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org = _______________________________________________ SPDK mailing list -- spdk(a)lists.01.org To unsubscribe send an email to spdk-leave(a)lists.01.org --===============5264295370391874755==--