17:01:18 <tjones> #startmeeting vmwareapi
17:01:19 <openstack> Meeting started Wed Jun 18 17:01:18 2014 UTC and is due to finish in 60 minutes.  The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:23 <openstack> The meeting name has been set to 'vmwareapi'
17:01:31 <tjones> hi folks
17:01:35 <arnaud> o/
17:01:42 <kirankv> Hi!
17:02:24 <mdbooth> hi
17:02:31 <browne> hi
17:02:54 <tjones> ok so from our AI last time we were all going to review 2 patches to unblock some other work.  no one (including me) has reviewed them
17:03:06 <tjones> #link https://review.openstack.org/#/c/59365/
17:03:17 <tjones> #link https://review.openstack.org/#/c/91005/
17:03:29 <tjones> garyk: you around?
17:04:23 <tjones> hmmm..  without garyk my plan is not going to work.  I was going to review them in this meeting
17:04:31 <garyk> hi
17:04:36 <tjones> ah there you are
17:04:36 <vuil> o/
17:04:56 <mdbooth> Other people can review too :)
17:04:59 <tjones> so i was saying no one (including me) has reviewed the 2 patches we wanted to get reviewed from last week
17:05:07 <rgerganov> hi. I will be around for 15-20min
17:05:11 <tjones> mdbooth: they are garyk patches so i wanted him here
17:05:11 <mdbooth> Whoa, patch set 35
17:05:43 <mdbooth> tjones: Is it worth discussing rgerganov's stuff first?
17:05:45 <garyk> i am here
17:06:19 <tjones> ok let's pause this since rgerganov needs to drop off
17:06:25 <tjones> and get back to it
17:06:36 <tjones> rgerganov: you have stuff?
17:06:57 <rgerganov> so I had updated the SPBM patch and tried to address some of the concerns that mdbooth brings into his api proposal
17:07:07 <tjones> link please?
17:07:16 <rgerganov> https://review.openstack.org/#/c/66666/
17:08:10 <rgerganov> I am thinking to implement the same changes in oslo.vmware, that is separate Vim and Pbm
17:08:38 <tjones> we need to get john to remove -2.
17:08:49 <garyk> tjones: the bp has not been approved
17:09:05 <mdbooth> I like the patch
17:09:08 <mdbooth> However...
17:09:17 <garyk> i think that rado has a very nice direction
17:09:21 <mdbooth> It's problematic
17:09:25 <garyk> why?
17:09:38 <mdbooth> Because it changes Vim in Nova in a way which is incompatible with oslo.vmware
17:09:57 <garyk> not really, it is inline (i think)
17:09:57 <mdbooth> While we already have an outstanding patch to migrate to oslo.vmware
17:10:08 <mdbooth> Which I am simultaneously proposing we substantially rewrite
17:10:22 <mdbooth> So, in isolation I like it
17:10:30 <mdbooth> In context, I think it's adding to a mess
17:10:33 <garyk> i am not in favor of a rewrite at the moment.
17:10:42 <garyk> i added my comments to the spe that you posted
17:10:46 <mdbooth> Well, rgerganov is proposing a rewrite
17:10:53 <garyk> i have yet to see if you addressed them
17:10:53 <rgerganov> mdbooth, that is not true
17:10:55 <mdbooth> That is, an incompatible api change
17:11:12 <rgerganov> how is using oslo.vmware right now?
17:11:13 <mdbooth> I don't think it's worth making multiple incompatible api changes
17:11:16 <rgerganov> s/how/who
17:11:26 <mdbooth> rgerganov: glance, I believe
17:11:33 <tjones> rgerganov: cinder and glance both
17:11:40 * mdbooth is at home and doesn't have a source tree to hand
17:12:19 <rgerganov> I believe that we can still make API changes in oslo.vmware and increase the version
17:12:40 <kirankv> I think ceilometer has already started to use oslo.vmware
17:12:47 <mdbooth> rgerganov: I'm in favour of api changes in oslo.vmware :)
17:12:55 <mdbooth> We just need to coordinate
17:13:06 <mdbooth> I'm against piecemeal changes
17:13:25 <arnaud> mdbooth, if you have suggestions for oslo.vmware, we have a GSoC intern who is looking at it
17:13:45 <mdbooth> arnaud: I put out a bp last week for discussion
17:13:56 <arnaud> link?
17:14:00 <vuil> https://review.openstack.org/99952
17:14:28 <arnaud> ty
17:15:38 <tjones> lets finish up the spbm discussion before moving on to mdbooth bp.  plus we need to get the spec approved.
17:16:01 <mdbooth> If we're going to refactor Vim and PBM, I want session transactions, sane error handling and the death of invoke_api/_call_method() :)
17:16:20 <mdbooth> tjones: Ok, but this was rgerganov's concern
17:16:33 <tjones> ah ok
17:16:37 <rgerganov> I suggest to do incremental changes in oslo.vmware
17:16:50 <arnaud> +1 rgerganov
17:16:55 <rgerganov> I definitely want to separate Vim and Pbm
17:17:07 <mdbooth> Consider what that means, though
17:17:28 <mdbooth> Every incompatible incremental change now requires coordination with multiple projects
17:17:38 <mdbooth> Every one requires a flag day
17:17:49 <mdbooth> You might as well just fix it and have a single flag day
17:17:54 <mdbooth> It's not a large amount of work
17:18:06 <arnaud> you can fix it without modifying the APIs directly
17:18:11 <mdbooth> The only reason we don't just Get It Done(TM) is that it'll take donkey's years in review
17:18:17 <arnaud> and have the flag day later
17:18:37 <arnaud> you don't have an early flag day and then realize
17:20:14 <garyk> i do not following regarding the flag day. theinetgartion should just be a bump on the oslo.version
17:20:18 <garyk> what am i missing
17:20:30 <rgerganov> garyk, that is my understanding as well
17:20:36 <garyk> theinetgartion => integration
17:20:51 <mdbooth> Bumping oslo.version and updating all the code which uses it
17:21:23 <garyk> but that is in one patch
17:21:26 <garyk> 'atomic'
17:21:38 <arnaud> hmm no it's a patch per project using it
17:21:49 <mdbooth> it's a patch per project, per update
17:22:35 <garyk> but that is atomic per project.
17:22:44 <mdbooth> per project, per update
17:22:48 <tjones> mdbooth: i think your concern is with the number of *incompatible* changes.  as rgerganov said incremental changes
17:22:52 <garyk> that is how it is done with oslo changes
17:22:57 <garyk> say for example oslo messaging
17:23:17 <garyk> the oslo code always needs to be backward compatible
17:23:41 <mdbooth> tjones: Right. The current implementation is quite a mess, though. There is very little you can fix in a backwards compatible way.
17:23:57 <mdbooth> e.g. rgerganov's simple refactoring breaks it
17:24:01 <tjones> lets try to get to a plan in the next 7 minutes as we have other stuff needing discussion.
17:24:24 <rgerganov> mdbooth, I am not sure that my change is API breaking for oslo.vmware
17:24:25 <mdbooth> How about we agree to actively discuss it on the list during the week?
17:24:34 <arnaud> mdbooth, the way I see it, is you write a totally new library and for all of the existings functions you change the implementation to call the new stuff
17:24:48 <arnaud> temporarily
17:25:06 <mdbooth> arnaud: Right. That's in my proposal, too.
17:25:10 <arnaud> ok
17:28:09 <tjones> im not seeing how rgerganov breaks stuff either but we are running out of time for this topic
17:28:32 <garyk> how about we set a time tomorrow to discuss this on the vwware channel?
17:28:35 <tjones> shall we agree to continue on the ML this week on this?
17:28:50 <rgerganov> garyk, +1
17:29:20 <tjones> good idea garyk.  shall you propose a time?
17:29:31 <mdbooth> tjones: See 2 lines changes in volumeops and vmops
17:29:40 <mdbooth> +1
17:29:40 <garyk> we can try this time tomorrow unless you guys cab do a little eralier
17:29:56 <mdbooth> I can't do this time tomorrow
17:30:05 <mdbooth> How early can we go?
17:30:10 <tjones> earlier is fine
17:30:20 <mdbooth> 2 hours earlier would be fantastic
17:30:28 <tjones> 9am PST
17:30:53 <tjones> 5pm UTC
17:31:23 <mdbooth> tjones: Works for me
17:31:33 <garyk> cool
17:31:33 <tjones> #action discuss https://review.openstack.org/#/c/66666/ and https://review.openstack.org/#/c/99952/1 tomorrow in openstack-vmware at 4PM UTC (that is 8am PST)
17:31:41 <tjones> ok lets go to approved BP
17:31:47 <tjones> vui - how's it going?
17:32:10 <vuil> fine. Got some good comments re: earlier patches in the refactor review chain.
17:32:22 <vuil> I am updating/rebasing the works
17:32:32 <vuil> rinse and repeat from there
17:32:49 <tjones> great - so moving along
17:33:20 <tjones> the 2 reviews we needed to get to (from last time) still need to be reviewed.  I don't want to do it here due to time, but they are .
17:33:24 <garyk> as long as you are saving water. that is what is importnat
17:33:54 <tjones> #action review https://review.openstack.org/#/c/59365/ and https://review.openstack.org/#/c/91005/
17:34:03 <tjones> that is blocking hotpug
17:34:20 <tjones> #topic BP in review
17:34:21 <garyk> i tried to break them into little ones ....
17:34:31 <garyk> one needs to be rebased - will do tomorrow morning
17:34:33 <tjones> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:vmware,n,z
17:34:48 <tjones> anyone have a BP to discuss?
17:35:37 <tjones> looks like we lost kiran, but his spec is getting closer
17:35:40 <kirankv> i got reviews last week after this meeting and have addressed them, so if reviewers can check them it would help
17:35:46 <tjones> ah there you are
17:36:08 <tjones> #action review https://review.openstack.org/84662
17:36:18 <tjones> kirankv: what about https://review.openstack.org/98704
17:37:28 <kirankv> tjones: https://review.openstack.org/98704 is the one to go first
17:37:34 <tjones> ok good
17:37:35 <mdbooth> Fun! That has inter-nova locking implications.
17:37:46 <tjones> ok if no more BP discussion??  we can move on
17:37:59 <KanagarajM> I have following bug patches https://review.openstack.org/#/c/99623 https://review.openstack.org/#/c/92782/
17:38:03 <tjones> #topic bugs
17:38:06 <kirankv> the other one nova core has concerns of compute looking into datastores of another compute
17:38:15 <tjones> #undo
17:38:16 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x23b3fd0>
17:38:25 <tjones> lets wait a sec before bugs
17:38:56 <tjones> ok you mean the 2nd on has concens, not the 1st right?
17:39:08 <mdbooth> tjones: Copy from another nova
17:39:10 <kirankv> so if https://review.openstack.org/98704  can get reviewed that would be goof
17:39:29 <mdbooth> Haven't looked at the patch, btw
17:39:34 * mdbooth is making assumptions
17:39:47 <tjones> ok good we can focus on https://review.openstack.org/98704
17:39:54 <tjones> #topic bugs
17:39:55 <garyk> KanagarajM: thanks for addressing the comments. I have some minor ones to add.
17:39:57 <kirankv> ok thanks
17:40:51 <KanagarajM> sure Gary. thanks.
17:41:40 <tjones> any other bugs?
17:41:45 <KanagarajM> there is a concern on timeout value used
17:42:05 <arnaud> I have a chain of 3 patches for the iSCSI stuff
17:42:13 <mdbooth> The iSCSI one is still open. arnaud I started reviewing your patches, btw, but I haven't finished yet
17:42:18 <KanagarajM> so I would like to finalize the time out here
17:42:37 <mdbooth> I was going to ask, though, that you rebase them on top of https://review.openstack.org/#/c/99370/
17:42:38 <arnaud> https://review.openstack.org/#/c/97612/ https://review.openstack.org/#/c/100379/ https://review.openstack.org/#/c/100778/
17:42:45 <mdbooth> Again, no point in stomping on each other
17:43:26 <arnaud> mdbooth, this is making some tradeoff but I think this is fine
17:44:14 <arnaud> mdbooth, we discussed with Vui the fact
17:44:20 <tjones> KanagarajM: so you want to timeout after 7200 seconds to be consistent with cinder?
17:44:25 <arnaud> that if the compute node dies when we remove the targets
17:44:35 <arnaud> the target will never be removed
17:45:07 <arnaud> on a steady system: this should not happen, and if this happen, I don't think this is the end of the world
17:45:15 <KanagarajM> yes that was the fact I followed
17:45:19 <kirankv> KanagrajM: It should be left to the earlier default and when VMFS cinder driver is used it should be set to 7200 in the conf
17:45:48 <garyk> kirankv: KanagarajM: yes, 180 sounds more reasonable
17:46:48 <mdbooth> arnaud: I've only looked at the first patch so far, and I haven't finished with that yet
17:46:56 <mdbooth> I think the meat is in the second patch, right?
17:47:02 <arnaud> right
17:47:33 <mdbooth> I think that as long as we don't have the respawning target problem it should be acceptable
17:48:01 <arnaud> anyway it will take some time. I asked Vui to look at it too
17:48:04 <mdbooth> i.e. that if a target exists anywhere it will exist everywhere, and the only way to rid yourself of it is to delete it everywhere before the refresh job runs
17:48:28 <vuil> having gotten around to, but will, promise :-)
17:48:31 <mdbooth> I take your point that it may not be worth spending a lot of time on an edge case
17:48:42 <mdbooth> arnaud: I will review them all tomorrow
17:49:07 <arnaud> ok awesome! thanks a lot mdbooth
17:49:18 <tjones> KanagarajM: you ok with overridding the default if the VMFS driver is used?
17:49:48 <KanagarajM> I will set to 180 seconds as default in the code
17:50:16 <tjones> ok any other bugs?
17:50:29 <mdbooth> arnaud: How about the rebase? Principal change is a refactor to consolidate volumeops and volume_util
17:50:30 <KanagarajM> I have another one
17:50:41 <tjones> KanagarajM: ok
17:50:46 <mdbooth> arnaud: However, I don't expect that to affect the review in any substantive way
17:50:48 <arnaud> mdbooth, I will look at that after the meeting
17:50:49 <mdbooth> It's just code motion
17:51:26 <garyk> i say ship it :)
17:51:29 <tjones> lol
17:51:38 <tjones> KanagarajM: what was your other one?
17:52:46 <KanagarajM> vc driver breaks instances.hypervisor_hostname value https://review.openstack.org/99623
17:53:20 <mdbooth> Nasty
17:53:43 <mdbooth> Surprised they have the same morefs
17:54:10 <garyk> that is why the uuid was suggested
17:54:14 <vuil> morefs typically just grows in monotonically increasing numeric values
17:54:24 <kirankv> KanagrajM: Id rather put the uuid at the end than in between, makes a better reading
17:54:50 <vuil> *thinking about icehouse->juno upgrade implications"
17:55:20 <mdbooth> Ah, different centers
17:55:25 <garyk> somewhat related - at the summit we were asked to drop the nodename support (multi cluster support). i am looking into that
17:55:27 <kirankv> vuil: it is handles by updating the hostname
17:55:29 <vuil> mdbooth yep
17:55:46 <mdbooth> vuil: Why not an upgrade job?
17:55:46 <KanagarajM> I tried the icehouse to Juno for an instance
17:55:59 <KanagarajM> and worked properly
17:56:10 <kirankv> garyk: do you have a spec for that?
17:56:24 <garyk> kirankv: i am in the process of drafting a mail.
17:56:33 <garyk> i'll shoot it past you first as you did this work
17:56:52 <KanagarajM> the normalize_nodename method take care of it
17:57:13 <kirankv> garyk: thanks
17:57:31 <vuil> mdbooth: sounds like it is handled in the patch re: upgrade, will look at it further
17:57:50 <mdbooth> vuil: Sounds like removing multi cluster makes this go away
17:57:51 <kirankv> mdbooth: this is an edge case, the user has to create the same named clusters in the same order to hit the bug
17:57:54 <mdbooth> i.e. what garyk said
17:58:17 <tjones> ok 3 minutes - apart from the ordering of displayname/uuid - any other issues?
17:58:17 <garyk> i think that the normalize will help, but need to look at it in more detail
17:58:21 <KanagarajM> yes but I see this bug in multiple test env
17:58:32 <vuil> I can see it happening a lot in CI type envs
17:58:56 <garyk> yeah, the times for the football games are ridiculous. tjones can you please escalate to management
17:59:00 <tjones> clearly this needs to be fixed - but need to make sure it doesn't break other htings
17:59:01 <mdbooth> lol
17:59:02 <tjones> lol
17:59:21 <tjones> garyk:  you mean soccer?  :-D
17:59:30 <garyk> yeah.
17:59:33 <kirankv> agree gary
18:00:01 <mdbooth> tjones: One to throw over the wall and run away: given that we have no core reviewers, could we do with nominating our own tech lead?
18:00:07 <tjones> ok 1 minute for #open discussion
18:00:28 <tjones> lets move over to openstack-vmware for that discussion
18:00:28 <mdbooth> Not enough time to discuss, but one to mull for next time, maybe?
18:00:37 * mdbooth has to shoot this evening
18:00:43 <tjones> #endmeeting