16:00:01 #startmeeting Cinder 16:00:01 Meeting started Wed Dec 21 16:00:01 2016 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:04 The meeting name has been set to 'cinder' 16:00:06 Agenda: https://wiki.openstack.org/wiki/CinderMeetings 16:00:15 hi 16:00:17 Ping: dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylikehu mdovgal ildikov 16:00:19 hi 16:00:21 hi 16:00:23 wxy viks ketonne 16:00:24 Hello! 16:00:26 Hey everyone 16:00:26 hey 16:00:27 hello 16:00:28 hi 16:00:31 hello 16:00:50 Hello :) 16:00:54 hey 16:01:08 hi 16:01:43 #topic Announcements 16:01:56 The usual one: 16:01:57 #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Review focus 16:02:20 I think we've got some progress there on our priorities, but could always use more reviews. 16:02:32 #info Need to register for the PTG if you have not already done so 16:02:46 PTG is coming up quick. Please register if you can. 16:02:55 #link http://www.openstack.org/ptg PTG info and registration 16:02:59 smcginnis: +1 16:03:09 #info Summit call for presentations is open 16:03:26 Summit won't be too far behind. The call for presentations is open for that. 16:03:31 Cinder representation is getting better but still less than a typical midcycle. 16:03:36 Would be great to have some good storage related sessions. 16:03:42 :( 16:04:00 Hopefully folks are just waiting on (and getting) approval to go. 16:04:06 #link https://www.openstack.org/summit/boston-2017/call-for-presentations/ Summit CFP 16:04:26 And finally, 16:04:35 #info Need to start planning for the PTG 16:04:43 Started an etherpad to start planning topics to cover. 16:04:50 #link https://etherpad.openstack.org/p/ATL-cinder-ptg-planning PTG topic planning 16:05:06 Please add any topics you would like discussed at the PTG to the etherpad. 16:05:24 We will prioritize and figure out schedule closer to the event. 16:05:31 smcginnis: We can fill the list with the usual ones. 16:05:43 Like multiattach, A/A, driver deadlines. :D 16:05:48 :) 16:05:49 dulek: Hah, yep. Could probably copy paste half of the last etherpad into this one. ;) 16:06:06 smcginnis: :-) 16:06:08 Bingo? 16:06:19 diablo_rojo_phon: hummm, the bingo is a must! 16:06:19 diablo_rojo_phon: ;) 16:06:31 diablo_rojo_phon: You're in charge of prizes 16:06:37 erlon: read my mind :) 16:06:37 scottda: +1 16:06:42 And the cava 16:06:49 diablo_rojo_phon: :) 16:06:56 scottda: handles of fireball 16:07:20 patrickeast brought the Cava last time 16:07:36 OK, that's all I had for announcements. Any last minute topics, or should I just open it up for general discussion? 16:08:10 let's the holly-war begin :) 16:08:13 #topic Open Discussion 16:08:20 Bikeshedding time? :) 16:08:33 smcginnis: When will our next meeting be? :-) 16:08:40 Since I forgot to ask last time. 16:08:53 jungleboyj: Good point, I was going to bring that up before we ended. 16:09:00 :-) 16:09:10 I got your back this time. 16:09:12 I will be around next Wednesday, but I'm sure most will be busy and there won't be much going on. 16:09:25 Any objections if we skip next week and pick up in January? 16:09:53 I'll take that as a no. :) 16:09:54 smcginnis: works for me 16:09:58 *crickets* 16:10:03 ship it 16:10:06 Works for me :) 16:10:10 #info No meeting next week, will start again in January. 16:10:17 smcginnis: will you send announcement to the ML? 16:10:19 same for me 16:10:28 e0ne: Yes, I'll do that after the meeting. 16:10:38 And maybe a reminder early next week if I think of it. ;) 16:10:58 I don't think many folks are going to be around next week 16:11:05 Probably not. 16:11:06 Yeah, probably not. 16:11:21 We did discuss this patch a little: https://review.openstack.org/#/c/399003/ 16:11:27 Too much, IMO. 16:11:37 heh 16:11:37 :) 16:11:41 that 16:11:43 okey) let's discuss it again) 16:11:47 I see some value in it if something goes wrong and an admin is tring to figure out what happened. 16:12:09 geguileo: hemna Any reason we shouldn't merge that patch? You've the -1's 16:12:14 geguileo and hemna: I didn't want to approve it while you both had a -1 on there. 16:12:17 smcginnis: actually, not 'when' but 'where': on nova's side or cinder's side 16:12:21 * geguileo looking 16:12:22 I just don't see it as being as useful as the assertion in the bug 16:12:24 e0ne: True 16:12:27 it really isn't 16:12:44 hemna: Without it there's no breadcrumb to figure out what happened. 16:12:46 if you want useful information for debugging an actual attachment problem, then you enable trace logging 16:12:51 that is actually useful information 16:13:01 which is the connector, and initiator, and connection_info 16:13:11 do a votint, that only seems personal preferences :) 16:13:19 or at least debug level logging 16:13:40 to me info level seems excesive 16:13:45 it's not a big deal, but that information isn't going to really be useful for a failed attach 16:14:16 geguileo, hemna: that's the problem: all useful logs are available only in debug mode:( 16:14:27 yup 16:14:38 so make the @trace for attaches info then 16:14:41 hemna: it helps to understand that cinder works good 16:14:42 that would be useful 16:14:45 e0ne: but that's just changing the happy path 16:14:51 not the one where you get an error 16:14:56 hemna: good point 16:15:22 logging something like what he's doing in that patch isn't useful. "hey I'm attaching a volume to instance uuid." 16:15:26 is basically all that log is 16:16:18 It doesn't really hurt anything to do that, but I suppose it ends up being more noise. 16:16:20 As I mentioned in the patch, I don't think that's the right thing to do (moreover if we are going to add dynamic log changing soon) 16:16:30 jungleboyj, that's all it is, noise 16:16:43 hemna: Fair enough. 16:17:15 anyway, I can +A it, but it's just useless IMHO 16:17:34 but since we don't seem to agree on that and there are some cores who want it I think we should either vote or merge it since it has 3 +2 16:17:40 if you really want useful logging for attaches, you have attach process trace logging and make it always on 16:17:58 hemna: I don't think it's useless. I agree that is's a partial fix 16:18:10 e0ne: My thoughts too. 16:18:17 ok it's done 16:18:18 next 16:18:22 +A'd it 16:18:35 hemna: do you propose to add tracing logs for info lavel? 16:18:57 an actual attach failure isn't going to use that information. 16:19:26 hemna: +1. usually it's on the nova's side 16:19:37 Now that we've got the really important things figured out.. :D 16:19:37 hemna, thx 16:19:43 the useful information is the connector, connection_info 16:19:48 and the exceptions 16:20:25 what we should have is the ability to add certain workflow logging enabled 16:20:30 and be able to turn that on/off on the fly. 16:20:50 like....I want to debug attaches only...enable trace logging for attaches only. 16:20:56 and then turn it back off 16:20:59 w/o bouncing Cinder 16:21:03 that would be useful. 16:21:13 ok I'll shut up now :) 16:21:22 hemna: that's what the dynamic logging change will allow, right? 16:21:31 well, as a whole yah 16:21:44 unless it allows for targeted workflows 16:21:58 you don't care about volume creation debugging, but attaches, for example 16:22:04 hemna: the problem is that issue could be mot permanent and when debug is enabled we should wait for a while 16:22:26 hemna, geguileo: who is working on dynamic logging? Is there a spec 16:22:34 hemna: it's a good topic to discuss at PTG 16:22:36 e0ne: but that's the price to not have noise when everything is running fine 16:22:39 e0ne, +1 16:22:47 geguileo, yah 16:22:55 xyang2: there's a spec and I have some code (not up for review) 16:23:01 #link https://review.openstack.org/404260 16:23:02 Gorka's spec for dynamic log https://review.openstack.org/#/c/404260/ 16:23:07 thanks 16:25:36 Dynamic logging would be a nice add. 16:25:45 jungleboyj: +1 16:26:20 Hoping we can get that. 16:26:21 while we are talking about it 16:26:31 do we want it in O or in P? 16:26:35 gotta run to drop kiddo at school....bbiab 16:27:00 I would like to know to move the specs and to know if I have to keep working in the patch now 16:27:03 geguileo: I'd like it in O, but I think P is more realistic at this point. 16:27:04 geguileo: How large a change would it be? 16:27:04 or leave it for later 16:27:21 smcginnis: the code can be ready in a couple of days 16:27:29 We're past the spec freeze, though I always leave that open to core's discretion if we take things after that. 16:27:31 smcginnis: we just need to agree when we want it 16:27:41 geguileo: Will that delay the AA work though? 16:27:50 smcginnis: not really 16:27:52 Given the two, I'd rather see the HA stuff wrapped up. 16:28:13 smcginnis:i have most of the code, just need to add some tests and do more manual verification 16:28:16 geguileo: OK, if that's the case and we have at least another core or two that wants to help get this through, I'm all for it. 16:28:22 geguileo: can code 2 things at once, one with each hand. 16:28:33 scottda: I wouldn't be surprised. :D 16:28:33 lol 16:28:51 And code review on a third monitor. 16:28:53 ok, I'll get the code ready and we can decide later 16:29:07 geguileo: Cool, thanks. 16:29:10 np 16:29:36 Related to the patch that kicked this off, if we end up having better tracing I think this and many other places can be reevaluated. 16:30:36 OK, anything else to excessively discuss. :) 16:30:50 hi, joined in late... 16:31:15 I would like to discuss https://review.openstack.org/#/c/378105/11 if meeting is open for discussions 16:32:11 viks_: I think the point there was there shouldn't be any changes to v2 at this point. 16:32:18 Only to v3 and microversioned. 16:32:34 smcginnis: I am not adding any microversion to V2 16:32:48 all test cases for V2 are passing 16:33:11 viks_: I don't know why the unit tests are relevant. Like I said, no changes should be done to v2 at this point. 16:33:35 viks_: but you add unnecessary changes to v2 code 16:33:38 viks_: The point is that we should decide (as a Cinder team) if we are making any changes to v2 API. Especially if it's just a refactor. 16:33:57 IMO V2 API is not changing 16:34:21 the code refactoring..is it really a big issue 16:34:21 smcginnis: to be clear: no changes that change v2 API. we can change code and fix bugs as well 16:34:27 if everything is working fine 16:34:50 e0ne: Yes, that is a better/more accurate statement. 16:34:58 IMO it is not intriducing any new bugs and not stopping any prev finctionality 16:35:09 viks_: You're changing v2 API behavior by adding filtering. 16:35:20 viks_: the tricky thing about bugs, is that you don't see them comming 16:35:23 We don't know of any new bugs. But there is always a chance bugs are introduced when you change code... 16:35:36 scottda: +1 16:35:37 viks_: so if you are making changes to the code, even a simple refactor, you may be inadvertedly introducing bugs 16:35:39 that is why we have unit tests and test cases 16:35:39 scottda: +1 16:35:57 viks_: and in a perfect world we would catch everything there 16:36:01 but we know we don't 16:36:02 viks_: Please look at launchpad for a list of bugs that exist, even though unit tests passed. 16:36:12 scottda: +1000 16:36:15 so that's why we prefer not to touch v2 api at all 16:36:21 whenever it's possible 16:36:24 the same code got +2 previouly... 16:36:37 viks_: but you should be able to introduce the feature just touching v3 api, right? 16:36:38 viks_: our code is not ideal 16:36:49 viks_: I think if you remove the v2 changes, the rest should be better. I haven't reviewed it, but otherwise the change should be OK. 16:36:54 viks_: there are a lot of things to improve 16:37:06 viks_: you just need to change the items method in v3 16:37:15 smcginnis, viks_: I'll +2 on it once changes to v2 will be removed 16:37:26 I will as well 16:37:50 I dont know..it was not about that 16:38:04 I thought I refactored the code for beteerment 16:38:21 if we take a look at volume metadata filtering it is the same 16:38:34 but looks like everyone is against it 16:38:34 viks_: Yes, I appreciate that you were trying to make it better. But not sure how many different ways we can say that v2 should not be changed. 16:38:34 viks_: why do you need to refactor that so much? 16:38:38 viks_: We get that you were refactoring the code to make it better, but we do not wish to change the v2 code for just a refactor 16:38:43 viks_: if it wasn't old code the refactoring would have been welcomed with open arms 16:38:58 viks_: but as the saying goes: better the devil you know 16:39:04 viks_: TBH, you've added useless code to v2 like '_get_snapshot_filter_options' method 16:39:14 viks_: I humbly suggest that you just remove the v2 code changes, and put them all in v3. We will approve and we'll all be done. 16:39:18 I prefer to do refactoring in a separate patch 16:39:20 Ok... 16:39:36 thanks 16:39:46 I will do it 16:39:52 viks_: Thank you. 16:40:03 :) 16:40:17 if somebody wants to save me from merging hell, please, review https://review.openstack.org/405258 and https://review.openstack.org/400963 16:40:48 Anything else we need to discuss as a group? 16:40:53 e0ne: I feel your pain. 16:41:02 scottda: :) 16:41:16 Oh, I also wanted to point out the non-client library freeze will come up quick after the holiday break. 16:41:17 eharney: Are you around? 16:41:28 If there's anything we need in os-brick, we better get that through quickly. 16:41:37 hey 16:41:43 smcginnis, so please review brick patches :) 16:41:50 hemna: ;) 16:41:57 eharney: You'd already +2'd "replace AssertDictMatch". So I was waiting for you to look again.. 16:42:02 sure, will do 16:42:10 * e0ne will review os-brick patches tomorrow as a top priority 16:42:13 hemna: Did you already bring your kids to school? Are you across the street or something? :) 16:42:49 yah brought my kiddo to school and got back :) 16:42:54 eharney: Same with the v2/v3 cinderclient refactor, I guess. 16:42:55 You're quick! 16:43:03 :) 16:43:20 OK, anything else worth discussing in the meeting? Or should we move along? 16:43:33 scottda, eharney: for note: I'm going to do few more patches according to v1-v3 api support later 16:43:57 e0ne: Please visit python-brick-cinderclient-ext patch too. 16:43:58 I just don't want to have fun with chain like geguileo does 16:44:00 e0ne: Yeah, that's great. We can remove most of that duplicated code. 16:44:12 lol 16:44:21 s/we can/you can/ 16:44:22 :) 16:44:29 OK, thanks everyone. Have a good holiday break, if you're having one. :) 16:44:36 scottda: TBH, the current patch doesn't remove a lot of duplicated code. but I'll do it in a next one 16:44:42 If you're not, well, have a good quiet stretch anyway. :) 16:44:50 Thanks! Merry Christmas and Happy New Year to everyone! 16:44:58 e0ne: Yeah, I get it. But it sets things up for the next series. 16:45:05 Festivus for the rest of us. 16:45:08 scottda: yep 16:45:16 Let's all sing some carols! 16:45:29 That's a scary thought. :D 16:45:42 #endmeeting