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