17:00:15 #startmeeting vmwareapi 17:00:16 Meeting started Wed Jan 29 17:00:15 2014 UTC and is due to finish in 60 minutes. The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:19 The meeting name has been set to 'vmwareapi' 17:00:38 Greetings stackers! 17:00:41 Who's about? 17:01:06 i'm here 17:01:06 This is rajdeep vmware india 17:01:21 rajdeep: hey, welcome! 17:01:32 thanks 17:01:34 * mdbooth is here 17:02:46 probably a short meeting today 17:03:22 what is the agenda 17:03:28 #link https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Agenda 17:03:35 :-) just pulling it up 17:03:55 #topic bugs 17:04:20 Any new bugs to discuss? 17:04:32 I will make my triage run later today. 17:05:03 hi 17:05:11 hey garyk 17:05:15 we're just doing bugs 17:05:23 thanks 17:05:36 I just asked who has a high priority bug they need to discuss here or need to draw attention to. 17:05:36 i have addressed some bugs regarding race conditions that are blocking the CI 17:05:39 i hope those get in 17:05:53 For the record could you link those in the IRC log here? 17:05:54 Is anybody specifically focussing on the set of bugs which are causing Tempest failures? 17:06:19 mdbooth: garyk has taken on this 17:06:40 Cool 17:06:56 garyk: is this an accurate statement of your current efforts? 17:07:04 yeah, something like that 17:07:33 i am currently treating our ci issues 17:08:10 that is minesweeper. 17:08:38 minesweeper being the tool which runs vmwareapi tempest tests... 17:08:44 right 17:08:45 * mdbooth is trying to jog his memory 17:08:47 thanks 17:09:06 garyk: there seems to be lag between you and I … I'll pause a bit longer to let you type 17:09:34 garyk: could you list these high priority bugs so those present could give them review attention? 17:09:48 sec: 17:10:15 https://review.openstack.org/#/c/69622/ and https://review.openstack.org/#/c/65306/ 17:10:40 at the moment the minesweeper queue is 1 day deep. these 2 fixes will help shorten it considerably 17:10:49 ryan has validated them 17:11:19 that is all on my side 17:11:24 okay 17:11:40 I plan on spending the afternoon with the Minesweeper team to get a better handle on things. 17:12:03 If I find anything to patch, I will coordinate with you first since you are working in this area. 17:12:15 ok, thnaks 17:12:40 Incidentally, there are a couple of outstanding reviews now where we're catching Exception 17:13:08 Do we want to accept them as is, and hope we remember to raise more specific exceptions later 17:13:12 mdbooth: at the moment we are not able to catch a specific exception - i have written a TODO for this. 17:13:14 Or block now and fix it 17:13:20 i noticed that too. shouldn't we catch on a specific exception? 17:13:28 ok 17:13:46 mdbooth: i do not think it is reasonable to block these now - that would be detremental for the ci efforts 17:14:07 the connection does not raise the VC error - this is something that we need to develop 17:14:08 I'm satisfied with a TODO as it means new coders will know we don't like it but we can't address the problem right now. 17:14:28 if we had this - and not by parsing a string for the exception then could achieve it - but it is a future developemtn 17:14:39 hartsocks: agreed 17:14:44 May I suggest that all these patches add entries to a central TODO list 17:15:00 or risk being missed when the problem is addressed later 17:15:08 I like this so much I'm putting it on my own backlog. 17:15:13 mdbooth: feel free to open a bug on launchpad 17:15:21 I think there's reasonable potential for hair loss here :) 17:15:28 heh 17:16:02 not sure that i agree but maybe i am just too practical for this discussion 17:16:14 ? 17:16:55 what i am trying to say is that we have a real issue. sadly the fix is as good as it gets at the moment without taking a few days of new developments. it solves a real problem 17:17:53 mdbooth,garyk: let's discuss this off line. Maybe I misunderstand something. Either way, a central report on all "TODO" items is a pretty standard thing to have. I'm sure there's a tool to make it. 17:18:10 +1 17:18:13 +1 17:18:32 okay. 17:19:00 can't we parse the exception string 17:19:02 ? 17:19:09 #action discuss central TODO list of all known driver issues 17:20:33 rajdeep: I'm thinking that probably feels like a hack to people. And in general, it's nice to be able to catch as narrow an exception hierarchy as you can. 17:20:44 ok 17:21:12 rajdeep: it is possible that could be the only and best solution, but we would probably have to explain why so future maintainers don't sit in IRC having the same discussion we are having now. :-) 17:21:57 Just to record those two reviews in the meeting notes summary… 1 second please 17:22:14 #link https://review.openstack.org/#/c/69622/ - please review - priority performance bug 17:22:30 #link https://review.openstack.org/#/c/65306/ - please review - priority performance bug 17:22:50 … okay, that will show up in the notes now because I used the "#link" marker. 17:23:00 Moving on. 17:23:21 Anything else with bugs people would like to call out before we move to Blueprints discussion? 17:23:36 <_mdbooth_> My connection seems to have hug there, so I will have missed anything after the action item 17:24:02 s'okay I was just marking things for the log generator. 17:24:12 #topic blueprints 17:24:23 #link https://etherpad.openstack.org/p/vmware-subteam-icehouse 17:24:53 I may start doing this etherpad for each cycle. It lets us see priority order of blueprints. 17:25:37 Basically the short of it is we have 6 BP for Nova. 17:26:03 The top 2 are on Gary's plate and are also performance related. 17:26:28 i think that the 6 mentioned are already coded and waiting review 17:26:34 yeah 17:26:41 we also have a few pending approval - some have already been implemented 17:26:46 as far as I know these were all ready for i-2 17:26:53 (the top priority ones anyway) 17:27:15 correct. not sure if you guys saw russells mail from today/yesterday regardong bps for icehouse 17:27:27 the 4th feb is the last day to draft a bp 17:27:38 the 18th is the last day to have code for the bp 17:28:08 okay. 17:28:08 not sure if the core reviewers have cycles to deal with all of these, but that is another issue 17:28:20 all we can do is the best work we can. 17:28:26 so, newbie, question: what's the procedural to get a blueprint approved? 17:28:37 * hartsocks digs for link 17:29:01 https://wiki.openstack.org/wiki/Blueprints 17:29:09 thx 17:29:32 In short, you propose it and you flip the little status widgets on it to record your progress. 17:30:15 Many folks miss the part about setting your milestone. 17:30:24 we can go over that off line. 17:30:30 (or on the other channel) 17:30:37 ok 17:31:11 browne: do you have anything on your security blueprints or do you need more time? 17:31:48 i'm prototyping something for https://blueprints.launchpad.net/nova/+spec/vmware-encrypt-vcenter-passwords 17:32:21 cool. 17:32:47 browne: Is the related to why you were asking about certificate checking? 17:32:52 I have rights on that BP so I'm flipping Implementation: to "In progress" 17:33:05 mdbooth: no that was separate 17:33:18 hartsocks: ok 17:34:03 oh, it says I'm working on it… oh well. You know where the switch is now. When you are ready for core-reviewer you flip that to "needs review" 17:34:39 okay. 17:35:06 mdbooth: we discussed you doing some light refactorings … do you have anything on that yet? 17:35:40 hartsocks: I started, but it was clear that I was heavily treading on outstanding patches 17:35:49 e.g. at least 2 of garyk's 17:35:55 namely image cache and boot from iso 17:36:09 mdbooth: okay. Thanks for being aware of other developer's efforts. 17:36:11 Given that it's low priority, I don't think it's currently worth it 17:36:23 Well, I have garyk to thank :) 17:36:41 He's extremely responsive to both reviews and on IRC 17:36:48 mdbooth: I am fairly certain it would have to be a BP anyway. 17:36:52 mdbooth: you have spent valuable time finding a serious bug 17:37:16 let's not lose that information then. 17:37:40 can we get that info recorded somewhere? 17:38:11 There's a bug for the spawn() with multiple disks bug 17:38:20 link? 17:38:24 https://bugs.launchpad.net/nova/+bug/1271966 17:38:28 okay. 17:38:45 I also spent a few hours writing pseudocode for the existing spawn() 17:39:02 nice cath kudos 17:39:08 And I've spent a good while looking at how libvirt does it 17:39:26 I think we need an effort to have common code for this for all drivers 17:40:30 it would be nice to have a coarser grained set of building blocks for what a driver does… 17:40:52 … or maybe something that allowed drivers to be thinner? 17:41:03 But that's a whole conversation there. 17:41:37 (beyond just the fact that the drivers commonly duplicate code) 17:41:41 Indeed. On this specific point, I think the arguments to spawn() could be improved 17:42:13 block_device_mapping could be almost entirely resolved by the api 17:42:47 leaving the driver to do image cache management, and connect the previously mapped disks in order 17:44:39 mdbooth: I'm hearing input from folks like yourself, vuil, vipin, garyk … it sounds like maybe we need to meet up and get on the same page. 17:45:03 mdbooth: many of you may be working on the same ideas and it would be good to share the load. 17:45:28 We're kind of there anyway… so ... 17:45:32 #topic open discussion 17:46:12 I'd like to drawn attention to this: https://review.openstack.org/#/c/69652/ 17:46:22 Specifically the test pattern 17:46:25 I quite like it 17:46:33 that was the patch that i was giving the kudos for 17:46:34 I've mocked the suds client 17:46:43 mdbooth: awesome 17:47:05 have I mentioned I don't like fake.py? 17:47:13 Anyway, I think it's neat, and probably generally useful 17:47:17 Hence I'm bringing it up 17:47:20 hartsocks: You did :) 17:47:55 If it's generally useful, it's probably in the wrong place 17:48:26 If we're calling out work, I've been scratching around here: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:session-management-refactor,n,z 17:48:42 … mostly … I was after this: 17:49:04 https://review.openstack.org/#/c/66378/4/nova/tests/virt/vmwareapi/test_driver.py 17:49:08 line 120 17:49:22 mdbooth: Yeah, nice work. That is a neat useful way to mock the soap calls. 17:49:30 … I'm not 100% sure it's good work but I'm trying to find something better. 17:50:04 The basic premise is I noted the driver will sometimes try and "wait_for_task" ... 17:50:13 … but there's no previous task on the session. 17:50:34 So I was hoping to find some way we could do something like a database transaction. 17:51:30 This is probably too big to realistically make icehouse but the BP is approved. 17:52:00 I consider it lower priority than gary's work. 17:53:09 anything else to discuss? 17:55:08 not on my side 17:55:15 great. 17:55:34 We'll knock off early for once. 17:56:18 #endmeeting