14:00:09 <rosmaita> #startmeeting cinder 14:00:10 <openstack> Meeting started Wed May 20 14:00:09 2020 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:13 <openstack> The meeting name has been set to 'cinder' 14:00:16 <rosmaita> #link https://etherpad.openstack.org/p/cinder-ussuri-meetings 14:00:19 <rajinir> hi 14:00:20 <lseki> o/ 14:00:24 <rosmaita> #topic roll call 14:00:33 <tosky> o/ 14:00:35 <jungleboyj> o/ 14:00:35 <m5z> hi =] 14:00:37 <whoami-rajat> Hi 14:00:42 <eharney> hi 14:00:43 <LiangFang> hi 14:01:03 * jungleboyj misses table flipping bot 14:01:23 <rosmaita> good turnout 14:01:28 <eharney> actually https://etherpad.opendev.org/p/cinder-victoria-meetings 14:01:29 <e0ne> hi 14:01:38 <walshh_> hi 14:01:39 <rosmaita> eharney: thanks! 14:01:53 <rosmaita> i am living in the past 14:02:06 <rosmaita> ok, welcome to the first cinder meeting of victoria! 14:02:10 * smcginnis is here but double booked 14:02:34 <rosmaita> good turnout, i have a bunch of announcements 14:02:40 <rosmaita> #topic announcements -- follow-up from last meeting 14:02:46 <enriquetaso> o/ 14:02:48 <jungleboyj> Yay! 14:02:48 <rosmaita> i had two action items to send notes to the ML, which i didn't do, but here's why 14:02:59 <rosmaita> action 1 was to propose that cinder co-maintain the barbican-tempest-plugin 14:03:08 <rosmaita> i thought about that and decided that it's not a great idea, i don't want us being spread too thin 14:03:17 <rosmaita> (also, we have another way to handle all the cinder scenario tests in that plugin that we'll discuss later) 14:03:27 <rosmaita> so instead, i went to the barbican meeting last week and proposed that tosky be the Barbican-Cinder liaison for testing related matters 14:03:34 <rosmaita> which both tosky and the barbican team agreed to 14:03:40 <rosmaita> so mark that one "done" 14:03:41 <jungleboyj> ++ 14:03:49 <enriquetaso> ++ 14:03:53 <rosmaita> action 2 was to see what operators think about the fix for compute host name leakage via volume-show 14:04:00 <rosmaita> but when i thought about it, we're going to make that change no matter what they think 14:04:07 <rosmaita> rajat added release notes that explain clearly what the situation is 14:04:13 <rosmaita> so i'll send an announcement about the fix to the ML after the patch makes it through the gate 14:04:19 <rosmaita> #link https://review.opendev.org/#/c/726751/ 14:04:27 <rosmaita> so that one is "done" too 14:04:39 <rosmaita> #topic announcements - PTG 14:04:42 <tosky> a note on action 1: it means we will need to test whether we can import the barbican-based volume test in cinder-tempest-plugin, and if it works (i.e. we can use the barbican tempest client and they can use the tests for cross-testing), we can move forward 14:05:03 <rosmaita> yeah, i'm leaving that part up to you 14:05:14 <rosmaita> don't forget to register for the ptg: 14:05:19 <rosmaita> #link https://virtualptgjune2020.eventbrite.com/ 14:05:24 <rosmaita> it's free 14:05:33 <rosmaita> but that way the foundation can send you the connection info etc 14:05:49 <rosmaita> i think we'll be using "meetpad" 14:05:58 <jungleboyj> Yep. 14:06:04 <rosmaita> opendev is hosting an instance, it seems pretty good 14:06:26 <rosmaita> for cinder stuff, and don't forget to add topics to our etherpad: 14:06:31 <rosmaita> #link https://etherpad.opendev.org/p/cinder-victoria-ptg-planning 14:07:05 <rosmaita> i'll try to get the proposals worked into a rough schedule early next week 14:07:11 <rosmaita> so you can plan ahead a bit 14:07:36 <rosmaita> #topic announcements - Interoperability WG 14:07:44 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014895.html 14:07:58 <rosmaita> i'll give you a second to open that link 14:08:03 <rosmaita> the big takeaway from that email is don't use Yahoo Mail on Android to send stuff to the ML 14:08:28 <rosmaita> i'm pretty sure where he says "team members of Core" he's talking about the Core Components for interoperability, not that you need to be a cinder-core to participate on behalf of cinder 14:08:37 <rosmaita> which actually brings me to my point, namely: 14:08:44 <rosmaita> is there anyone here with a strong interest in interoperability and being the cinder liaison for the interoperability WG? 14:08:51 <rosmaita> (please someone say yes) 14:09:06 <rosmaita> only change we had in ussuri impacting interop is a bump in mv 14:09:14 <rosmaita> train max mv == 3.59, ussuri max mv == 3.60 14:09:20 <rosmaita> from this commit: 14:09:29 <rosmaita> #link https://github.com/openstack/cinder/commit/7e98d14a5724efaa8b02d8dc1c5d28cde7ce0ea6 14:09:49 <rosmaita> (yes, it says 3 years ago, but it really was merged during ussuri) 14:09:59 <rosmaita> but tbh, i do not know how microversions are taken into account for interop purposes 14:10:06 <rosmaita> i mean, whether operators can pick & choose which ones they expose 14:10:19 <rosmaita> in any case, if you are interested in working with the interop WG 14:10:23 <rosmaita> your immediate task would be to attend the meeting on this friday 22 may at 14:00 UTC 14:10:37 <rosmaita> (otherwise i guess i will have to go) 14:10:42 <rosmaita> they meet on zoom, so more fun than IRC 14:10:51 <rosmaita> details are on the meeting agenda etherpad: 14:10:58 <rosmaita> #link https://etherpad.opendev.org/p/interop 14:11:05 <rosmaita> anyway, grab me in #openstack-cinder today sometime if you want to talk about what it is in general that the interop WG does and what being cinder liaison would entail 14:11:17 <rosmaita> this used to be super-important, but these days i'm not so sure 14:11:39 <rosmaita> #topic announcements - Launchpad! 14:11:45 <rosmaita> yes, we are still using it 14:11:52 <rosmaita> #link https://launchpad.net/cinder/+milestone/victoria-1 14:12:06 <rosmaita> that's what we have targeted so far for M-1 14:12:43 <rosmaita> plus, of course, lots of driver patches are untargeted but available for your reviewing pleasure 14:12:52 <rosmaita> btw, i put up a patch moving the image encryption spec to victoria: 14:13:00 <rosmaita> #link https://review.opendev.org/#/c/729574/ 14:13:14 <rosmaita> victoria milestone-1 is June 18, so less than a month away 14:13:25 <rosmaita> i know we haven't had the ptg yet 14:13:37 <rosmaita> but we have some leftover train-ussuri business that can be attended to 14:14:35 <rosmaita> nfs encryption (enriquetaso), volume-local-cache (LiangFang), and in-flight encryption (Luzi and m5z, i think) 14:14:45 <rosmaita> victoria milestone-1 is June 18, so less than a month away 14:15:14 <rosmaita> i am sure all those folks will appreciate reviews so they can keep things moving 14:15:36 <rosmaita> ok, that's it for announcements 14:15:37 <enriquetaso> ++ 14:15:50 <rosmaita> #topic tempest service client registration & detection 14:15:51 <enriquetaso> thanks rosmaita 14:16:04 <rosmaita> this came up on the mailing list two weeks ago: 14:16:14 <rosmaita> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014778.html 14:16:19 <rosmaita> and it refers to this: 14:16:28 <rosmaita> #link https://docs.openstack.org/tempest/latest/plugins/plugin.html#service-clients 14:16:54 <rosmaita> anyway, tosky can fill in details, but the general idea is that the reason why we have volume scenario tests in the barbican-tempest-plugin 14:17:13 <rosmaita> is that they need to use the barbican service client, which only exists in that plugin 14:17:25 <tosky> yeah, sorry, my comment above should have been written here, as part of the follow up on the follow up of action 1 14:17:38 <rosmaita> but, there is a framework in tempest to allow a plugin to register its clients so that others can use them 14:17:58 <tosky> looking at the code, the barbican-tempest-plugin seems to implement the proper class methods to register its tempest clients 14:18:33 <rosmaita> we discussed this with the barbican team, and they like the idea of us (i.e., tosky) putting up a patch to get the client registered 14:18:35 <tosky> so I believe that we can use the barbican tempest clients by just depending on barbican-tempest-plugin (and installing it in the same tempest environment) 14:19:04 <rosmaita> and they have no objection to us moving those tests to the cinder-tempest-plugin, where we should be able to use the barbican client 14:19:10 <rosmaita> but like tosky just said 14:19:16 <rosmaita> this is still theoretical 14:19:29 <rosmaita> there is a framework, but i'm not sure anyone is actually using it yet 14:19:45 <rosmaita> but if it does work, that will be great 14:19:51 <tosky> oh, a lot of people are using it, I think gmann was a bit pessimistic there :) 14:20:04 <rosmaita> that's great, then 14:20:12 <tosky> or at least the project I'm close to implemented it (sahara and manila) 14:20:20 <tosky> I will probably send a patch which imports the volume tests from thir plugin to cinder-tempest-plugin and see if everything explodes or not 14:20:36 <rosmaita> sounds like a good plan to me! 14:20:57 <rosmaita> so, if this works, we'll have the volume tests back in our plugin 14:21:07 <rosmaita> and we can let the barbican people do their own thing 14:21:22 <tosky> we also need to verify they can use our tests for cross-testing 14:21:26 <tosky> so we don't break each other 14:21:37 <rosmaita> that would be nice 14:22:08 <gmann> rosmaita: tosky using it via import is dangerous and chance to break. service client can be registered i tempest and used from there. that is much stable and suggested way 14:22:43 <rosmaita> gmann: thanks -- i think that's our plan 14:22:44 <gmann> running tests of each other is all fine but using not-stable API are not 14:22:48 <gmann> +1 14:22:57 <rosmaita> tosky meant moving the tests over from their plugin to ours 14:23:24 <gmann> ok, tests are fine to move. 14:23:29 <rosmaita> anyway, that's some excitement on the testing front 14:23:51 <rosmaita> #topic Backup bug fix and functional tests 14:23:57 <rosmaita> ganso: that's you 14:24:01 <ganso> hi! 14:24:23 <ganso> ok so this is just a heads up that the functional test patch and fix patches are 100% ready for review 14:24:39 <ganso> #link https://review.opendev.org/#/c/720833 14:24:44 <ganso> #link https://review.opendev.org/#/c/728289/ 14:25:25 <ganso> I went with the approach that we've had agreed in previous meetings, to have separate backup trees per tenant 14:26:19 <ganso> that worked very well IMO, implementation was simple, and from the functional test we can see from the API that it works as our agreed definition of "intended". 14:27:31 <ganso> in the test patch comments you can see the before and after the depends-on was added 14:28:20 <rosmaita> ok, thanks -- i just targeted those for victoria milestone-1 14:28:41 <ganso> that's all I had, looking forward to any review feedback 14:29:04 <rosmaita> ok, thanks for the reminder 14:29:31 <rosmaita> #topic volume local cache 14:29:36 <LiangFang> hi 14:29:41 <rosmaita> hello 14:29:52 <LiangFang> I moved the spec from U to V 14:30:12 <LiangFang> and the review is: https://review.opendev.org/#/c/729473/ 14:30:38 <LiangFang> not sure I did correctly 14:31:15 <LiangFang> regarding the cinder patch: https://review.opendev.org/#/c/700799/ 14:31:24 <whoami-rajat> this will be a merge conflict with the encryption one 14:31:50 <rosmaita> yeah, we can work that out later -- the spec is approved for V even if it's not in that directory 14:31:57 <rosmaita> yet 14:32:52 <LiangFang> so depends on which patch go first, right? seems the second patch need to do the merge conflict:) 14:33:04 <rosmaita> yep 14:33:16 <LiangFang> seems I don't need to handle the merge conflict currectly 14:34:03 <rosmaita> yes, don't worry about the spec, we'll get that taken care of eventually 14:34:06 <LiangFang> in last meeting, team and eharney suggested to move cacheable=True capability to volume manager 14:34:29 <LiangFang> rosmaita: thanks 14:35:07 <LiangFang> I have done the rework, moved cacheable=True from driver to manager 14:35:46 <LiangFang> now this is enabled by protocols, iscsi/fc/nvmeof will be added cacheable 14:36:32 <LiangFang> correctly os-brick patch is also ready to be reviewed 14:36:46 <LiangFang> https://review.opendev.org/#/c/663549/ os-brick patch 14:37:11 <LiangFang> I'm sorry I cannot add tempest test case at this moment, because: 14:37:38 <LiangFang> tempest test case depends on the initial patches be merged first 14:37:43 <LiangFang> e.g. 14:38:21 <LiangFang> in test case, I cannot successfully create volume type with cacheable <is >True, but 14:38:34 <tosky> not even if you create a test which depends-on the patch with the feature? 14:38:35 <LiangFang> in test case, I can successfully create volume type with cacheable <is >True, but 14:39:33 <LiangFang> in the following creating volume, it will fail, because scheduler cannot find a valid backend 14:40:08 <LiangFang> this is because no backend is marked as cacheable by manager(this is in cinder patch) 14:41:30 <whoami-rajat> ^ what tosky said, depends on doesn't help? 14:41:37 <LiangFang> tosky: can I depends on a patch that have not merged? thanks 14:41:49 <tosky> LiangFang: yes, that's the magic of zuul 14:41:56 <LiangFang> great! 14:42:02 <rosmaita> tosky: can you have multiple depends-on ? 14:42:05 <LiangFang> thanks 14:42:25 <tosky> rosmaita: yes (not sure what happens if they conflict, but I didn't hit that case) 14:42:37 <rosmaita> that shouldn't happen here 14:42:50 <tosky> have you never seen a patch on zuul which has like 6 or 7 other patches in its stack? 14:43:20 <rosmaita> no, i like my dependencies to be singular 14:44:06 <LiangFang> tosky: one more thing of tempest test case is: 14:44:58 <LiangFang> after volume be cached, I need to verify it is really successfully cached, then, i need to get the info from host machine 14:45:49 <LiangFang> but host machine(compute node) normally is not the one running tempest test case 14:46:25 <LiangFang> so it is not possible to get info from host machine(compute node) 14:46:42 <tosky> it depends on what you need to do in the test to ensure that everything works 14:46:48 <LiangFang> but yes, in zuul, it is the same machine 14:48:15 <LiangFang> I can call e.g. "ps aux", then check the qemu process, check the -drive, if it is like cas1-1 or something, then it means it is successfully cached 14:49:08 <rosmaita> you might want to talk to some nova people, i imagine that they have to do that kind of stuff for some of their tests 14:49:11 <LiangFang> "ps aux" should be running on compute node, but yes, it works in zuul 14:49:32 <LiangFang> rosmaita: ok 14:50:32 <LiangFang> I find the tempest lib files, seems cannot find a function to run cmd in compute node (yes, can run in VM that created) 14:51:58 <tosky> uhm, need to recheck for the compute node 14:52:26 <LiangFang> so, if added the test cases like this way (ps aux, then check ..), it means the test case can only run in zuul, it is not a common test case that can run in an environment that tempest is not running in the compute node 14:53:31 <rosmaita> well, i guess running in zuul only is a start 14:53:51 <eharney> i don't think you can rely on running "ps" from a tempest test to check on the status of something like this 14:53:55 <LiangFang> another thing is: 14:54:38 <tosky> I would say: let's write down which are the conditions needed to verify the feature, in plan English, and then move forward from there 14:54:38 <LiangFang> seems tempest test case can only running functional test, cannot really compare the performance with/without cache, because: 14:55:37 <tosky> no, that's not the place for performance test (that would be rally), but we probably need to see anyway if it's working 14:55:43 <LiangFang> even not cached, in zuul, the volume(actually the file) will be cached by host machine system page cache 14:56:08 <rosmaita> yes, the point of these is to make sure everything works, not to assess performance 14:56:50 <LiangFang> ok 14:57:21 <rosmaita> anything else? 14:57:22 <LiangFang> so I will try to add depend-on patches, and then make tempest works 14:57:28 <rosmaita> sounds good! 14:57:41 <LiangFang> that's all, thanks 14:57:44 <rosmaita> ok, 2 minutes for open discussion 14:57:48 <rosmaita> #topic open discussion 14:58:01 <tosky> reminder: please vote on https://review.opendev.org/#/c/709780/ which migrates the grenade jobs to native zuul v3, part of the community goal for V (and it will be backported to ussuri) 14:58:46 <rosmaita> ok, thanks, i will look at that one after the meeting 14:59:24 <m5z> small request: could you please review: https://review.opendev.org/#/c/724634/5 14:59:45 <m5z> #link https://review.opendev.org/#/c/724634/5 15:00:03 <rosmaita> ok 15:00:14 <rosmaita> out of time ... thanks everyone! 15:00:16 <m5z> thanks :) 15:00:16 <rosmaita> #endmeeting