16:00:01 #startmeeting Cinder 16:00:02 Meeting started Wed Jan 7 16:00:01 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 The meeting name has been set to 'cinder' 16:00:10 hi all 16:00:11 Hi 16:00:16 Hello! 16:00:17 hi 16:00:18 hi all 16:00:19 Hi! 16:00:21 hi 16:00:31 hi 16:00:34 hi 16:00:39 agenda items for today 16:00:42 #link https://wiki.openstack.org/wiki/CinderMeetings 16:01:02 first off I wanted to point people to the new cinder review dashboard 16:01:05 #link https://wiki.openstack.org/wiki/Cinder#Review_Links 16:01:12 click the Cinder review inbox link 16:01:29 make sure you're logged in and enjoy more managable review list 16:01:46 give me feedback on it at #openstack-cinder 16:02:15 also keep in mind of kilo-2 deadline https://launchpad.net/cinder/+milestone/kilo-2 16:02:42 february 5th. A lot of bps are not started. I will be bugging you for an update and potentially punting 16:03:11 #topic What makes a unit test valid? 16:03:13 #link https://bugs.launchpad.net/cinder/+bug/1404339 16:03:15 Launchpad bug 1404339 in cinder "Unit tests for zfssa driver don't actually check anything" [Undecided,In progress] 16:03:16 jgriffith: you're up 16:03:23 thingee: thanks 16:03:33 So I just wanted to touch on something real quick 16:03:46 hi 16:03:49 our unit tests need serious love 16:04:10 the definition of a unit test is something that tests the smallest possible unit of code 16:04:13 like a method 16:04:21 o/ (late) 16:04:35 we've got a number of tests that actually excercise multiple modules 16:04:43 jgriffith: +1000 16:04:48 jgriffith: +1 16:04:56 also the easiest way to test error path logic / syntax errors 16:05:05 jgriffith: are you talking about driver unit tests or core unit tests? 16:05:14 bswartz: all of the above 16:05:29 jgriffith: +1,000 16:05:39 also keep in mind that you may be clever but if nobody else knows how the hell your unit test works you're not that clever 16:05:44 you're just annoying :) 16:06:07 I plan on spending some time doing some cleanup in the coming weeks 16:06:10 another thing jgriffith and I were talking about earlier this week than thangp's object work showed is that we inconsistent mocks of volumes, snapshots etc 16:06:18 Also expect me to be much more picky in reviews 16:06:27 thingee: :) 16:06:33 But are pure unit tests actually useful at all? 16:06:43 Most of the things we screw up are interfaces 16:06:44 DuncanT: yes IMO 16:06:47 DuncanT: absolutely if done correctly 16:06:57 DuncanT: sadly what we have now I argue is not useful 16:07:03 it doesn't actually test much 16:07:07 I'd agree there 16:07:12 jgriffith: +1 16:07:17 except the test code and how well the writer understands mox or mock 16:07:23 Anyway.... 16:07:32 jgriffith: so if someone wanted to sign up to help you.... 16:07:35 the other thing was about fake resource objects 16:07:36 I just think that a unit test can helpfully test up to two modules or functions, not just one 16:07:47 Like I mentioned in eariler meeting, we need better UT coverage 16:07:55 I'll keep my eye on your work though 16:07:58 winston-d: +1 16:08:06 ok.... so places to help? 16:08:19 low hanging fruit would be common fake objects 16:08:33 currently each test has it's own "fake volume" or whatever 16:08:46 and it has just one or two fields (those needed for the test) 16:09:00 I'd like to see a set of common fake objects that are fully populated 16:09:06 jgriffith: +1 16:09:11 and see those used/shared 16:09:23 should some code coverage % be required? 16:09:33 Also unit tests that call other unit tests are no good IMO 16:09:39 jgriffith: good idea, i like it:) 16:09:49 kmartin: honestly way earlier when I started in this project, I was strict on that in reviews, but I received backlash on that. 16:09:54 o/ 16:09:57 jgriffith: do we got such tests? 16:10:05 jgriffith,thingee: for test coverage, how about posting the lowest 5/10 modules regularly 16:10:11 e0ne: we do :( 16:10:22 oh no.... :( 16:10:24 kmartin: our internal line for UT is 80% 16:10:46 anyway, I don't want to take up a ton of time 16:10:53 wanted to raise awareness 16:10:55 kmartin: Nova, Swift, Neutron are all above 80%, sadly cinder only has < 75% 16:10:55 winston-d: our internal unit tests is 100% :P 16:11:03 get people thinking about it going forward 16:11:07 winston-d: what's the command to check coverage %? 16:11:18 winston-d, ok should we not hold drivers to that as well? 16:11:26 It is far too easy to game a minimum coverage level 16:11:28 xyang1: ./run_tests.sh -c 16:11:28 jgriffith: sounds good. We should have a plan of some sort...unit tests being broken is a giant thing. I think it would help if others pitched in to you help you 16:11:42 winston-d, kmartin: we need to be vary careful with covrage and separating tests as unit or functional, imo 16:11:47 winston-d: thanks 16:11:49 reviewers should just be paying strong attn to tests... there are plenty of papers about the downsides of enforced coverage 16:11:49 kmartin: i usually run coverage on driver reviews and -1 if they are too low, but we don't define what too low is 16:11:52 thingee: yeah.... lemme see if I can come up with a plan 16:11:59 It is better to have less coverage but have it quality, than 100% coverage of useless tests 16:12:04 bring it back at next meeting, or maybe at mid-cycle meetup? 16:12:13 #agreed improve unit tests 16:12:15 :) 16:12:21 DuncanT: I sense you're in a contrary mood today :) 16:12:32 #action jgriffith will come up with a plan to make improvements in bite size pieces 16:12:35 :) 16:12:50 cool that's all for now I think 16:12:56 thanks jgriffith 16:13:05 My next topic is a noop now I think 16:13:08 jgriffith: I've always felt unit tests are the least useful form of testing, and always felt I'm probably missing something, but if I aam then so are most people writing the tests 16:13:10 jgriffith: i hope, you'll do it up to next meeting:). not everybody could attempt mid-cycle meetup 16:13:19 #topic Game plan for seperation of target drivers 16:13:22 DuncanT: right, we can be tougher reviewing UT, hopefully that can help gating the UT quality. 16:13:23 #link https://review.openstack.org/#/c/135139/ 16:13:26 jgriffith: around? :) 16:13:28 e0ne: understood 16:13:30 LOL 16:13:33 :_ 16:13:35 :) 16:13:55 So I added that before the Holiday 16:14:04 patch has merged so we're at phase 2 16:14:15 big shout out to mtanino for finding some bugs already 16:14:32 TBH I had a hell of a time trying to keep that thing up to date and merged 16:14:35 hi. 16:14:44 so I'm unfortunately expecting some hidden gems 16:15:11 * thingee is behind on bugs from yesterday 16:15:12 mtanino: I'll look at that latest patch again this morning 16:15:21 mtanino: and sorry, I hadn't realized you assigned the bug to yourself 16:15:24 jgriffith: I assume these bugs are already posted on LP 16:15:33 thingee: indeed (2) 16:15:38 jgriffith: no problem :) 16:15:59 jgriffith: so what's next phase? 16:16:07 anyway, I initially proposed that topi becuase I was getting overwhelmed with the merge conflicts 16:16:18 thingee: that depends :) 16:16:45 thingee: ideally connection releated calls in the manager would be setup to be able to go directly to the target driver 16:16:48 BUT.... 16:17:00 that requires a ton of thrash on all the drivers, so probably not worth it 16:17:18 jgriffith: I anticipate k-2 being dedicated to bug fixing for this. 16:17:25 I think the next thing to do is let it bake and start some optimization 16:17:25 k-3 I think won't be good time for it 16:17:49 thingee: there shouldn't be *that* many bugs :) 16:18:15 anyway... I think it's better now to tweak whats there for K 16:18:27 revisit at summit if we want to go a step further with it 16:18:33 sounds good 16:18:58 #action mtanino and jgriffith to do bug fixing on target driver related code 16:19:05 jgriffith: anything else? 16:19:18 thingee: nah, I'm good... thanks!!! 16:19:26 #topic Update on Oslo namespace changes 16:19:29 jungleboyj: hey 16:19:32 #link http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/drop-namespace-packages.rst 16:19:33 Howdy! 16:19:59 So, I feel like I maybe need to be more proactive with communication from Oslo. So here I am. :-) 16:20:16 I apologize for the issues that popped up unexpectedly yesterday. 16:20:31 Wanted to make people aware of what is going on. 16:20:59 So, the oslo packages are all changing their namespace. I.E. oslo.config -> oslo_config . 16:21:29 This is happening because of a number of issues that oslo has been having with the current approach. You can see the link above for details. 16:21:54 jungleboyj: namespace colisons? 16:22:08 What this means is that they are going to be release new library versions that move to using the new namespace. They are releasing with shims that allow the old oslo.config format to work for now. 16:22:17 jungleboyj: not true... please don't confuse things here 16:22:42 oops... wrong person/window 16:22:44 sorry :) 16:22:48 ? 16:22:54 jgriffith: Ok. Good. 16:23:03 :) 16:23:11 * jgriffith got busted not paying attention in classs 16:23:19 jungleboyj: sounds like a plan 16:23:21 navneet: It is due to issue with setuptools. 16:23:53 So, I am going to be pushing changes up as they release to new libraries to use the new namespace so we aren't dependent upon the shims. 16:23:57 #action jungleboyj to change oslo.concurrency -> oslo_concurrency and oslo.config -> oslo_config 16:24:04 jungleboyj: anything else? 16:24:25 Also, please be aware as the new libraries are released we may run into other breakages like the one we saw yesterday. 16:24:29 oslo_i18n :P 16:24:41 don't use private methods 16:24:49 thingee: thanks for saying it for me :) 16:24:50 Bad unit testing was uncovered by the new library being released. 16:24:57 thingee: I almost popped a gasket 16:25:08 If such issues arise, please let me know. 16:25:34 So, I think that is all I needed to say there. Just wanted people aware. 16:25:43 jungleboyj: thanks 16:25:45 Also, note that I am close to getting all the incubator pieces updated. 16:26:02 Have two more patches to work out and push up. Policy and Scheduler. 16:26:06 I also want to mention with lazy translation changes, even though we did talk to the people behind the change, it was reviewed in and was not caught 16:26:25 jungleboyj, are you changing all driver code references to these is one patch? or should the driver owners fix them? 16:26:30 * jungleboyj looks sheepish. 16:26:43 kmartin: I will take care of all of it. 16:26:54 #topic Where to do "san replica array configuration" 16:26:54 Best to just have one big patch for each library. 16:26:55 ok. thanks 16:27:02 TaoBai: hi 16:27:14 jungleboyj: same question...we approach you in case of oslo changes issues 16:27:22 Hi 16:27:38 navneet: Yes. 16:27:41 Start with me. 16:27:47 Can we add hacking checks for the out-dated oslo imports please 16:27:58 Once they are believed fixed 16:28:04 I would like to cancle this topic , because duncan just clarify his proposal 16:28:09 DuncanT: Would be happy to do that if people support it. 16:28:18 TaoBai: ok 16:28:20 jungleboyj: I certainly do. 16:28:32 #topic Request to review logging standards documentation 16:28:35 TaoBai: DuncanT: what is the proposal please? 16:28:35 DuncanT: Ok, will work on that as well. 16:28:38 jungleboyj: hi 16:28:44 I am here. ;-) 16:28:44 TaoBai: Ping me if you've any questions 16:29:02 #link http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/drop-namespace-packages.rst 16:29:19 Hold on. 16:29:24 avishay: see the review - just insert an extra layer in the class hierachy 16:29:33 Duncan Thomas 12:00 AM I'd agree with Avishay that they should be somewhere common, I just don't think that should be here - a subclass of this called ReplicatingSan or similar that can be further subclassed by storwize and others makes perfect sense. 16:29:34 not sure that it is a correct link 16:29:41 thingee: That is the wrong link 16:29:49 TaoBai: DuncanT: works for me 16:29:55 And the like https://review.openstack.org/#/c/145113/1/cinder/volume/drivers/san/san.py 16:30:02 DuncanT: I blame jungleboyj for putting the wrong link in the agenda :) 16:30:07 Did I? 16:30:20 Oh sigh, I did. Hold on. 16:30:29 thingee: Blaming jungleboyj seems like a good general policy to me 16:30:43 DuncanT: :-p 16:30:49 avishay thanks for your confirm 16:30:54 #link https://review.openstack.org/#/c/132552/ 16:31:21 So, this is real short and sweet. Follow up from yesterday's cross projects meeting. 16:31:43 They want to get this document merged. Want everyone aware of it and to review it. So, please take a few minutes to do so. 16:32:00 It will be the base definition of how we do logging going forward. 16:32:01 Hi DuncanT, sure I will if there is 16:33:19 jungleboyj: thanks 16:33:31 thingee: Thank you. 16:33:44 #topic Midcycle meet up in austin 16:33:48 jungleboyj: here?? 16:33:58 #link https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup 16:33:58 :) 16:34:34 Oh, me again. 16:34:40 No, I left. ;-) 16:34:59 jungleboyj: we had someone yesterday asking about attending. What should we tell people? 16:35:06 jungleboyj: you're popular today 16:35:13 So, last thing. We have two weeks until the mid-cycle meetup. Looks like about 22 people on the list as coming. 16:35:20 e0ne: Good way to be. ;-) 16:35:34 So, if people have questions about coming that are answered in the etherpad, direct them to me. 16:35:43 jungleboyj: Are we over capacity? 16:36:03 we will be putting names in for the 2 NetApp slots this week, we already are approved 16:36:14 smcginnis: Good question. The room that we currently have reserved will hold 25 comfortably. So, we are ok. I have Jennifer holding on to the backup room just in case. 16:36:14 I thought we have 'infinite' capacity in Cinder. 16:36:21 :) 16:36:23 winston-d: lol 16:36:30 winston-d: Hah! 16:36:35 lol 16:36:47 lol 16:36:48 So, I think we will be fine either way. Security issues are just less if we stay under 25, but am not going to turn anyone away. 16:36:57 will we have agenda for it this week? it's very hard to get approval w/o agenda 16:37:07 timcl: Good, need names for security and wireless access. So, appreciate you getting those. 16:37:07 a few pending approval, DuncanT are you going to make it? 16:37:27 kmartin: Hopefully, but not had a definite yes, yet 16:37:48 I'll chase tomorrow 16:37:51 agenda would be nice too so we can plan who to send accordingly 16:37:51 jungleboyj: thanks again 16:38:08 Anyway, if you are going to attend, please make sure your name is in the etherpad: 16:38:12 #link https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup 16:38:23 #topic Request quick resolution for https://review.openstack.org/#/c/133102 16:38:24 Only a few potential topics? please add to the list 16:38:24 thingee: Ok, I think I am done blathering on. 16:38:30 deepakcs, sdague: here? 16:38:35 thingee, yes, 16:38:51 #link https://review.openstack.org/#/c/133102/ 16:38:54 I quickly wanted to check with sdague on whether we need to wait for his devstack plugin patch to get our CI patch thru ? 16:39:41 given the strict CI deadlines, i would suggest to let the gluster patch thru, and once sdague 's plugin patch is in, we can send another one 16:39:47 sdague, ^ 16:40:10 so the thing is, installing and configuring glusterfs is really dubious scope creep for devstack, which is why there hasn't been much interest on the devstack side 16:40:44 sdague, Hmm what u mean by dubious ? 16:40:58 deepakcs: I think it took ceph a year to get merged in :) 16:41:10 thingee, so u mean we get relaxed deadline for gluster ?;) 16:41:13 yeh, and glustefs is less clear than that 16:41:36 sdague, I believe BharatK (author of patch) complied with every review of yours :) 16:41:38 the external plugins support should alleviate it 16:41:54 deepakcs: honestly I would start by asking, why are you waiting for the last month? Gluster has been in cinder for some time now. 16:42:03 sdague, I see that ur plugin patch has +2, +1, so is it close to getting merged ? 16:42:25 deepakcs: this isn't just a check list thing, we said multiple times during the review that it was really unclear wheter putting glusterfs in devstack core made sense. 16:42:28 thingee, resource issues, which are now fixed :) 16:43:04 dtroyer is now +2 on the external plugins, so I expect it to merge soon 16:43:15 chmouel or ianw need to weigh in 16:43:31 sdague, ok great 16:43:39 #link https://review.openstack.org/#/c/142805/7 16:44:05 sdague, we will wait for ur plugin to get in & refactor our patch over it then. thanks 16:44:22 cinder meetings are about making dreams come true 16:44:38 thingee: :) 16:44:47 deepakcs: fwiw, the test case for 142805 is actually your plugin in a github tree of mine 16:45:02 to prove it would support the glusterfs case 16:45:08 https://review.openstack.org/#/c/142815/8 16:45:43 sdague: thanks for chiming in 16:45:50 deepakcs: anything else? 16:45:50 thingee: I like that motto 16:45:55 sdague, cool, thanks again. I will follow up with BharatK on that 16:46:00 thingee, no, I am done 16:46:14 #topic open discussion 16:46:58 Do we want to use this extra time to put together an agenda for the meet-up? 16:46:59 so I've been working on some changes that would allow for version discovery from cinder client 16:47:14 get rid of volumev2 service type 16:47:19 thingee: +1 16:47:27 thingee: that will be nice 16:47:59 service type volume and url just point to x.x.x.x:8776 is all that will be need in the keystone service catalog 16:48:02 big thanks to jamielennox|away 16:48:09 for helping me 16:48:30 and the previous behavior will be supported 16:48:40 volume and volumev2 16:49:34 jungleboyj: sure agenda items 16:49:56 I think patrickeast has his target auth information topic 16:51:17 thingee: Putting f-2-f time in to wrap up open specs would be useful. 16:51:18 thingee: yep 16:52:27 jungleboyj: ? 16:52:52 thingee: We still have some specs that need to be approved. Right? 16:53:29 jungleboyj: yeah but they're not in a ready state 16:53:33 thingee: Thinking of xyang1 's CG spec. 16:53:36 I responded to some over the weekend 16:53:49 jungleboyj: thanks:) 16:53:52 jungleboyj: that one has a comment that needs to be addressed 16:54:05 xyang1 mention she would have to think about it 16:54:06 thingee: I think I've already addressed 16:54:13 I'll recheck 16:54:13 I was going to look at some more today as well. Just thinking that making some time to talk thorugh issues f-2-f would be useful. 16:54:26 thingee: and jason is ok with it 16:54:35 sorry what is f-2-f? :P 16:54:42 jungleboyj: I think we did that last time and it was useful. 16:54:53 xyang1: thanks 16:55:10 thingee: Face to face. 16:55:14 smcginnis: +2 16:55:16 heh 16:55:22 "Open discussion" 16:55:57 Thankfully we don't have drivers to get merged. 16:55:58 I'm not sure how far along DuncanT will be getting with the rpc work for versioned objects. 16:56:18 but we should be in better shape with thangp's cinder object work to talk about it some more 16:56:25 jungleboyj: we have driver updates that need to be merged by k-2:) 16:56:40 xyang1: True enough. 16:58:02 For those setting up 3rd party ci: there are now "mentoring meetings" to help you out. 16:58:03 #link https://wiki.openstack.org/wiki/Meetings/ThirdParty#Agenda_for_next_Mentoring_meeting 16:58:13 ok thanks everyone. if you want to propose an agenda item for the midcycle meetup, add it here https://etherpad.openstack.org/p/cinder-kilo-midcycle-meetup 16:58:42 asselin_: thanks! 16:59:10 #endmeeting