14:00:05 #startmeeting cinder 14:00:05 Meeting started Wed Feb 7 14:00:05 2024 UTC and is due to finish in 60 minutes. The chair is whoami-rajat. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 The meeting name has been set to 'cinder' 14:00:10 #topic roll call 14:00:19 Hello ! 14:00:30 o/ 14:00:33 o/ 14:00:41 o/ 14:00:46 o/ 14:01:21 o/ 14:01:21 o/ 14:01:38 Hi 14:02:46 #link https://etherpad.opendev.org/p/cinder-caracal-meetings 14:03:33 o/ 14:03:40 o/ 14:04:12 welcome everyone 14:04:17 let's get started with announcements 14:04:22 #topic announcements 14:04:32 Midcycle - 2 14:04:37 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/BJ7EFMPBDNZMDVYWASC7CFY5GXW4GEGX/ 14:04:48 Details: 14:04:48 Date: 14th February, 2024 14:04:48 Time: 1400-1600 UTC 14:04:48 Meeting link: https://meet.google.com/cqw-kbpn-sxx 14:04:48 Etherpad: https://etherpad.opendev.org/p/cinder-caracal-midcycles 14:04:54 We only have a week so please add your topics 14:05:58 get ready for 2 hour meeting next week! 14:06:09 next, Releasenote job breaking and fix 14:06:16 #link https://review.opendev.org/c/openstack/cinder/+/907836 14:06:22 As our transition from yoga-eom, we deleted the stable/yoga branch and created unmaintained/yoga 14:06:32 This caused a failure in our releasenotes job because we used the tag stable/yoga 14:07:02 I approved the patch but Brian left a comment that we should use yoga-eom instead of unmaintained/yoga as our releasenote tag 14:07:03 LOL - I just noticed that and was putting it in as a topic... 14:07:30 i also noticed today itself, but the release team was ahead of us 14:07:45 Me too, just noticed this morning 14:08:10 so here's why it matters 14:08:10 so unmaintained/yoga is synchronous with stable/yoga since it will be an active branch accepting changes 14:08:30 we don't have responsibility for what goes on in unmaintained/yoga 14:08:38 should we update https://releases.openstack.org/ as well? 14:08:53 so i think we should end the yoga series release notes with the last stuff we have done 14:09:10 which would be everything up to the yoga-eom tag 14:09:13 there are 43 other projects using unmaintained/yoga 14:09:32 yeah, but we Argonauts do not follow the crowd! 14:09:36 happystacker, that should be updated yes, but i guess release team will already be looking into it 14:09:44 we should be in sync even if it is technically wrong 14:09:48 oh ok good 14:10:22 not sure if frickler is around but would be good to get his opinion on this 14:10:23 rosmaita s/crowd/heard/ 14:10:28 about being in sync ... there is a bit of leeway with respect to the unmaintained branches 14:10:42 ironic, for example, wants to actively manage theirs 14:10:55 so it makes sense for them to include those changes in the official release notes 14:11:21 since we don't want to, i think we should stop our release notes with our last official actions in that branch 14:11:28 whoami-rajat: sorry having another meeting in parallel, not sure about the question? 14:11:56 frickler: has to do about whether to publish unmaintained/yoga stuff in the cinder release notes 14:12:14 i agree, the whole unmaintained thing is new so not really sure about the right thing, but what rosmaita said makes sense to me, if the project wants to be active in their unmaintained branch then unmaintained tag is good else eom should be a consideration 14:12:51 frickler, so rosmaita suggested that we should use yoga-eom instead of unmaintained/yoga as the tag since cinder team won't be actively looking after the unmaintained branch 14:12:53 yes, renos should still include unmaintained notes, at least that seemed to be the major opinion of the tc 14:13:16 we did not actually consider that issue at the TC 14:13:22 at least not that i'm aware of 14:13:47 well ok ... of tc members 14:14:04 but yeah, bring it up at the next meeting, certainly worth more discussion 14:14:36 in the meantime, i am in favor of the -eom tag, it fits more with the "opt in" nature of the unmaintained stuff 14:14:38 I'm pro the discussion but would also like the cinder gate to be fixed in the meantime :D 14:14:55 +1 14:15:06 I don't have any objections there 14:15:20 also we can always update it after the discussion 14:15:31 so +1 from me 14:15:54 +1 to which? unmaintained or eom? 14:15:59 eom 14:16:08 \o/ 14:16:18 let's do it, and we can set a good example 14:16:22 :D 14:17:04 yeah, I'm convinced with the idea that this should be an opt in based on if the project wants to maintain their branches 14:17:37 else there will be questions on releasenotes about changes that we have no idea about 14:17:41 ok, i'll update the patch (so if there are complaints, they'll be about me) 14:18:43 thanks, i can share the complaints :D 14:19:14 okay, so we will be going with the eom tag in releasenotes instead of the unmaintained one 14:19:19 ok, you can go ahead and ninja it in to get the gate un-broken 14:20:21 and i guess we have to backport it? i first notice this in looking at a stable/zed patch , https://review.opendev.org/c/openstack/cinder/+/906259 14:22:00 I remember frickler confirmed that stable branches should be automatically fixed by this 14:22:12 there is some reno magic that i have no clue about 14:22:21 but he did test it in 2023.2 branch and gate was passing 14:23:24 okay moving on to the next announcement since we have a bunch of topics lined up 14:23:24 yes, see https://review.opendev.org/c/openstack/designate/+/908290 , so please double check after merging the fix in master before doing too many patches 14:23:45 thanks frickler ! 14:23:55 next, Eventlet update 14:23:58 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/7PJZ4WYRS2B3PIZ5KYFL6V3JWYL4V5FQ/ 14:24:03 #link https://review.opendev.org/c/openstack/requirements/+/907243 14:24:05 ok, cool 14:24:14 The version 0.35.0 broke docs job in manila and now 0.35.1 is released and merged in our UC 14:24:18 The latest version of eventlet is expected to work across openstack 14:24:25 We haven't seen any failures in cinder related to it so looks good for us 14:25:03 next, oslo feature freeze 14:25:09 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/DB7EAOKIHXCULKISSFZCYTIUMEATPGQQ/ 14:25:14 deadline: R-7: Feb 12 - Feb 16 14:25:18 If you have any feature in oslo libraries, make sure it gets merged before Feb 16 14:26:21 that's all the announcements we had for today 14:26:26 anyone has anything else? 14:28:09 okay, let's move to topics then 14:28:12 #topic Improvement to cinder-backup dealing with incremental backups 14:28:15 crohmann, that's you 14:28:50 Yes. Sorry for hijacking this as a "topic". But I just wanted some quick feedback if you like the idea at all. 14:29:16 No, it's fine. 14:29:21 This is a change by someone else, removing the fetching of ALL backups to then loop over them to find the parent. 14:30:24 I reworked it and started to introduce a helper to just do a SINGLE DB query to find the suitable parent backup. I just need some guidance on using either BackupLists from objects to put the ujelp ... 14:30:41 i can see it's a very old patch from 2017 ... 14:31:03 Yeah. But we are heavy users of incremental backups, that's why I found and refactored it. 14:31:41 the idea makes sense to me, need to check the approach but should be good to include 14:31:52 The loop and all of this "in Python" logic seemed messy. 14:32:25 Just please someone use Gerrit to give me some feedback on where to place the helper funktion best and all. I finish the change quickly then. 14:34:54 That's all I wanted to ask about this one. 14:34:55 I'll take a look. But you might want to make sure eharney looks at the RBD one. 14:35:12 RBD one ? 14:37:03 Ceph has its own backup, kept in RBD. That is what their driver does. 14:37:48 Can you drop a link to the change you are referring to? 14:38:35 The change I am discussing here is just about the cinder-backup DB objects. Nothing driver specific ther. 14:39:42 https://review.opendev.org/c/openstack/cinder/+/810457 14:40:23 ahhh .. you are already talking about the next next topic ;-) 14:40:38 on 484729, openstack-tox-pep8 passed but definitely should have failed -- weird. wonder what's going on there 14:41:18 #link https://review.opendev.org/c/openstack/cinder/+/484729 14:42:15 K, so zaitcev and eharney kindly look into https://review.opendev.org/c/openstack/cinder/+/484729 :-) 14:42:30 whoami-rajat: Which topic are we then on currently. 14:42:48 crohmann, i think you have 3 topics, guess we are done with the first one? 14:43:00 more than, yes. 14:43:02 #topic DB indexes missing in backups table 14:43:10 #link https://bugs.launchpad.net/cinder/+bug/2048396 14:44:20 Also I quick one... This is a bug about the backups table not having any indexes at all. But there are likely some columns that are used quite heavily. With Caracal coming up, this is the chance to add then. 14:44:52 we should fix this, i'm interested in working on it (took the bug for now) 14:45:01 i remember geguileo did some work on indexes for some tables, but maybe backups was not a part of that effort 14:45:07 great, thanks eharney 14:45:38 eharney: Please also consider https://review.opendev.org/c/openstack/cinder/+/484729 which will data_timestamp :-) SCNR. 14:46:07 I meant to say: "will filter on data_timestamp column" 14:46:49 so this looks addressed, anything else on this topic? 14:47:12 not from me. Just did not want to miss the "C" release for this schema change ;.) 14:47:31 ok 14:47:35 #topic Cinder-Backup (rbd driver): add option to keep only last n snapshots per backup 14:47:41 #link https://review.opendev.org/c/openstack/cinder/+/810457 14:48:21 That's the one zaitcev mentioned earlier. eharney was called out to look into this one. 14:48:58 okay great 14:49:01 so last one from crohmann 14:49:04 #topic Any update on the Ceph auth / caps disucssion? 14:49:06 Review (and merge) of this feature kinda stalled. With a new comment from another operator today I got my hopes up we could get this 14:49:16 in to Caracal 14:49:38 we can surely look for reviews on that 14:51:20 but the last update was Jun 22, 2022. Would be awesome to revive the review. Let me / Jan know if there are any change required to get this merged. 14:54:50 sure, sorry it is taking long but we more or less have review bandwidth issues with contributors joining/leaving, will look more into that general problem 14:55:35 okay anything else on this? I'm planning to cover the next 2 topics quickly in next 5 minutes 14:56:02 nope. I'm good on this one. 14:56:07 great, thanks 14:56:10 #topic Third party CI compliance check 14:56:13 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/QK223RS27RYNDACTPUVJZR2REL42OC4B/ 14:56:24 I've sent out a mail to ML so vendors please take a look 14:56:30 If you are a vendor, please take a look and perform required actions before the midcycle meeting next week 14:56:39 that's all i wanted to say 14:56:46 #topic volume type extra_specs behavior 14:56:53 setting custom extra specs for volume types work, but creating a volume from it will fail during scheduling due to the need to satisfy ALL extra_specs in the backend. This works different from other resources like volumes themself. What is the desired state here? Allowing "volume type set --property customkey=customvalue" and letting the scheduler ignore this, or not allowing to set custom properties at all? 14:56:57 #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZWXFYIQ3FSFC5MGTSIMVEHCEJRQQRQ3X/ 14:57:28 with custom properties, we are talking about driver specific properties right? 14:58:03 i think it would be helpful to frame what you're wanting to accomplish with this 14:58:16 we also allow setting AZs and multiattach in the extra specs which are not related to drivers 14:58:27 i am talking about the field of "properties" or extra specs and its usage in volume types 14:59:10 so there are some cinder specific properties, like AZ and multiattach as i mentioned, and some driver specific that are checked against the capabilities that the driver reports 14:59:23 because i would like to use something in volume types to give users more uniform information about volume types 14:59:29 as eharney said, it would be easier to help if we know about the use case you are trying to achieve 15:00:13 so the use case is to try to have fields that are visible to users but not actually used for scheduling, makes sense 15:00:21 and it seems for other openstack resources, i could simply use the "properties" 15:00:26 yeah eharney 15:01:16 currently that would just have to use the description field i guess 15:02:06 okay we are out of time 15:02:12 we can continue the discussion next week 15:02:16 or on the #openstack-cinder channel 15:02:23 please take a look at the review requests 15:02:30 and next week we will have the midcycle-2 15:02:31 thks 15:02:33 so see you all there 15:02:35 thanks everyone! 15:02:37 Thank you all! 15:02:39 #endmeeting