17:01:38 <hartsocks> #startmeeting vmwareapi
17:01:38 <openstack> Meeting started Wed Feb 19 17:01:38 2014 UTC and is due to finish in 60 minutes.  The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:41 <openstack> The meeting name has been set to 'vmwareapi'
17:01:48 <hartsocks> Hi folks, who's around?
17:01:50 <ik__> when is hackathon?
17:02:00 <browne> i'm here
17:02:03 * rgerganov is here
17:02:41 <rgerganov> garyk told me that he won't make it
17:02:48 <hartsocks> ik_: sorry to run you off.
17:03:55 <tjones> hi
17:04:02 <hartsocks> rgerganov: I got a note too. Short meeting then?
17:04:09 <hartsocks> :-)
17:04:13 <rgerganov> hartsocks, agree
17:04:32 <ssurana> :)
17:05:06 <hartsocks> #link https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Agenda
17:06:12 <hartsocks> I think most folks were aware that the FF for blueprint proposals passed around the time of our last meeting (back on Feb 05)
17:06:40 <hartsocks> What this means is we have to stop proposing new BP to Nova.
17:07:01 <hartsocks> That doesn't mean code has to be perfect today though. (but perfect is nice)
17:07:36 <hartsocks> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
17:07:53 <hartsocks> Feature Freeze is actually March 4th.
17:07:57 <browne> side note: the agenda link has a dead link to https://wiki.openstack.org/w/index.php?title=NovaVMware/AdministratorGuide&action=edit&redlink=1
17:08:16 <hartsocks> #action clean out dead link in wiki
17:08:25 <hartsocks> browne: thanks.
17:08:46 <hartsocks> So, March 4th if your code isn't "perfect" it's not getting in.
17:09:28 <browne> hartsocks: does that mar 4th date apply for bugs too?
17:10:02 <hartsocks> FF is for BP but...
17:10:12 <hartsocks> it's probably a good idea to have the bugs ready too.
17:10:18 <browne> ok
17:10:24 <hartsocks> Once that deadline hits it's really hard to get attention.
17:10:54 <hartsocks> The rule on Bugs is you may backport them if you can get reviews and cycles to do it.
17:11:03 <tjones> browne: keystone may have different rules than nova too
17:11:08 <hartsocks> It's better to have the bug fix in before the version is cut.
17:11:27 <browne> ok thx
17:12:08 <hartsocks> Oh, yeah. Each project can have different internal deadlines. The link is for OpenStack in general. A project's deadline won't be any *later* than the posted deadline on the wiki.
17:12:50 <hartsocks> So, for example, Nova has moved up its deadlines for the sake of reviewer sanity.
17:13:22 <hartsocks> So after typing all of that...
17:13:35 <hartsocks> #link https://etherpad.openstack.org/p/vmware-subteam-icehouse
17:13:45 <hartsocks> I took some time this AM to update our etherpad.
17:14:20 <hartsocks> I will try to keep that up-to date on where things are in icehouse.
17:14:43 <hartsocks> I usually do an update pass every Wednesday morning. With the deadlines looming I will try to be more frequent.
17:15:20 <hartsocks> There's a section in there for critical bugs. These are intended to free Minesweeper.
17:15:43 <hartsocks> Okay.
17:15:48 <hartsocks> #topic blueprints
17:16:06 <tjones> that is very good.  the core reviewers tend to jump on those bugs that will help minesweeper
17:16:35 <hartsocks> I've only identified two so far. There's bound to be more.
17:17:02 <hartsocks> Just for the record:
17:17:12 <tjones> should we be also calling out dependencies?   Im concerned about our long dependecny chains
17:17:21 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/autowsdl-repair
17:17:52 <hartsocks> (the reason Minesweeper was not accepting the patch is that Minesweeper uses proxies and I never tested in a proxied environment.)
17:18:07 <hartsocks> tjones: I could do the homework for dependencies
17:19:21 <hartsocks> Does anyone have a BP that they need to talk about before we move to bugs?
17:19:45 <sabari> https://blueprints.launchpad.net/nova/+spec/vmware-spbm-support
17:19:49 <sabari> needs some reviews.
17:20:23 <hartsocks> #link https://review.openstack.org/#/q/topic:bp/vmware-spbm-support,n,z
17:20:31 <hartsocks> That's a *number* of patches
17:20:48 <rgerganov> I will take a look at these
17:21:06 <sabari> Thanks Rado.
17:21:10 <rgerganov> I want to restore my patch for favoring shared datastores and this is somehow related
17:21:26 <rgerganov> I mean we need to come up with good DS selection algorithm
17:21:40 <hartsocks> I'm already concerned that https://review.openstack.org/#/c/66666/12/nova/virt/vmwareapi/vim.py interacts with what I'm trying to do.
17:21:46 <sabari> So that was you, I remember to have seen that patch, but couldn't relate to who was working on it.
17:22:31 <hartsocks> rgerganov: yes, I remember we figured out we need to rank the DS somehow but we never fleshed out how to do it.
17:22:39 <sabari> the change was need to make use of the vim as a base class for pbm connections.
17:23:16 <sabari> hartsocks: can you post the link for the change that you are doing.
17:23:21 <hartsocks> how does that affect the normal vSphere WS SDK interactions?
17:23:50 <hartsocks> sabari: this is that autowsdl business. It seems to be continually blocked or ignored.
17:24:10 <sabari> it doesn't affect the standard connection mechanism. For SPBM, we need to connect to a new endpoint using a new wsdl.
17:24:29 <hartsocks> yes, but you've modified the soap connector code…
17:24:37 <hartsocks> soap URL code
17:25:00 <hartsocks> so what I'm concerned about is that this might accidentally mean if my patch merges I will break your SPBM support.
17:25:12 <sabari> kind of just a tweak so that we can get the url's for both code flows properly.
17:25:56 <sabari> I view the change by pbm code to be a bit cosmetic.
17:26:04 <sabari> it doesn't change a lot of semantics.
17:26:13 <sabari> i will take a look at your code.
17:26:55 <hartsocks> thanks. Looks like Jenkins doesn't like my tests anymore.
17:28:33 <hartsocks> Okay, so moving on...
17:28:39 <vuil> https://blueprints.launchpad.net/nova/+spec/vmware-vsan-support has a couple of patches
17:28:47 <vuil> available for review as well
17:29:18 <vuil> though I'd say wait a day or two as a few of the patches can use another round of update of the oslo vmware lib
17:29:40 <rgerganov> vui, what kind of infrastructure do I need to test vsan?
17:29:42 <tjones> vuil: is that moving along ok?
17:29:49 <tjones> the oslo stuff
17:30:08 <rgerganov> tjones, we have the repository created -- oslo.vmware
17:30:09 <vuil> same for spbm, kinda :-)
17:30:21 <vuil> I can walk you through it later.
17:30:27 <rgerganov> vuil, thanks
17:31:10 <tjones> rgerganov: when i checked last week it was blocked on an infra issue.  is it unblocked?
17:31:51 <rgerganov> https://github.com/openstack/oslo.vmware
17:31:56 <rgerganov> fresh and clean
17:32:11 <tjones> awesome
17:32:30 <tjones> um… there is nothing in there yet…
17:32:39 <tjones> i mean other than the directory structure and stuff
17:33:00 <vuil> The action is happening here: https://review.openstack.org/#/q/status:open+project:openstack/oslo.vmware,n,z
17:33:01 <rgerganov> yes but Vipin resubmitted his patches
17:33:26 <hartsocks> wow. lots of action.
17:33:38 <tjones> gr8
17:34:06 <vuil> looks like dims is helping with bringing the dependencies needed
17:34:15 <hartsocks> Is this work still going to make icehouse-3?
17:35:18 <rgerganov> not sure, we should talk to Vipin
17:35:19 <vuil> Think the library is in good shape, we just need to get the project set
17:35:43 <vuil> up properly for review/verification
17:36:40 <hartsocks> okay, lots to stay on top of then.
17:38:30 <hartsocks> Anything else on blueprints? Anything on blueprint priority?
17:40:01 <hartsocks> #topic bugs
17:40:34 <hartsocks> #link https://etherpad.openstack.org/p/vmware-subteam-icehouse
17:40:48 <hartsocks> I ran my bug priority report this morning.
17:40:56 <hartsocks> The report itself has some bugs.
17:41:04 <tjones> looks like we need to do some triage
17:41:41 <hartsocks> #link https://bugs.launchpad.net/nova/+bugs?field.tag=vmware
17:42:15 <hartsocks> as far as what's tagged vmware, 6 un-triaged isn't so bad…
17:42:39 <hartsocks> #link https://bugs.launchpad.net/nova/+bug/1278149
17:42:43 <uvirtbot> Launchpad bug 1278149 in nova "VMware: InstanceNotRescuable hit during rescue tempest tests" [Critical,Fix committed]
17:42:57 <hartsocks> Should that be tagged for our sub-team list?
17:42:58 <tjones> yes - but there are 200 in nova and now that i am the "bug czar" i'd love our list to be 0 :-D
17:43:07 <hartsocks> heh.
17:43:45 <tjones> i'll take a look at that one
17:44:12 <hartsocks> So, is https://bugs.launchpad.net/openstack-vmwareapi-team this still useful?
17:44:33 <tjones> yes it should.  I will add it.  yes the project is very much used by our customers and partners
17:44:43 <hartsocks> okay.
17:45:20 <hartsocks> We can do bug-triage outside the meeting in #openstack-vmware
17:45:26 <tjones> ok
17:46:09 <hartsocks> open discussion or is there a bug someone needs to bring to our group attention?
17:46:59 <hartsocks> #topic open discussion
17:47:12 <hartsocks> okay, any topics at all?
17:47:38 <tjones> ok sure
17:48:12 <tjones> i want to make sure i know what our top 5 critical bugs are for icehouse.  so i look at your list….  *loooking*
17:48:54 <tjones> and i see ordered by prio - but that is nova prio which may not be our customers prio
17:48:55 <tjones> right?
17:49:09 <hartsocks> it's a combination
17:49:20 <hartsocks> it's nova priority + vmwareapi subteam priority
17:49:30 <hartsocks> the sum of the two priorities is the overall rank.
17:49:40 <tjones> ok great!  so high/critical is high for nova, critical for our customers - correct?
17:49:45 <hartsocks> right
17:49:53 <tjones> excellent!  that is exactly what i need
17:50:23 <hartsocks> That lets us follow the rule that a driver that's non-gating literally can *never* rise to Critical/Critical
17:50:33 <tjones> right
17:50:51 <hartsocks> The Nova core are trying to conserve "Critical" to mean "breaks *all* of OpenStack" … but you knew that.
17:51:15 <tjones> yep
17:51:34 <hartsocks> I have a separate list for "blocks Minesweeper" but I've not figured out how to fold the three different priorities together (or whether I should bother)
17:52:24 <tjones> i don't think it is needed.  when we have minesweeper blockers i ask the core guys to take a look and they are very responsive
17:52:44 <tjones> so i'd just bring those 2 to their attention either IRC or ML
17:52:46 <hartsocks> cool
17:53:50 <hartsocks> A note on testing...
17:53:54 <hartsocks> Unit testing.
17:54:34 <hartsocks> I have been trying to improve my use of mocks and I did something a little rude this morning … I dropped a test on someone-else's patch.
17:54:48 <hartsocks> I handed over the original patch so I felt it wasn't too terrible
17:54:57 <hartsocks> #link https://review.openstack.org/#/c/73865/8/nova/tests/virt/vmwareapi/test_driver_api.py
17:55:10 <hartsocks> Starting at line 462
17:55:25 <hartsocks> I managed to mock out all the API except for the code under test.
17:55:42 <hartsocks> Then I used asserts to do assertions on wether the API was used correctly.
17:55:53 <hartsocks> I couldn't figure out how to explain this without code.
17:56:22 <hartsocks> But, using the mocks, we can assert that a task is created and waited on.
17:56:53 <hartsocks> I would like to do more testing in this direction because I feel it will allow us to cover more branches and scenarios.
17:57:10 <rgerganov> the problem with mocking is that creates tight coupling between tests and code under tests
17:57:27 <rgerganov> but it is the way to go in most of the cases
17:57:54 <hartsocks> Compared to writing a fake.py which has to cover all possible use scenarios the Mocking could actually be less coupling.
17:58:33 <hartsocks> The problem with the fake.py is that as you increase the number of scenarios it can cover you come closer and closer to building a simulator of the system under test.
17:58:45 <hartsocks> Perhaps I can learn to do better Mocks.
17:58:56 <hartsocks> But in the test I've linked...
17:59:06 <hartsocks> I get to actually initialize the real object under test.
17:59:27 <hartsocks> A reviewer can come in and see… yes… that's the object under test, not a fake version.
17:59:41 <hartsocks> That's my soap box on the topic anyhow.
18:00:09 <tjones> i'd like to be able to write better tests.  i will spend some time looking at this
18:00:30 <hartsocks> It's not what I would call good code, but I'm trying. :-)
18:01:00 <browne> i definitely like using mock over mox or fakes
18:01:35 <hartsocks> This particular set of mocks I wrote because instead of pulling serviceContent the code was pulling the Vim object… it made the wrong API calls.
18:01:47 <hartsocks> The test enforces call order.
18:02:10 <hartsocks> Looks like we're out of time.
18:02:14 <hartsocks> #endmeeting