15:06:24 #startmeeting cinder_bs 15:06:25 Meeting started Wed Mar 17 15:06:24 2021 UTC and is due to finish in 60 minutes. The chair is enriquetaso. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:06:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:06:28 The meeting name has been set to 'cinder_bs' 15:06:33 #topic roll call 15:06:38 hi :P 15:06:38 hi 15:06:40 o/ 15:06:56 Etherpad: 15:06:56 #link https://etherpad.opendev.org/p/cinder-bug-squad-meeting 15:07:20 Full list of bugs: 15:07:22 #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021135.html 15:07:56 #topic bug_1:"SADeprecationWarning: The joinedload_all() function is deprecated, and will be removed in a future release. Please use method chaining with joinedload() instead" 15:08:02 #link https://bugs.launchpad.net/cinder/+bug/1832164 15:08:04 Launchpad bug 1832164 in Cinder "SADeprecationWarning: The joinedload_all() function is deprecated, and will be removed in a future release. Please use method chaining with joinedload() instead" [Critical,In progress] - Assigned to Gorka Eguileor (gorka) 15:08:21 wanted to name the bug because it is in critical condition but it is already handled by Gorka. 15:08:23 rosmaita: thanks for your detailed comments on CI, Im applying fixes right now 15:08:32 that one illustrates a point eric made last week 15:08:45 namely, we need to review some old bugs 15:09:04 rosmaita++ 15:09:04 enriquetaso: i can make it un-critical 15:09:06 My idea was to do an update of the old bugs but I could not do it for this week, I will prepare it for the next and maybe some for the PTG if they are important. 15:09:23 yeah, i am not saying that you personally need to do it 15:09:27 Fix proposed: 15:09:29 just that "we" need to do it 15:09:32 #link https://review.opendev.org/c/openstack/cinder/+/780755 15:09:45 rosmaita sure 15:10:05 so the story is that sqlalchemy 1.4.0 drops that joinedload_all call 15:10:14 and 1.4.0 was released on monday 15:10:24 and our docs job was using it and breaking 15:10:39 in the mean time, 1.4.0 is not included in upper-constraints 15:10:59 our doc job was ignoring upper constraints (sort of) 15:11:10 so, we have fixed our jobs to respect upper constraints 15:11:31 what i am saying is that it is important that we fix this, because we will be broken in xena 15:11:42 but it is not as critical as i thought yesterday 15:11:51 and now i will shut up 15:11:52 ohh 15:11:57 well, it's a pretty simple change 15:12:15 thanks rosmaita for the details \o/ 15:12:36 The following bug is already assigned and is being worked on, but I wanted to highlight it in case someone is using quotas. 15:12:51 #topic bug_2: "Automatic quota refresh counting temporary volumes" 15:12:59 #link https://bugs.launchpad.net/cinder/+bug/1919161 15:13:00 Launchpad bug 1919161 in Cinder "Automatic quota refresh counting temporary volumes" [High,New] - Assigned to Gorka Eguileor (gorka) 15:13:08 'When using the automatic quota refresh via `until_refresh` and `max_age` configuration options the calculated quota usage by the refresh will not be correct if there are temporary volumes (such as those created from snapshots for backups)' 15:13:39 I couldn't find a patch for ^ so I think it doesn't have one yet 15:14:11 Moving on... I need an opinion on next one: 15:14:23 #topic bug_3: "id of encryption for volume type not verified" 15:14:28 #link https://bugs.launchpad.net/cinder/+bug/1918879 15:14:29 Launchpad bug 1918879 in Cinder "id of encryption for volume type not verified" [Undecided,New] 15:14:37 The description of the bug just says "when try to update encryption for a given volume type, this api received one parameter is id, but it is not used,therefore, when it is a wrong encryption id, the api layer not check". 15:14:38 I guess the bug is incomplete, I'd like to ask about steps of how to reproduce the problem and probably if It's using LUKS or something else. However, I've never updated a volume type before so I'd like to be double sure about what to ask. 15:14:55 proably https://review.opendev.org/c/openstack/cinder/+/779436 15:15:53 great 15:16:36 enriquetaso: i think start by asking exactly what api call, what they are passing in the request, and also what release they are talking about 15:18:30 #action enriquetaso: ask for more detailed information 15:18:46 next one: 15:19:03 #topic bug_4: "ensure_export model_update ignored" 15:19:08 #link https://bugs.launchpad.net/cinder/+bug/1918449 15:19:09 Launchpad bug 1918449 in Cinder "ensure_export model_update ignored" [Wishlist,Incomplete] 15:19:20 "The volume manager calls the driver's ensure_export() at startup time. There are several volume drivers that return a model_update from ensure_export, but the volume driver ignores that model_update." 15:20:02 I set the importance to wishlist, should I change it to medium? 15:20:17 this still needs some justification that it is really a bug, and we need a discussion/decision about whether drivers should really be returning updates from ensure_export calls 15:21:05 likely to end up as a ptg discussion i guess 15:21:10 Yes, please read Eric's comment 15:21:57 before we resolve this bug, we really need to resolve: "how exactly does the ensure_export driver API behave?" which seems to be up in the air a bit 15:22:26 https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L1430 15:22:49 so the other ones explicitly say " can optionally return a dict of changes", this one does not 15:23:10 right, and we have had code for ages that does not accept a return dict from it 15:23:29 so it seems reasonable to start at the idea that it probably shouldn't be updating things that require it to return a dict, etc 15:23:46 i agree 15:23:58 which goes back to the questions i was asking before: why exactly should we _start_ doing that? still unclear 15:24:25 so, it's a good topic for the next PTG 15:25:27 OK.. 15:25:30 #topic Open Discussion 15:25:36 https://bugs.launchpad.net/cinder/+bug/1298135 15:25:37 Launchpad bug 1298135 in Cinder "Cinder should handle token expiration for long ops" [Medium,Confirmed] 15:25:49 can we discuss this ? 15:25:55 sure 15:26:09 #link https://bugs.launchpad.net/cinder/+bug/1298135 15:26:17 "Cinder should handle token expiration for long ops" 15:26:29 so cinder <-> nova and cinder <-> glance support service_token 15:26:36 cinder <->swift does not.. 15:27:07 so I added that support and sent service_token to swift, modified swiftclient to consider session to talk with keystone middleware. 15:27:24 however this does not work. and token expiry trigger 401 Error. 15:27:25 i'd like to understand why it does not 15:28:38 the swift proxy-server validates token for each backup chunk and it talks with keystone middleware to validate token.. This report failure as invalid token because its expired. 15:28:40 * enriquetaso likes the tag 'bugsmash' :P 15:29:08 So, I see two ways to solve it: 15:29:09 1) Either patch both Cinder and Swift to support service_auth and its tokens. 15:29:09 2) Or use Keystone trust and refresh tokens like Glance already does for long running image uploads. 15:30:14 my general sense is that this shouldn't require patching Cinder and Swift 15:30:47 eharney can you try this experiment. may be I am doing incorrect steps. 15:30:50 i'm not sure what the current status of keystone trusts is 15:30:58 i'm not sure that keystone trusts are needed for this 15:31:27 i don't think we use trusts for service tokens used to talk to nova from cinder, do we? 15:31:45 no trusts only used for glance <->swift 15:31:48 its not in cinder 15:32:08 ok for option 1.. add expiration in keystone.conf e.g. 100 seconds and try to upload backup of 2GB in swift. 15:32:28 i think there's more to it than that 15:32:29 ok, so that's a problem right there 15:32:36 i.e. the details in https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html 15:32:38 the service tokens also expire 15:32:42 right. 15:32:47 forgot to mention 15:33:06 u need to add [service_user] section and respective support in cinder/backup/drivers/swift.py 15:33:42 please update bug if it works for anyone whoever can try. 15:34:20 OK, i need to end the meeting 15:35:44 the last update was in 2019 15:36:07 oh meant to mention this one: https://bugs.launchpad.net/oslo.db/+bug/1814199 15:36:09 Launchpad bug 1814199 in Cinder "soft_delete is wrong" [High,In progress] - Assigned to Gorka Eguileor (gorka) 15:36:24 sure 15:36:45 this is another old one that gorka has a patch up for 15:36:56 #link https://review.opendev.org/c/openstack/cinder/+/776974 15:37:03 so there's probably not much to say about it 15:37:04 Fix proposed ^ 15:37:15 other than i promised gorka that i would review it 15:37:32 #action review https://review.opendev.org/c/openstack/cinder/+/776974 15:37:37 thanks! 15:37:56 it's a bit more complicated than that other sqlalchemy patch 15:38:34 I'll try to reproduce the bug kinpaa12389, but i'm not familiar with the topic 15:39:16 rosmaita++ 15:39:18 kinpaa12389: you may not see much action on that until after RC-time 15:39:36 we kinda have our hands full at the moment 15:39:47 true.. 15:39:59 OK, thank you all! 15:40:00 #endmeeting