14:00:32 #startmeeting cinder 14:00:32 Meeting started Wed Feb 19 14:00:32 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:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:35 The meeting name has been set to 'cinder' 14:00:36 o/ 14:00:39 hi 14:00:49 #link https://etherpad.openstack.org/p/cinder-ussuri-meetings 14:00:57 #topic roll call 14:01:10 hi! o/ 14:01:12 Hi 14:01:14 hi 14:01:29 O/ 14:01:40 looking like a good turnout 14:02:04 o/ 14:02:09 ok, let's get started 14:02:16 #topic announcements 14:02:22 a bunch of business items today 14:02:29 #topic announcements - Vancouver PTG head count 14:02:37 reminder - need a head count for the Vancouver 2020 PTG (8-11 June) 14:02:45 please add yourself to the etherpad 14:02:52 #link https://etherpad.openstack.org/p/cinder-victoria-ptg-planning 14:03:01 also, feel free to start adding topics 14:03:05 hi 14:03:19 #topic announcements - virtual mid-cycle part 2 14:03:26 as discussed last week, will be the week of 16 March 14:03:32 watch the ML for a poll - hopefully in the next day or two 14:03:41 i need to figure out what went wrong with the time zones in doodle for the volume-local-cache meeting poll before sending it out 14:03:52 #topic announcements - possible data loss situation (bug 1852106) 14:03:54 bug 1852106 in Glance "Possible data loss from createImage action" [Undecided,New] https://launchpad.net/bugs/1852106 14:04:01 i think i mentioned this at the end of last week's meeting 14:04:08 kind of an unlikely scenario, i think 14:04:16 details and a quick workaround were sent out on the ML yesterday 14:04:23 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012641.html 14:04:32 it only applies to train (or if someone is running a cloud out of master) 14:04:49 btw, the main nova patch addressing this merged last night 14:04:55 #link https://review.opendev.org/#/c/707738/ 14:05:03 if you have a ussuri devstack around set up to do encrypted volumes 14:05:10 it would be worth giving that change a workout 14:05:18 i'm not worried about it preventing direct boot of an image of an encrypted volume 14:05:26 but i'm a little worried about it working *too* well, that is, preventing a legitimate use case 14:05:35 all the obvious stuff seems to work 14:05:43 i think i should probably spend some time working on some tempest tests 14:05:59 #topic releases 14:06:09 cinder 16.0.0.0b1 has been released for milestone-2 14:06:16 thanks to smcginnis for fixing some bugs around config and docs and the kilo branch (!) that were blocking the release 14:06:30 cinderclient and brick cinderclient extension also had their first py3-only releases 14:06:30 Right place, wrong time? 14:06:48 :) 14:06:50 6.0.0 for client, 1.0.0 for the extension 14:06:58 these aren't the final ussuri releases, we just wanted the py3-only versions available so that they can get a workout in the gate 14:07:10 #topic releases - os-brick 14:07:17 would like to get a py3-only release out there 14:07:24 again, this won't be the final ussuri release 14:07:31 let's take a quick look at whether there's anything that would be good to get in 14:07:40 #link https://review.opendev.org/#/q/project:openstack/os-brick+status:open+branch:master 14:08:38 i think 697564 was being held by zuul because its parent hadn't merged 14:08:57 i just did a recheck, it should be ok now 14:08:58 o/ 14:09:52 my main question here is: is there anything we should wait for, keeping in mind that this is *not* the actual ussuri release 14:10:13 nothing jumps out at me as crucial 14:10:44 looks like os-brick is in a good shape to be released 14:11:06 ok, thanks 14:11:13 looks like  699861 may be ready 14:11:25 #link https://review.opendev.org/#/c/699861/ 14:11:32 Yeah, given that this isn't the final release it looks pretty good. 14:11:55 ok, great 14:12:15 #topic releases - final rocky release 14:12:28 this is supposed to happen soon 14:12:37 looks like we've got 3 unmerged patches 14:12:43 Support Incremental Backup Completion In RBD 14:12:50 #link https://review.opendev.org/705703 14:12:57 Fix: Create new cache entry when xtremio reaches snap limit 14:13:00 699861 is on its way. 14:13:06 #link https://review.opendev.org/707341 14:13:20 jungleboyj: thanks, that was sitting for a long time 14:13:26 Tell reno to ignore the kilo branch 14:13:33 #link https://review.opendev.org/707498 14:13:40 (that last one is a no-brainer, we can't cut a release without it) 14:13:47 (but we need the cherry-pick to stein merged first:) 14:13:54 #link https://review.opendev.org/#/c/707497/1 14:14:11 What about the Comment on 705703 from Lucian? 14:14:27 i'm working on it 14:14:43 so far, I wasn't able to reproduce it in stein/master 14:14:50 i'm going to try with rocky 14:15:06 that's probably a latent bug in the object code 14:15:17 if someone would like to reproduce it too, it would be great:) 14:15:25 enriquetaso: The reno one? You may need to force updating reno to the latest. 14:15:34 the backup fix could make it more likely to occur, hard to say 14:16:06 smcginnis, about Lucian's comment in 705703 14:16:32 what do you suggest eharney ? 14:17:31 it would be nice to know where it actually happened -- given that rbd incr backup is totally broken without this patch, if it only happens sometimes when using incr backup, we're still better off just landing 705703 14:17:48 Ok. 14:18:04 it also happened on windows, which, no idea what that tells us 14:18:38 ok 14:18:45 oh.. 14:18:52 He he he. 14:19:08 so it sounds like it would be ok to merge into stable/rocky as enriquetaso continues to investigate? 14:19:35 (which investigation can consist of asking lucien to give us more info) 14:19:43 https://gph.is/1gTrfDd 14:19:56 rosmaita: ++ 14:20:07 export_record is in the traceback, i guess we could try testing backup import/export 14:20:57 hey, looking at that trace, I think that the parent field should be part of the OPTIONAL_FIELDS list: https://github.com/openstack/cinder/blob/master/cinder/objects/backup.py#L152 14:21:22 someone mentioned Windows so a notification popped up :D 14:21:44 I've tried http://paste.openstack.org/raw/789482/ eharney 14:22:02 #link https://bugs.launchpad.net/cinder/+bug/1862635 14:22:03 Launchpad bug 1862635 in Cinder "Cinder backup export broken" [Undecided,New] 14:22:15 smcginnis: what's the absolute deadline for final rocky release? 14:23:34 for some reason 24 February is in my head, but i don't know if it's that day, or anytime that week 14:24:20 Yes, theoretically Feb 24. 14:25:19 ok, well, i think we can merge enriquetaso's patch and hopefully come up with a bugfix before monday 14:25:29 WFM 14:25:31 so, the above patches are the only things i see for *all* cinder components for stable/rocky 14:25:37 but i am not 100% confident in my gerrit query abilities 14:25:43 so if anyone here has anything they are watching to get into stable/rocky 14:25:51 say something now 14:26:05 otherwise, i think we are looking good for final rocky release 14:26:33 rosmaita: Thanks for keeping such good track of all of that. 14:26:46 just trying to do my job :D 14:26:55 :-) 14:26:59 ok, that's all from me 14:27:09 #topic friendly review request 14:27:14 going out of order here 14:27:21 becasue this should be quick 14:27:35 e0ne has a request for people to look at 14:27:46 #link https://review.opendev.org/630305 14:27:47 rosmaita: thanks 14:27:59 last patch required for generic backups feature! 14:28:04 this patch was waiting for reviews few month 14:28:08 months 14:28:18 but now I updated it with unit-tests 14:28:32 that makes it much sexier 14:28:50 Ooooh, I like a good unit test. 14:28:52 I've added unit-tests only for a *new* code, so some old functions are still not covered :( 14:29:08 anyway, I hope to. get some feedback on it 14:29:20 thanks e0ne 14:29:30 Ok. I will take a look. Would be great to get that feature in. 14:29:31 any other comments? 14:29:48 I'll propose few next patches soon with new unit tests and generic backup implementation 14:29:59 very cool! 14:30:00 hope to get it ready for Ussuri 14:30:21 Yay! 14:30:21 #topic volume-local-cache 14:30:28 LiangFang: that's you 14:30:40 quick question first, though 14:30:49 hi team, I have updated the spec based on the cross team meeting with nova 14:30:54 did you send an email for nova spec-freeze exception? 14:31:00 yes 14:31:06 Yeah, I saw that go out. 14:31:08 ok, i missed it 14:31:12 http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012615.html 14:31:16 thanks 14:31:29 I will attend Nova meeting tomorrow 14:31:55 ok, great 14:31:59 Nova team is giving +1, and wait cinder team to go first 14:32:07 He he. 14:32:29 https://review.opendev.org/#/c/689070/ 14:33:07 #link https://review.opendev.org/#/c/684556/ 14:33:24 (that's the cinder one) 14:33:29 yes 14:33:53 ok, i will commit to re-reading the cinder spec today 14:34:14 Me too. 14:34:23 my thinking is: could it be an experimental feature in Ussuri, so customers can test it 14:34:29 eharney: it would be helpful if you have time to verify that the encryption part is OK by you 14:34:58 ok 14:35:06 thanks 14:35:29 it looks like a big feature, and let's improve it in next release 14:35:34 LiangFang: that sounds reasonable 14:35:34 is any scenario tempest test planned for the feature? 14:35:44 I'd say it would be almost a requirement 14:36:26 I just tests in my Openstack running time environment, so tempest test run yet. 14:36:35 no tempest test run yet 14:36:45 i wonder what kind of new tempest test we would want for it 14:37:14 we definitely would want to create a job that runs a lot of existing tests on this config 14:37:23 eharney: ++ 14:37:29 ++ 14:37:46 we'd need a node with open-cas running, and then just use the current tests 14:38:19 although i don't know that we have a lot of tests that check data integrity? 14:38:38 rosmaita, agreed 14:38:38 should I provider such node? 14:38:57 opencas is open source software right? 14:39:03 yes 14:39:04 LiangFang: can you run open-cas even without the SSDs 14:39:24 just using node memory or something 14:39:35 yes, we can use DRAM as cache 14:39:49 ok, because we don't need to know about performance 14:40:02 just that stuff does not blow up when the cache is being used 14:40:13 yes, we even can /dev/loop1 as cache 14:40:27 cool, that would do it 14:40:50 we probably want some devstack support to install it with a basic config, and then we can create a zuul job for it 14:41:07 that sounds right 14:41:41 so how does this sound 14:41:48 inspur seems interest with this feature, not sure what the deploy tool they are using 14:41:54 experimental feature -> zuul job -> finish feature 14:42:10 that is, don't require the zuul job for this spec 14:42:30 Sounds fair. 14:42:35 makes sense 14:42:54 ok, i'll be sure to mention this on the review 14:43:02 tosky: thanks for bringing this up 14:43:13 nice to have someone worried about testing in the room! 14:43:32 :-) 14:43:39 a lot of people around are worried about testing too - I'm just noisy 14:43:40 :) 14:43:46 rosmaita: should I provide test node? 14:44:26 I know a team from Intel is providing CI node 14:44:42 oh, may be the same team with RSD 14:44:55 well, my main concern for the experimental feature is that having its code there doesn't break normal cinder 14:45:03 so our current tests should cover that 14:45:16 ok... thanks 14:45:28 i guess i'm not so interested in a test node as much as what tosky and eharney suggested 14:45:51 make it possible to run open-cas in a devstack with no fancy hardware 14:46:03 and run our tempest tests against it 14:46:07 rosmaita: ++ 14:46:21 ++ 14:46:41 ok, any general comments from anyone? 14:46:50 rosmaita: I guess that if a 3rd-party CI would like to setup such environment with real hardware, they will be more than welcome 14:47:06 in addition to the open-cas job 14:47:22 sure 14:47:33 the problem is that those things come and go 14:47:39 while devstack is forever 14:48:25 but yes, LiangFang if you know of someone who wants to set up a 3rd party CI with SSDs and stuff, please encourage them 14:48:39 rosmaita: ok 14:49:02 anything else? 14:49:21 gibi comments in Nova spec 14:50:07 saying he want to see +2s in Cinder spec......... 14:50:30 :) 14:50:36 what time is the nova meeting tomorrow? 14:50:37 sorry to say that 14:50:45 :-) 14:50:59 seems the same time of today 14:51:31 i'll review today 14:51:46 14:00 UTC (#openstack-meeting) 14:51:47 it looks like you've addressed all the points that came up in the meeting 14:51:48 thanks 14:52:00 so i anticipate a +2 14:52:23 unless someone notices a major problem that we've all missed 14:52:43 i think we'd be able to require clarifications in a follow up 14:52:43 thanks team 14:53:01 no promises, but i am optimistic 14:53:24 i know it's late where you are, hopefully you will awaken to good news tomorrow 14:53:52 :-Dthanks 14:53:54 Sleep with dreams of caching 14:54:02 #topic open discussion 14:54:03 .......... 14:55:11 finally we have time for open discussion, and nobody has anything to say? 14:55:16 :) 14:55:19 :D 14:55:31 rosmaita: You are just on top of everything. 14:55:37 i wish 14:56:02 ok, so please look at volume-local-cache spec 14:56:10 and e0ne's backup patch 14:56:17 :) 14:56:43 and stable cores, please look at the 3 reviews for stable/rocky 14:56:59 and enriquetaso is going to investigate lpetrut's bug a bit further 14:57:04 anything else? 14:57:12 +1 14:58:16 sounds like we are all done 14:58:20 thanks everyone! 14:58:20 Thanks! 14:58:24 thanks 14:59:16 see you next week! 14:59:17 #endmeeting