16:00:15 #startmeeting Cinder 16:00:16 Meeting started Wed Oct 24 16:00:15 2018 UTC and is due to finish in 60 minutes. The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:20 The meeting name has been set to 'cinder' 16:00:25 o/ 16:00:25 @! 16:00:25 <_pewp_> jungleboyj (^-^*)/ 16:00:26 hi! o/ 16:00:43 o/ 16:00:49 This week's agenda: https://etherpad.openstack.org/p/cinder-stein-meeting-agendas 16:00:55 #link https://etherpad.openstack.org/p/cinder-stein-meeting-agendas 16:01:18 <_alastor_> ol 16:01:40 hello 16:02:10 Give people another minute to collect. 16:02:18 hi 16:02:19 hello 16:02:25 jungleboyj: we miss the pings ;-) 16:02:31 hi 16:02:37 geguileo: I know. Is it safe to do again? 16:02:49 no idea, you can always try.... };-) 16:03:34 courtesy ping: erlon tpsilva ganso patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut lseki _alastor_ whoami-rajat yikun 16:03:45 Oooh, am I still alive? 16:03:49 yay!!!! 16:03:54 \o/ 16:03:56 you are!! 16:04:23 maybe they turned that off? 16:04:25 Ok, I guess I can ping people again if people would like that back. 16:04:35 jungleboyj: ++ 16:04:45 rosmaita: And now you are on the list. 16:04:50 jgriffith: Hey buddy! 16:04:59 jungleboyj: maybe log in with a dummy account for the ping just in case ;0 16:04:59 Ok. Lets get started. 16:05:06 #topic announcements 16:05:40 First announcement Happy Birthday to _hemna or hemna Which ever gets his attention. :-) 16:06:22 I have gotten the Berlin Forum Etherpads put together: 16:06:35 #link https://wiki.openstack.org/wiki/Forum/Berlin2018 16:06:59 Right now the etherpads are just a copy of what we put down for our proposals. 16:07:40 If you have anything on the topcs: Data Service, Role in Edge Computing or User Survey Feedback. Please add something. 16:08:02 Who all is going to be in Berlin? 16:08:10 +1 16:08:11 I will be. I know smcginnis will be. 16:08:15 Yep 16:08:19 e0ne: Excellent! 16:08:26 i am staying home and having a jelly doughnut 16:08:43 rosmaita: Ich be ein berlinner? ;-) 16:08:45 jungleboyj: I'll be there 16:08:50 geguileo: Yay! 16:08:58 eharney: I think is also going to be there. 16:09:35 jungleboyj: I think so 16:09:37 Ok, so we have at least a few of us there for the technical talks. 16:09:48 Otherwise I will just fake it. 16:09:58 :) 16:10:21 Anyway, please go update the etherpads with thoughts whether you will be there or not. 16:10:37 I will record the sessions like I did in Vancouver. 16:10:46 Does anyone want me to do hangouts for these? 16:11:23 Most of the sessions are on Tuesday afternoon. 16:11:38 i'm ok with just recordings 16:12:01 Ok, if no one is jumping up and down for hangouts I won't plan to do that. 16:12:24 Moving on. 16:12:36 I have proposed stable/rocky release 13.0.1 . 16:12:47 Lots of good bug fixes backported so it will be good to get that out. 16:13:19 So, I think that is all I have on for announcements. 16:13:45 #topic Review of responses to User Survey Feedback 16:14:10 So, I was hoping to get some thoughts organized this week. I did not so my goal is to start getting some info into the etherpad. 16:14:21 #link https://etherpad.openstack.org/p/BER-Cinder_User_Survey_Responses 16:14:44 Hopefully more to discuss here next week. 16:15:18 #topic Volume Revert-Snapshot Follow-up 16:15:27 erlon: You around? 16:16:22 yikun: Looks like you have actually been tackling this. 16:16:29 So, a little explanation ... 16:16:45 tommylike has unfortunately been moved on to other responsibilities. 16:16:56 yeah, see https://bugs.launchpad.net/cinder/+bug/1798503/comments/2 16:16:56 Launchpad bug 1798503 in Cinder "When reverting volume to smaller snapshot size is incorrect" [High,In progress] - Assigned to Yikun Jiang (yikunkero) 16:17:01 yikun: Is going to be helping backfill his Cinder responsibilities. 16:17:08 : ) 16:17:16 So, a warm welcome to yikun 16:17:22 ha, thanks. 16:17:32 Welcome. 16:17:36 <_hemna> jungleboyj: thanks man :) 16:17:37 welcome!! 16:18:19 So, it looks like we were in agreement that there is a bug and the fix is in process. 16:18:20 geguileo: thanks, :) 16:18:34 * jungleboyj sings Happy Birthday to _hemna 16:18:40 hemna: 🎂 16:18:59 :-) 16:19:06 <_hemna> :) 16:19:09 jungleboyj: Yep, I think that was an oversight that we didn't prevent that from happening. We talked about preventing it during the spec review. 16:19:38 jungleboyj: yes, and I think @erlon know and agree it, and I find his +1 on the patch. 16:20:03 #link https://review.openstack.org/#/c/611491/ Ok, see the review. 16:20:07 Will take a look at it. 16:20:17 Think it is good to go with what the Spec designed. 16:21:42 Ok. So, I think we can move on. 16:21:59 #topic Automate Generation of api-ref sample files in Cinder 16:22:13 #link https://docs.openstack.org/nova/latest/contributor/api.html#functional-tests-and-api-samples 16:22:26 I am not sure who added this topic. 16:22:47 I think it might have been whoami-rajat but he doesn't seem to be here. 16:23:34 I haven't looked over the link, but I think the gist of it is Nova generates api-ref samples using a job that extracts actual response bodies. 16:23:44 If that's the proposal, I'm all for doing the same. 16:24:01 smcginnis: Yeah. That was the goal. 16:24:03 +1 16:24:13 I think gmann was the one noting that it is something we could do. 16:25:32 I didn't think anyone would have a problem with that approach. Also good to keep parity between Cinder and Nova where possible. 16:26:01 Just a matter of getting someone to implement it which I think whoami-rajat was going to look into. 16:26:06 So, I will follow up with him. 16:26:33 #action jungleboyj to follow up with whoami-rajat 16:26:48 #topic Improve volume transfer records 16:26:49 I assume we have to manually update the parameter list with descriptions still though. 16:26:56 But at least if the examples are accurate, that helps. 16:27:03 smcginnis: ++ 16:27:07 i like this comment, "The functional API samples tests are not the simplest thing in the world to get used to, and can be very frustrating at times when they fail in not obvious ways" 16:27:18 something to look forward to 16:27:23 *smh* 16:27:25 Hah 16:27:37 At least they are honest. 16:27:56 yikun: Your topic. 16:28:09 thanks, and this spec want to add ``original_project_id`` and ``current_project_id``, ``accept`` fields to 16:28:09 ``transfer`` table to help admins trace the owner info and the transfer accepted info. 16:28:21 and the spec is just an initial draft, and some more detail needs to be completed. 16:28:31 If you guys are interested, you could take a look and give us some suggestion. :) 16:28:46 #link https://review.openstack.org/#/c/612866/ 16:29:20 I think that could be useful. 16:29:35 Sounds like something to consider to me. 16:29:39 We may need to think about that data growth if we don't get rid of those records though. 16:29:54 Not sure how much transfers are used in some clouds, but that would grow over time. 16:30:07 <_hemna> seems like a good idea 16:30:30 Is it something that could be added to the DB cleaning process? 16:32:09 So, doesn't seem to be any immediate concerns. Just need to get reviews on the Spec? 16:32:41 Ok. So. 16:32:48 yeah, just want your idea on it, :) 16:32:51 #action team to review the spec. 16:33:28 Anything else yikun ? 16:33:38 ok, thanks, that's all. :) 16:33:49 Thanks yikun . 16:34:19 #topic Explicit disable volume creation with multiattach=True for Ocata and Pike releases 16:34:25 e0ne: Your floor. 16:34:33 jungleboyj: thanks :) 16:35:03 so, we've got multiattach released in Queens 16:35:16 but there is some code in older versions too 16:35:19 e.g.: 16:35:38 in pike we check multiattach capability in a shceduler 16:35:48 Right. 16:36:12 in ocata - everybody can pass '--allow-multiattach` flag to volume 16:37:29 but we don't officially support this before Queens 16:37:39 it confuse users 16:38:01 they are trying to create volume for multiattach 16:38:06 Yeah. That is kind of confusing. 16:38:30 and I do understand, that in ideal world everybody should upgrade their clouds to the latest version 16:38:40 but it doesn't work :( 16:38:42 He he he. 16:38:58 e0ne: should we just modify the client to only pass that when the server supports the microversion? 16:39:28 Or is it that the API is accepting it even though the feature is not completed? 16:39:46 geguileo: I don't think it is something that we want to silently ignore. 16:39:51 I do remember hearing one or two users that somehow were using the multiattach flag with those older releases. I think maybe with their own hacks. 16:39:58 IMO, if we can return 400 Bad request Multiattach isn't supported until Q - it'll help users to understand what's going 16:40:05 But I don't think we have to support private hacks at the expense of confusing everyone else. 16:40:15 e0ne: that sounds reasonable to me 16:40:20 smcginnis: Yeah, I think PowerVC customers were using that. 16:40:24 e0ne: Yeah, I think that's OK. 16:40:25 smcginnis: +1 16:40:42 smcginnis: +2 16:40:46 great to know that we're on the same page 16:40:53 e0ne: I think that is good. 16:41:07 And if the people who hacked it in need it they can remove that check too. 16:41:16 jungleboyj: Exactly. 16:41:23 I'll provide a patch for Ocata and maybe for Pike this week 16:41:26 jungleboyj: +1 16:41:33 e0ne: thanks 16:41:35 Just to play devils advocate... 16:41:46 Uh oh. :) 16:41:55 does that mean that any "unsupported" type/extra-spec entry should have a similair check? 16:42:04 I'm afraid, that it'll affect our customers too, but It's better to get this move explicit 16:42:28 jgriffith: This one wasn't the extra spec approach though, right. Just the explicit flag on create. 16:42:34 I think it is better to improve the user experience. 16:42:43 jgriffith: TBH, I didn't dig intho tthis part for Pike yet 16:42:52 jungleboyj: +1 16:42:54 :) 16:43:21 It's the boolean parameter to the create call here - https://developer.openstack.org/api-ref/block-storage/v3/index.html?expanded=create-a-volume-detail#id87 16:43:46 We should probably improve that description. 16:43:58 And by approve, I think I mean delete the whole thing. 16:44:04 LOL 16:44:27 smcginnis: Loves deleting code. 16:44:30 smcginnis: AFAIR, this option is already deprecated 16:44:36 jungleboyj: Yes I do! 16:44:54 #link https://github.com/openstack/cinder/blob/master/cinder/api/v3/volumes.py#L342 16:44:56 e0ne: Yeah, we just don't indicate that in the api-ref. So maybe just removing it would cause less confusion. 16:45:14 smcginnis: good point, I agree with you 16:45:20 The only problem is that IIRC folks like gophercloud may be exploiting that flag in older versions... let me look 16:45:23 I think in the last major version bump of cinderclient we removed it too. 16:45:48 jgriffith: I'm afraid that you're right :( 16:46:30 Ah, marked deprecated in the client - https://review.openstack.org/#/c/586296/ 16:46:34 jgriffith: I just hit this issue with Ocata and Gophercloud (K8S) 16:46:41 LOL 16:47:34 good enough 16:49:08 So, how do we want to go forward here? 16:49:14 Anything we need to do for gophercloud? 16:49:34 Can we gopher it? 16:50:04 https://media.giphy.com/media/vkS5sVdreVWUg/giphy.gif 16:50:06 I think it's probably ok; my only thing is going back versions and changing behaviors typically doesn't end well 16:50:10 even if it's the right thing to do 16:50:22 jgriffith: Yeah, this is kind of iffy as far as stable policy goes. 16:50:46 that's why I bring this topic to meeting before I proposed a patch 16:51:12 e0ne: so refresh my memory, what horrible fate awaits those on O that try this? 16:51:26 Good question. 16:51:58 I thought it set the property of the volume object, but didn't actually do anything. 16:52:12 jgriffith: you can create a volume with multiattach=True but it wont work as expected 16:52:20 so clearly going forward we've deprecated it and should remove it clearly 16:53:05 So we don't normally remove features in stable branches. But this "feature" doesn't actually do anything, so... 16:53:11 e0ne: My vote would be to log an error and leave it; if somebody is using it they can ignore the error. But removing it from old versions is out of policy IMO 16:53:20 smcginnis: yeah, I hear ya 16:53:30 jgriffith: Yeah, I think you're right. 16:53:35 Ok, I'll shut up now and go with what the smart people in the room decide :) 16:54:08 :) 16:54:08 I think to follow stable policy, we need to leave it in the older releases, even if it doesn't do anything. 16:54:18 So maybe the best answer is to just make it clear that nothing is happening in the logs? 16:54:21 smcginnis: I'm afraid so 16:54:26 jungleboyj: +1 16:54:30 smcginnis: ++ 16:54:32 <_hemna> sounds reasonable 16:54:39 ok, fair enough 16:54:46 We at least leave them bread crumbs 16:55:10 Toasty, with a hint of garlic. 16:55:31 smcginnis: :) 16:55:45 Mmmmmm. 16:55:57 Outback Croutons. 16:56:33 So, I think the answer is that we add a log message that clearly indicates that the option you are using is doing nothing. 16:56:39 Everyone in agreement? 16:56:45 That works for me. 16:57:02 Do our best to improve UX without breaking policy. 16:57:06 And if someone is doing something funky downstream, they can just remove that logging. 16:57:24 smcginnis: ++ 16:57:29 jungleboyj, smcginnis : +1 16:58:21 Ok. Good. So that gets us through the agenda with 2 minutes left. 16:58:31 Should we wrap up a little early? 16:58:51 open discussion? 16:59:02 * e0ne is joking 16:59:03 #topic open discussion 16:59:07 :) 16:59:10 You have less than one minute. Go. 16:59:16 :-) 16:59:24 Ok, thanks everyone for joining. 16:59:31 Thanks! 16:59:32 Have a great week and talk to you all next week! 16:59:33 see you next week 16:59:41 #endmeeting