17:01:33 <tjones> #startmeeting vmwareapi
17:01:34 <openstack> Meeting started Wed Jun 11 17:01:33 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:35 <Arkady_Kanevsky> can we provide pointer to both WIPs on meeting schedule?
17:01:36 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:39 <openstack> The meeting name has been set to 'vmwareapi'
17:01:45 <navneet_> ejgriffith:np
17:01:48 <tjones> hi who is here today?
17:01:52 <arnaud> o/
17:01:53 * mdbooth is here
17:02:14 <browne1> hi
17:02:16 <garyk> hello
17:02:43 <tjones> vuil:  you here?
17:02:45 <kirankv> hi!
17:03:05 <tjones> hey kirankv - haven't seen you in a while.  welcome back
17:03:09 <vuil> yep
17:03:24 <tjones> ok great - lets get started with our fav topic
17:03:25 <kirankv> tjones: :) thx
17:03:35 <tjones> #topic approved BP
17:03:48 <tjones> vuil: want to let us know how phase 2 refator is going?
17:04:15 <vuil> phase 2+3 are happening in parallel.
17:04:29 <dims__> o/
17:04:31 <vuil> I just updated the phase 2 patches, they are ready for review
17:04:39 <tjones> do you have a link to share with all of the patches in order?
17:04:46 <garyk> vuil: can you please post the first patch
17:04:53 <vuil> phase 3 needs to be updated on top of them, and still needs some decomposition
17:04:55 <tjones> even i am getting lost
17:04:56 <garyk> tjones: you beat me :)
17:05:13 <vuil> a sec
17:05:30 <vuil> Not first, but https://review.openstack.org/#/c/87002/
17:05:46 <vuil> and all its dependencies technically are phase 2 stuff
17:05:54 <tjones> following the links - this one looks 1st https://review.openstack.org/#/c/99238/2
17:06:08 <vuil> there were some reordering of the patches
17:06:59 <vuil> there is an 'image handling' patch that I am trying to rebase to the right parent after all these motion. if you start at 99238 you may see it hanging out in an odd place. Will fix after the meeting
17:07:03 <dims__> vuil, commit message is missing blueprint info - https://review.openstack.org/#/c/99238/
17:07:53 <tjones> vuil: it's pretty confusing  with the multiple dependencies.  if you could add a section to https://etherpad.openstack.org/p/vmware-subteam-juno with all of the patches in review order i think it would help.  then i can send a message to the ML with this and other info on what we are doing
17:07:54 <vuil> well that one technically is just code cleanup, encountered while I refactor the code for sure...
17:08:38 <dims__> ah there is a fork as well in the dependency chain
17:08:44 <vuil> sure. Gimme 1/2 hour after the meeting. Once the rebase is done we should have a main chain of commits which should make things clearer
17:08:57 <tjones> as a team our absoute highest prio is the review of this patchset.
17:09:06 <tjones> s/this/these
17:09:10 <dims__> +1 tjones. sounds awesome vuil
17:09:21 <mdbooth> Unfortunately I'm not at my desk, but when I get in to the office tomorrow I have a little tool which generates dependency trees from outstanding gerrit patches
17:09:31 <tjones> ohh - nice! mdbooth
17:09:48 <tjones> that would be very helpful (not just for this one)
17:09:50 <mdbooth> Where should I post the output?
17:10:03 <tjones> in that etherpad would be great
17:10:04 <mdbooth> Or the tool, for that matter
17:10:08 <mdbooth> Ok
17:10:33 <tjones> anything else about the refactor?
17:10:46 <tjones> #action vuil to update https://etherpad.openstack.org/p/vmware-subteam-juno on the patchsets
17:10:56 <tjones> #action tracy to send out email to the ML asking for reviews
17:11:05 <tjones> #action all of us review these patches
17:11:16 <tjones> #action mdbooth post the tool and output to https://etherpad.openstack.org/p/vmware-subteam-juno
17:11:31 <mdbooth> tjones: garyk and I also have outstanding refactor patches, although not directly related
17:11:41 <vuil> @dims re: fork, yes and no, (98322 looks like one, but after rebase will be part of chain). That said, I set 98529 aside as a branch as I think of it as somewhat orthogonal to the refactoring work.
17:12:35 <dims__> vuil, thanks for the clarification
17:12:50 <tjones> yeah but i am worried about this.  we need the big ones done so we can add features for juno.  i know there allways will be refactor work - but i don't want to block new features on the piecemeal ones.  how do you guys think we should handle this?
17:13:04 <tjones> with the core team?
17:14:03 <tjones> one could argue that power_off should have been part of phase 1
17:14:47 <dims__> tjones, from discussions with mriedem, he is expecting disk and image handling in spawn to get broken down, once that is done the refactor is done IMHO
17:14:50 <vuil> as long as the changes are orthogonal to the main refactor work, I am somewhat okay. Then it is just a review priority thing.
17:15:18 <tjones> dims__:  good as long as once that is done we can continue feature work i am happy
17:15:31 <tjones> ok anything else on approved BP?
17:15:35 <vuil> things that interferes with the main commit refactor chain can cause rebase headaches, so please be cognizant of it
17:15:49 <dims__> lets keep the patch series in refactor to just that and not expand the scope
17:15:57 <dims__> right vuil
17:16:03 <mdbooth> vuil: garyk just had a patch +2d which will touch almost everything
17:16:05 <tjones> garyk: mdbooth could you pause on those patches until phase 2/3 is done?
17:16:06 <mdbooth> although trivially
17:16:30 <dims__> tjones, i don't think we should stop pushing
17:16:47 <vuil> which one is it?
17:16:57 <mdbooth> https://review.openstack.org/#/c/91352/
17:17:15 <tjones> oh yeah that one
17:17:23 <mdbooth> It's been approved, in fact
17:17:24 <tjones> it's merging.  we are ok
17:17:27 <mdbooth> :)
17:17:32 <tjones> :-D
17:17:35 <dims__> tjones, mdbooth rebase is the cost we have to bear :)
17:18:11 <tjones> just don't want to step on eachothers toes as *much* as we were in icehouse.  that was unbearable.  and in fact the one of the purposes of refactor
17:18:12 <vuil> will be fun, but this we should be okay.
17:18:24 <tjones> ok lets move on
17:18:38 <tjones> garyk: hot plug??
17:18:57 <mdbooth> How many toes does https://review.openstack.org/#/c/97170/ step on?
17:19:26 <garyk> mdbooth: it does not step on any :)
17:19:47 <tjones> even any of vuil?
17:19:47 <garyk> i think that the only contenious code at the moment is the actual spawn and vmops related stuff
17:20:00 <garyk> the power off does not even clash with those
17:20:09 <tjones> great
17:20:19 <garyk> i think that we should be prgamatic about things (but that is me)
17:20:21 <dims__> good news all around
17:20:25 <mdbooth> Ok, in that case I will continue trying to get reviews on that
17:20:26 <dims__> +1 garyk
17:20:37 <tjones> then we are ok.  garyk are you pausing on hotplug until refactor is done?
17:20:55 <garyk> tjones: at the moment it is in review. has been for over 2 months now :(
17:21:04 <tjones> i know….
17:21:13 <garyk> i guess it will be a matter of rebasing after the spawn code is in
17:21:23 <tjones> yeah ok lets leave that then for now
17:21:32 <garyk> even though it is authogonal (most prba spelt wrong)
17:21:37 <vuil> +1 gary,mdbooth on the general approach to this
17:21:39 <garyk> there are 2 new vmops methods :)
17:22:24 <garyk> it sucks to not work on features but i think satellite things to vmops can and should be done
17:22:38 <dims__> did anyone pick up the work to "ensure one nova compute process == one cluster"
17:23:15 <dims__> do we need a blueprint for it?
17:23:22 <tjones> listens….
17:23:24 <vuil> not that I am aware of
17:23:30 <vuil> on both qns
17:23:44 <tjones> me either.  just a note in my head that it needs doing
17:23:45 <vuil> on first qn :-)
17:23:49 <dims__> ok, let me poke on it and let u all know
17:23:52 <garyk> dims__: tjones: vuil: i was planning on doing that
17:23:55 <tjones> dims__: thanks
17:24:06 <tjones> ok lets talk about unapproved BP now
17:24:13 <garyk> my major concern with it is backward and forwards compatibility.
17:24:16 <tjones> #topic BP under review
17:24:37 <tjones> #undo
17:24:37 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x2452690>
17:24:41 <dims__> garyk, ok, i'll help, you have the pen :)
17:24:55 <garyk> dims__: ok.
17:25:03 <garyk> i'll sync up with you tomorrow
17:25:12 <tjones> ok good
17:25:20 <tjones> #topic BP in review
17:25:23 <tjones> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:vmware,n,z
17:25:43 <tjones> who wants to discuss their BP?
17:26:13 * mdbooth *still* hasn't written up the oslo.vmware api BP
17:26:15 <kirankv> VMware nova-Storage optimization for clusters with multiple datastores
17:26:30 <garyk> garyk: ephemeral disks
17:26:35 <tjones> #link https://review.openstack.org/98704
17:26:40 <kirankv> https://review.openstack.org/#/c/95907/5/specs/convergence.rst
17:26:44 <garyk> idea is to waut till after the spawn to add the code
17:27:00 <tjones> yes but we do need to get the specs approved
17:27:07 <kirankv> oops wrong link
17:27:09 <kirankv> https://review.openstack.org/#/c/98704/4
17:28:01 <tjones> dims__:  has a -1
17:28:18 <mdbooth> Looks like trivia, though
17:28:22 <tjones> but not techical issues
17:28:33 <tjones> should we vote 0 on non-technical issues?
17:29:00 <mdbooth> kirankv: I read that earlier. I wondered what the impact was of over-using a single datastore
17:29:23 <mdbooth> Do we balance datastores for performance?
17:29:34 <mdbooth> What would the impact be of a popular impact ending up on a datastore?
17:29:49 <mdbooth> Would it be worth dedicating a simple datastore to the image cache?
17:30:05 <mdbooth> s/simple/single/
17:30:07 <kirankv> mdbooth: As long as we stay in the max limits mentioned in the vsphere doc, we should be fine
17:30:46 <dims__> kirankv, waiting for a response to my questions :)
17:31:25 <mdbooth> dims wrote: If for some reason some datastores need to be off line then it would be very difficult to figure out which vm(s) will be affected. Right?
17:31:38 <mdbooth> So not all trivia
17:31:44 <dims__> right :)
17:32:00 <tjones> didn't scroll down enough - sorry
17:32:10 <kirankv> mbooth: how much to size the simple datastore that caches images would be a challenge
17:32:23 <dims__> we don't need to do this here on IRC do we?
17:32:35 <mdbooth> dims__: Guess not
17:32:42 <kirankv> it really depends on the workloads (flavors) getting deployed
17:33:19 <tjones> we do have time now and it's faster for you guys to discuss it when you are all here.  we have 1 more to discuss after that
17:33:21 <kirankv> dims__ : will respond and address you comments by tommorrow
17:33:51 <mdbooth> The performance balancing thing is a question for platform experts (i.e. not me)
17:34:07 <mdbooth> Just strikes me as a potential issue
17:34:41 <mdbooth> vuil: ^^^
17:35:07 <vuil> :-)
17:35:32 <vuil> I will take a look at the bp and give you my 2c
17:35:55 <tjones> vuil: mdbooth was brining up some performance issues above
17:36:05 <tjones> can you address those as well?
17:36:15 <mdbooth> vuil: My question was: if we're going to create linked clones across datastores rather than making copies, how much of an issue would it be in practise for a popular image to end up on a particular datastore
17:36:29 <mdbooth> Especially when that datastore was picked effectively at random
17:38:18 <kirankv> the blueprint tries to address that by first trying to put the VM on the datastore where the cache is present, another improvement is to distribute the cache across the datastores so that cross referencing across datastores is avoided
17:39:01 <tjones> kirankv: do you mean https://review.openstack.org/84662
17:39:09 <mdbooth> Latter would emasculate the patch though, right?
17:39:46 <mdbooth> Although we could copy directly from another cache
17:40:19 <dims__> mdbooth, right that may be easier for maintenance
17:40:35 <kirankv> tjones: thats a different bp, thats only to optimize performance by avoiding a network transfer
17:40:43 <mdbooth> That would be a different patch, though
17:40:45 <mdbooth> kirankv: right
17:40:54 <vuil> I hope folks are not waiting for me. Still reading...
17:41:37 <tjones> ok lets take an action for kirankv to address dims concerns and vui to address the performance issues and move on? ok with that ?
17:41:48 <mdbooth> +1
17:41:51 <tjones> s/issues/concerns
17:41:58 <kirankv> tjones: ok
17:42:26 <tjones> #action kirankv to address dims__ comments on https://review.openstack.org/98704 and vui to address performance concners
17:42:34 <tjones> #link https://review.openstack.org/86074
17:42:38 <tjones> garyk:  you are up
17:42:47 <garyk> tjones: not much to update
17:42:54 <garyk> ephemeral is up for review
17:43:03 <garyk> i'll post a link in a sec
17:43:14 <tjones> #link https://review.openstack.org/#/c/86074/
17:43:40 <garyk> :)
17:43:44 <tjones> johnthetubaguy: was interested in this before
17:43:44 <garyk> spbm is also in review
17:44:03 <garyk> https://review.openstack.org/84652
17:44:37 <tjones> funny that is not on my list
17:44:42 <garyk> so basically both BP's are waiting for cores
17:44:55 <garyk> the SPBM code has been posted in review since last year december
17:45:16 <tjones> lets make sure that we have 2 guys from our side +1 on the specs before we start pushing cores to review it
17:45:40 <garyk> ok np
17:46:05 <tjones> rado reviewd spmb and arnaud reviewed ephemeral.  can someone else please take a look at these this week?
17:46:21 <garyk> i'll ping them for the reviews. thanks
17:46:23 <tjones> #action review https://review.openstack.org/84652 and https://review.openstack.org/#/c/98704/4
17:46:42 <tjones> no i mean they all ready did - we should get 2 fresh people to look ;-)
17:47:13 <tjones> any other BP discussions?
17:48:10 <tjones> #topic bugs
17:48:11 <tjones> https://bugs.launchpad.net/nova/+bugs?field.tag=vmware
17:48:33 <tjones> 2 new ones
17:48:40 <garyk> tjones: i have been over the bugs and have posetd fixes for 2 networking issues. don't recall the bug #'s off hand
17:48:49 <tjones> ok thanks gary
17:49:07 <tjones> #link https://bugs.launchpad.net/nova/+bug/1325866
17:49:08 <uvirtbot> Launchpad bug 1325866 in nova "Datastore in a Cluster-Datastore fails to enter maintenance mode if instance has a CD-Rom attached to it" [Undecided,New]
17:49:37 <tjones> #link https://bugs.launchpad.net/nova/+bug/1328455
17:49:39 <uvirtbot> Launchpad bug 1328455 in nova "vmware: Instance going to error state while resizing" [Undecided,New]
17:49:55 <tjones> these 2 look like things that customers would get really annoyed by and they have no owner.
17:50:29 <garyk> tjones: i'll try and look at that one tomorrow
17:51:05 <tjones> thanks - other people can volunteer too ;-)
17:51:33 <tjones> #topic opendiscussion
17:51:40 <tjones> ok what else do you want to talk about?
17:52:21 <kirankv> garyk: if you need help in testing them, let me know
17:52:34 <tjones> browne1: to reporter is asking for an update on https://bugs.launchpad.net/nova/+bug/1317393
17:52:35 <uvirtbot> Launchpad bug 1317393 in nova "VMware: operating system not found after upgrade to 5.5" [Medium,New]
17:53:17 <garyk> kirankv: thanks
17:53:18 <browne1> tjones: ok, yes, i saw that.  i'll reply
17:53:25 <tjones> keep going back to bugs - mdbooth hows your iscsi fun going?
17:53:29 <tjones> #link https://bugs.launchpad.net/nova/+bug/1324036
17:53:30 <uvirtbot> Launchpad bug 1324036 in nova "Can't add authenticated iscsi volume to a vmware instance" [Undecided,Confirmed]
17:53:46 <mdbooth> tjones: Discussing it with arnaud right now, actually :)
17:54:08 <tjones> should we assign that one to you since you are working  on it?
17:54:38 <mdbooth> tjones: Sure
17:55:19 <mdbooth> tjones: I spent yet more time thinking about locking
17:55:21 <mdbooth> btw
17:55:25 <mdbooth> Way too much time, in fact
17:55:41 <tjones> lol - we have 5 minutes if you want to discuss
17:55:44 <mdbooth> Which then led me to wondering why I was bothering
17:56:05 <mdbooth> Specifically: under what circumstances might 2 nova instances be accessing the same datastore
17:56:17 <mdbooth> as I understand it, a datastore can only be a member of 1 cluster, right?
17:56:36 <mdbooth> So we'd need to have multiple novas managing a single cluster
17:56:41 <vuil> that would be a clean way to go, but not necessarily
17:56:54 <mdbooth> vuil: So clusters can share a datastore?
17:57:10 <vuil> yeah.
17:57:44 <mdbooth> vuil: Sight
17:57:47 <mdbooth> s/t//
17:57:47 <kirankv> but its recommended not to share datastores except for datastores that are used to host templates etc
17:58:09 <mdbooth> vuil: I thought I'd talked myself out of it :(
17:58:28 <mdbooth> vuil: I came up with a horrible solution involving abusing Events in vsphere
17:58:46 <mdbooth> Also zookeeper, but that requires fencing
17:58:57 <mdbooth> All solutions require session transactions
17:59:40 <vuil> yikes.
17:59:58 * mdbooth has a solid proposal for session transactions
18:00:15 <vuil> I seem to recall there was some other use case where we need the lock, not just multi cluster -> single DS
18:00:34 <vuil> it's escaping me right now
18:00:38 <mdbooth> If we can assure ourselves that there's only a single nova involved, we can use nova locks
18:00:45 <mdbooth> Which are going to be much faster anyway
18:01:20 <mdbooth> vuil: There's also the vsphere 'solution' thing
18:01:34 <mdbooth> Although I read all the docs and I still don't really understand what it is
18:01:56 <vuil> Looks like we need to take it over to -vmware
18:01:58 <mdbooth> But it sounds like a mechanism to implement custom services
18:02:01 <mdbooth> vuil: Indeed
18:02:31 <tjones> oops - sorry gotta end now
18:02:40 <tjones> we can move over to openstack-vmware
18:02:47 <tjones> #endmeeting