17:00:27 #startmeeting VMwareAPI 17:00:28 Meeting started Wed Sep 18 17:00:27 2013 UTC and is due to finish in 60 minutes. The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:31 The meeting name has been set to 'vmwareapi' 17:00:40 Who's around to talk? 17:01:16 im here 17:01:29 hey. 17:01:39 Might be a short meeting then! 17:01:44 Only us about. 17:01:56 LOL 17:02:53 * hartsocks listens to crickets while waiting for more people 17:03:36 *checks for the ios 7 update while waiting for more people* 17:03:43 nice. 17:05:14 It's 8pm for Gary. I guess we won't see him. 17:05:27 Any HP folks around? 17:06:48 Well, the Feature Freeze means we won't talk Blueprints right now. 17:07:24 Our next deadline is the Havana-rc1 release which doesn't yet have a firm date. 17:07:37 That means our focus should be: 17:07:39 #topic bugs 17:07:53 #link http://paste.openstack.org/show/47225/ 17:08:36 The link has output from one of my new reporting tools. 17:08:47 nice! 17:09:13 the age is really good 17:09:40 I got tired of building these manually, so this will be easier to keep up to date. 17:10:23 Yeah. age. That's actually really useful... 17:10:25 hi vui here. Hopping in and out, due to conflict with a conf call I am now. 17:10:34 hartsocks, missing one of mine? 43641 17:10:58 can you look at vui's VMwareVCDriver: Sparse disk copy error on spawn again? he explained why he is using self rather than the class name (since it's static). maybe better to "unstatic" for clarity 17:10:58 vuil: hey 17:11:44 hartsocks, one more review of mine 46277 missing as well 17:12:12 dims: ah, I wrote this to scan for bug and a number, you use LP# and a number. I'll have to fix that. 17:12:54 I knew we had a lot of reviews to do. 17:13:00 hartsocks, not sure where i picked that habit from :) 17:13:42 40298 and 43994 have had multiple +1's for a while, just in a holding pattern of constant rebasing. 17:14:43 yeah, the "age" field shows some problems ... 17:14:59 your change 40298 is 14 days old... 17:15:08 this one... 17:15:13 I am going to do another rebase because I see some dependent changes are going to be updated as well. But other than putting the comment on the static call, there is nothing I am aware of that need to be addressed 17:15:25 … this is pretty bad: 17:15:27 * Medium https://bugs.launchpad.net/bugs/1180044 review: https://review.openstack.org/43270 17:15:27 title: 'nova failures when vCenter has multiple datacenters' 17:15:27 votes: +2:0, +1:1, -1:0, -2:0 age: 27 days 17:15:29 Launchpad bug 1180044 in nova "nova failures when vCenter has multiple datacenters" [Medium,In progress] 17:15:32 27 days old. 17:16:07 so, I should figure out how to bump these up to "ready for core" 17:16:38 You can see we have some patches that sit "ready" for almost a month at a time. 17:17:34 BTW: I'm calling something "ready" if it has 5 or more +1 votes from the group. 17:20:15 Well, the order of the day for me is *reviews* I will try and work through the 9 I see here ready for review and catch the ones dims pointed out this week and early next. 17:20:42 thanks hartsocks 17:20:45 The order by "priority" thing is experimental. 17:21:12 It's using both the nova project priority plus any other priority we assign. 17:21:14 So a line like... 17:21:24 * High/Critical https://bugs.launchpad.net/bugs/1223709 https://review.openstack.org/46027 readiness:ready for core 17:21:26 Launchpad bug 1223709 in openstack-vmwareapi-team "VMware: boot from volume exception" [Critical,In progress] 17:21:40 Means nova calls it "High" and we call it "Critical" 17:22:11 Critical for us means you shouldn't ship an OpenStack distro with the driver without this bug fix. 17:23:13 I've been told we should almost never use the "Critical" status in Nova ... 17:23:43 in nova "Critical" is supposed to mean all users are affected by this problem. 17:24:18 The argument I've heard is "only vSphere users can be effected by this bug" whenever I've tried to use the "Critical" status for one of our bugs. 17:24:48 So we have https://bugs.launchpad.net/openstack-vmwareapi-team 17:25:10 to attach different priorities when nova/driver priorities don't line up. 17:26:35 Any questions? Any bugs we need to get on the list? 17:28:01 #topic open discussion 17:28:14 So anything anyone needs to discuss at all? 17:29:40 We have 6 new bugs that don't have priorities on them. 17:30:05 #link https://bugs.launchpad.net/nova/+bug/1209090 17:30:07 Launchpad bug 1209090 in nova "create VM instances failed by vmwareapi.VCDriver" [Undecided,Incomplete] 17:30:24 I've seen this before: 17:30:37 "Got this error 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128)". 17:30:53 But, it goes away and I've never root caused it. 17:31:23 (beyond being a SOAP error) 17:32:20 This sounds familiar: 17:32:23 #link https://bugs.launchpad.net/nova/+bug/1225468 17:32:25 Launchpad bug 1225468 in nova "vmware: boot failure due to partial image copy" [Undecided,New] 17:32:34 anyone working on this? 17:33:36 I'll take that as a no. 17:34:16 thot tracy sounded out in an email that this is a dupe of another 17:34:19 oh i am kinda 17:34:41 what have you figured out? 17:34:59 i think it's a dup of one i am working on - partial upload 17:35:09 link? 17:35:39 https://bugs.launchpad.net/nova/+bug/1213269 17:35:41 Launchpad bug 1213269 in nova "_check_if_folder_file_exists only checks for metadata file" [Low,Confirmed] 17:36:06 I would concur that this is indeed a dupe. 17:36:30 okay. 17:38:25 I've got bug manager privs, so I've marked it. 17:38:53 This one jumps out: 17:38:55 #link https://bugs.launchpad.net/nova/+bug/1226709 17:38:57 Launchpad bug 1226709 in nova "Unable to boot from volume using VC VMDK cinder driver" [Undecided,New] 17:38:59 on this one https://bugs.launchpad.net/nova/+bug/1226709 it references a traceback showing __deepcopy__ i have seen that intermittenlty latel 17:41:01 hmm... 17:41:22 * russellb waves 17:41:30 just dropping in, need anything from me? 17:41:33 russellb: hey 17:41:50 be sure to target bugs you want to make sure get into havana to havana-rc1 17:42:01 We're triaging and working on this: http://paste.openstack.org/show/47225/ 17:42:19 cool 17:42:32 so probably target all your high priority ones to rc1? 17:42:40 That would be the goal. 17:42:47 cool, you should be able to do that 17:43:14 Hi Shawn, I just dropped in, looks like you missed https://bugs.launchpad.net/nova/+bug/1190515 in your list 17:43:15 I've started tracking a review's age too... 17:43:17 Launchpad bug 1190515 in openstack-vmwareapi-team "Incorrect host stats reported by VMWare VCDriver" [High,In progress] 17:43:33 how are you calculating age? 17:43:55 timestamp of last posted patchSet 17:44:12 what's the goal of tracking the age? 17:44:38 Some of our reviews sit around longer without attention… that forces merge problems. 17:44:41 if the audience is reviewers, you should take -1s into account too 17:44:53 meaning, is it waiting on a reviewer or not 17:45:09 i do some of this kind of stuff in my openreviews stats 17:45:25 http://russellbryant.net/openstack-stats/nova-openreviews.html 17:45:41 wow 17:45:48 could potentially update that script to generate the same stats, but on a subset of reviews 17:46:51 code here btw - https://git.openstack.org/cgit/openstack-infra/reviewstats 17:46:56 thanks! 17:47:02 sure 17:47:21 so you're not singled out at the top of the old stuff list or anything :-) 17:47:44 nice to know we're in good company! 17:47:49 :-p 17:48:27 heh 17:48:36 well, yeah, those stats are really useful for me 17:48:55 * russellb tries to get the patch of yours on the list reviewed 17:48:57 looks easy 17:49:53 russellb, one question, is it better to leave a review alone or keep rebasing? (if it is not getting attention that is) 17:50:27 rebase if it has a conflict is fine 17:50:36 one of my "longest waiting" lists ignores rebases (the last one) 17:50:55 great, thanks. 17:51:38 russellb, I noticed there are some scripts that pull forward +1's on some rebases. 17:51:57 what are the rules on those? 17:52:13 yeah if it's a trivial rebase (as in, you probably didn't *need* to rebase), it will copy reviews over 17:52:21 i don't know the exact logic for trivial rebase detection 17:53:05 I'll have to figure out how to detect a rebase and use that info in my own reporting. 17:53:06 https://review.openstack.org/#/c/12373/ 17:53:31 hartsocks: all i'm doing it looking at the the oldest revision that doesn't have any -1 on it 17:55:26 and if you guys hadn't seen those before, there's also this: http://russellbryant.net/openstack-stats/all-openreviews.html 17:55:27 I was curious and looked up trivial rebase detection: 17:55:29 https://code.google.com/p/gerrit/source/browse/contrib/trivial_rebase.py?spec=svnb7b202049d1285df8647ea1816f698c0a7b29d72&r=b7b202049d1285df8647ea1816f698c0a7b29d72 17:55:31 showing all projects combined and individually 17:55:51 Nova generally beats average review times across all projects, fwiw :) 17:56:14 It is based on git-patch-id. Essentially SHA1 of diff ignoring whitespaces and line num differences 17:56:24 ah, cool 17:58:16 Before we lose the room, anything else I need to get on my list? 17:59:35 Okay guys. 17:59:58 I'm usually hanging out in #openstack-vmware if you need me. 18:00:25 https://review.openstack.org/33100 is not on your list 18:00:30 russellb, thanks for helping us out on our priority bugs. 18:00:31 can you please add the same 18:00:32 thanks 18:01:19 Kind of tops Russell's list somewhere. 18:01:31 heh. looks like I have a bug in my report software. 18:02:08 i may take that list out actually ... i'm not sure how useful it is 18:02:15 (time since the 1st revision) 18:04:19 I'll go back over everything after this meeting and send an updated list. 18:04:46 Thanks for coming today everyone! 18:05:25 #endmeeting