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