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