17:02:33 <hartsocks> #startmeeting vmwareapi
17:02:35 <openstack> Meeting started Wed Jan 22 17:02:33 2014 UTC and is due to finish in 60 minutes.  The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:39 <openstack> The meeting name has been set to 'vmwareapi'
17:02:44 <hartsocks> hey folks, had my head in another meeting.
17:02:47 <hartsocks> Who's around?
17:02:51 <rgerganov> hi
17:03:00 <browne> hi, Eric's here
17:04:50 <hartsocks> today might be a light day… lots of folks are busy with other things today...
17:05:25 <garyk> hi
17:06:13 <hartsocks> #link https://wiki.openstack.org/wiki/Meetings/VMwareAPI#Agenda
17:07:19 <hartsocks> #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
17:07:36 <hartsocks> So the icehouse 2 deadline is tomorrow.
17:08:05 <hartsocks> #link https://etherpad.openstack.org/p/vmware-subteam-icehouse-2
17:08:31 <hartsocks> Last meeting I know I said we'd spend some time on bugs, but ...
17:08:53 <hartsocks> garyk, how's your BP looking "vmware-hot-plug" for icehouse-2?
17:09:09 <garyk> hartsocks: it was completed 2 weeks ago and is waiting for review
17:09:29 <garyk> all of the bluepreints that i was working on for i-2 were completed at the beginning of the month
17:09:31 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/vmware-hot-plug
17:09:40 <garyk> they occasionally have rebases but no chnages
17:09:44 <hartsocks> you're currently targeted at icehouse-3
17:09:50 <hartsocks> Is that new?
17:10:10 <garyk> i did not change it. maybe russellb went over all of the bps. not sure though
17:10:43 <hartsocks> I'm targeted for icehouse-3 as well on autowsdl-repair… so that would be my guess.
17:11:12 <garyk> i think that the problem that we have with these bps is we do not have core reviewers who are sponsoring us
17:11:24 <hartsocks> pretty much.
17:11:26 <russellb> correct
17:11:33 <russellb> i deferred everything not merged
17:11:50 <russellb> as i-2 was getting cut today
17:12:31 <russellb> garyk: over 90% of the blueprints don't have core sponsors fwiw ... the sponsor thing isn't really being done at all.  just making sure you know you're not singled out
17:13:03 <garyk> russellb: thanks for the clarification
17:13:15 <hartsocks> russellb: I think there was a fair bit of other stuff going on in i-2 anyway around gate and performance issues...
17:13:22 <russellb> yes
17:13:23 <garyk> i just hope that they get a few review cycles. some are features for parity
17:13:30 <russellb> quite a small number of bps made it
17:13:57 <hartsocks> russellb: is there anything we can do to try and help get more reviews through?
17:14:14 <garyk> did the network objects at least make it or will they be in the gate for the next month (it is about 3 days to get on once approved)
17:14:15 <russellb> not that i can think of really
17:14:27 <russellb> network objects are not merged
17:14:34 <garyk> :(
17:15:00 <russellb> we're trying really hard to fix the gate
17:15:04 <russellb> that's primary focus for me
17:15:34 <garyk> not if it is worth anything but the minesweeper has been pretty stable the last few days - we had some hiccups last week.
17:15:47 <russellb> definitely worth something :)
17:15:49 <russellb> that's good to hear
17:15:53 <russellb> you're ahead of the pack on that
17:16:17 <hartsocks> I did get an update that the Minesweeper guys are ready to turn on −0 voting this week.
17:16:36 <hartsocks> So, much kudos to our Minesweeper team. They have been working nights and weekends.
17:16:45 <garyk> i think there was a mail on the list not to have the third party ci's do −1's etc
17:17:01 <hartsocks> I used the phrase "-0"
17:17:15 <hartsocks> to indicate that it would be a "-1" but we're not doing −1 yet.
17:17:25 <garyk> ok
17:17:29 <hartsocks> It's a "not positive" result.
17:17:59 <hartsocks> … also as trivia if memory serves you can have a Floating point with a −0 representation in IEEE notation...
17:18:16 <hartsocks> even though a negative sign doesn't make sense on a 0.
17:18:30 * hartsocks admits he's a math geek.
17:18:49 <hartsocks> okay so there's nothing to discuss on BP this round.
17:19:19 <hartsocks> I was waiting for i-2 to pass before I tried cutting code on the service validation BP for Nova.
17:19:21 <garyk> just a quick update regarding the oslo progress.
17:19:38 <garyk> vipin has broken the patch up into a number of small ones.
17:19:40 <hartsocks> Vipin has broken his patch into 3 parts...
17:19:47 <hartsocks> Oh… :-)
17:19:53 <hartsocks> you wanted to give the update.
17:19:58 <garyk> that is, the patch set for the common vmware driver code shared by cinder, nova, glance and soon to be ceilometer
17:20:22 <hartsocks> There was some talk about making the Oslo incubated code a regular library.
17:20:28 <hartsocks> I'm not sure what that means.
17:20:56 <hartsocks> I know it means we get to test the code in the gate as opposed to moving through incubation.
17:21:24 <hartsocks> Anybody here have anything to comment on that?
17:22:23 <hartsocks> I take the silence as a no comment.
17:22:39 <hartsocks> Anyone from Glance or Cinder here?
17:23:19 <kirankv> Can you paste the patch set link for moving common driver code?
17:23:29 <hartsocks> 1 sec...
17:23:43 <hartsocks> #link https://blueprints.launchpad.net/oslo/+spec/vmware-api
17:23:53 <hartsocks> #link https://review.openstack.org/#/q/topic:bp/vmware-api,n,z
17:23:56 <kirankv> Thanks
17:23:59 <garyk> you can look at https://review.openstack.org/#/dashboard/9171 that has the patches posted by vipin
17:24:54 <hartsocks> kirankv: looks like this is also i-3 at the soonest.
17:25:12 <hartsocks> Any other BP we can talk about?
17:26:00 <kirankv> hartsocks: Thanks
17:26:25 <hartsocks> #topic bugs
17:26:46 <hartsocks> So, bugs still targeted at i-2
17:27:08 <hartsocks> #link http://goo.gl/Qhe5Lt
17:27:15 <hartsocks> … that was a nasty query
17:28:37 <rgerganov> I got merge approval for #link https://bugs.launchpad.net/nova/+bug/1252400 and then I had to rebase :(
17:28:43 <garyk> what is good is that they are all in progress
17:29:02 <hartsocks> hmm...
17:29:14 <garyk> which means that they need reviews
17:29:52 <hartsocks> Yeah. Pretty much *no* progress.
17:29:53 <rgerganov> why do you lost approvals if there are no conflicts for rebase?
17:30:11 <hartsocks> rgerganov: if I remember correctly...
17:30:18 <garyk> rgerganov: if the rebase is trivial then jenkins add in the reviews
17:30:28 <garyk> feel free to ping the guys who reviewed and approved the code.
17:30:41 <rgerganov> garyk, ok I will do that
17:30:59 <rgerganov> it is a trivial fix sitting for 3 months ...
17:31:02 <hartsocks> okay, I don't type fast enough. That's all I was going to say. :-)
17:31:05 <garyk> most of the rebasing was my fault - i changed the test file names. humble apoligies
17:31:28 <rgerganov> garyk, yes that was the reason for rebase
17:31:35 <rgerganov> but I didn't get any conflicts
17:31:38 <garyk> sorry
17:31:54 <rgerganov> I wonder why this is not considered "trivial" by Jenkins
17:32:27 <hartsocks> my guess is the patch's hash changed.
17:32:37 <garyk> you couls always as on #openstack-infra - sure somethere will be able to explain or fix if it is a bug :)
17:33:07 <garyk> fungi or joe gordon ,ay know
17:33:56 <hartsocks> well… the trivial rebase code is here:
17:34:02 <hartsocks> https://www.codeaurora.org/patches/quic/la/gerrit/trivial_rebase.py
17:34:23 <hartsocks> so… the precise reason is somewhere in that… :-)
17:34:49 <hartsocks> "'identical' (determined via git-patch-id) and reapply reviews onto the new"
17:35:12 <hartsocks> git-patch-id is a hash of your patch's contents… so… if 1 character changes… different hash.
17:35:37 <hartsocks> it's not very smart :-(
17:35:52 <rgerganov> the review process is a real pain IMO
17:36:12 <rgerganov> hartsocks, thanks for explaining this though
17:36:36 <garyk> rgerganov: it has its advantages and disadvantages
17:36:45 <hartsocks> Nova's currently got some problems that unfortunately affect the whole stack and as far as I can tell that's soaking up a *lot* of attention right now.
17:36:47 <garyk> basic rule of thumb - is review and your code will be reviewed
17:37:42 <garyk> a few cycles ago i think that vish would joke and say a bp would be approved if someone would give x reviews
17:38:11 <hartsocks> about all we can do is review each other's code.
17:38:27 <hartsocks> I would encourage the team to also review code outside the drivers.
17:38:50 <hartsocks> We should also be building skills so that we can eventually help with the Nova level bugs that are putting the gate in trouble.
17:39:10 <hartsocks> #topic open discussion
17:39:18 <hartsocks> Since were' there in open discussion anyhow.
17:39:57 <hartsocks> i-2 was pretty unsatisfying.
17:40:36 <hartsocks> Personally I looked at this SSH timeout bug a few weeks ago. I know garyk also looked at a few weeks after me. I was never able to make any progress. How did that go?
17:41:01 <garyk> i posted 2 patches which would help isolate the issues. they are still in review
17:41:17 <hartsocks> #link https://etherpad.openstack.org/p/nova-gate-issue-tracking
17:41:22 <garyk> i also posted one which break the gate for neutron - still in review….
17:41:44 <hartsocks> garyk: how do you know your patch fixes the issue?
17:42:16 <garyk> i did not say that they fix problems, they help identify problems.
17:42:24 <hartsocks> garyk: okay.
17:42:33 <garyk> say for example with the ssh - we know if the server or the guest networking is the problem
17:42:44 <garyk> it is mainly the wiring of the guests that causes the problems
17:43:07 <garyk> problem with the gate is that there are moving targets.
17:43:20 <hartsocks> #link https://review.openstack.org/#/c/66201/
17:43:23 <garyk> once it is networking, one it is virtual disks, one it is a race that got through the gate….
17:43:26 <garyk> wip
17:43:31 <hartsocks> you have an interesting comment there…
17:43:55 <garyk> ah, now i see the -1
17:43:58 <hartsocks> "Since this change is, reasonably for this case, a change to not use exponential backoff that variable should be like 'wait_time' and not be a fraction."
17:44:03 <hartsocks> This is interesting...
17:44:13 <hartsocks> because I think we have a 1.0 in our wait time.
17:44:25 <garyk> if they did the mat then they would see that the exponentional timeout is 1 sec every time
17:44:30 <garyk> that is wrong
17:45:08 <hartsocks> In general, from my days as an embedded C programmer I remember use of floating point is to be frowned upon.
17:45:13 <garyk> i'll address the comment. thanks for pointing the −1 put
17:46:02 <hartsocks> That's because FP calculations aren't smooth … that is you have gaps in IEEE representations between 0.0 and 1.0
17:46:42 <hartsocks> … so in a system where you are doing lots of math on fractional values you can get non-integral representations of numbers as they move through certain hard to represent fractional values.
17:46:50 <hartsocks> But...
17:46:54 <hartsocks> this is Python.
17:47:16 <hartsocks> so… we have different number representations.
17:47:18 <hartsocks> :-)
17:47:23 <hartsocks> math geek. remember.
17:47:50 <hartsocks> anyway… in my gut, I feel like these time representations should never be fractional anyway.
17:48:17 <garyk> thanks, i am going to drop the floating no.
17:48:37 <hartsocks> You always have a discrete monotonic representation of time in a computer. It's the clock cycle. :-)
17:48:54 <hartsocks> okay.
17:49:13 <hartsocks> well, we have lots of time for open discussion or we can sign off.
17:49:20 <hartsocks> any other topics?
17:50:50 <hartsocks> we're on #openstack-vmware if people need to chat.
17:52:14 <hartsocks> I'm going to try and cut a version of the service validation code over the next two weeks. I want it available for reaction at https://wiki.openstack.org/wiki/Nova/IcehouseCycleMeetup
17:52:42 <hartsocks> I figure if I'm in person in front of folks they can throw eggs, or otherwise give feedback.
17:52:56 <hartsocks> If nobody has another topic that's it today.
17:53:34 <hartsocks> #endmeeting