17:01:00 <tjones1> #startmeeting vmwareapi
17:01:01 <openstack> Meeting started Wed Feb 25 17:01:00 2015 UTC and is due to finish in 60 minutes.  The chair is tjones1. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:05 <openstack> The meeting name has been set to 'vmwareapi'
17:01:20 <tjones1> hi folks
17:01:21 <thangp> o/
17:01:24 <rgerganov> hello
17:02:32 <tjones1> lets get started
17:02:43 <tjones1> thangp: did you get an traction on that bug you were asking about last week?
17:02:53 <thangp> nope
17:03:11 <thangp> i think it's not a high priority bug or item right now
17:03:42 <tjones1> did you ask on the ML or on irc for cores to help look at it…  yeah it is probably not. hmmm..  after k-3 people will be looking at bug fixes more
17:04:16 <thangp> ok...i asked a couple of cores for reviews
17:04:21 <thangp> nothing yet
17:04:34 <tjones1> did they respond at all - like "no time right now" or ignore?
17:04:46 <thangp> ignore
17:05:02 <tjones1> :-(
17:05:11 <thangp> i guess we can wait until after k-3
17:05:22 <thangp> vmware doesnt get a lot of love from nova :P
17:06:19 <tjones1> yeah i guess so.  Lets update https://etherpad.openstack.org/p/VMwareapi-kilo with the links to the bugs we want to push after k-3.
17:06:21 <thangp> it will eventually get through, i hope
17:06:41 <thangp> ok, will do
17:06:45 <tjones1> i added a link a the bottomw for but fixes
17:07:04 <tjones1> rgerganov:  w.r.t. the hypervisor name vs id - is that a DB change?
17:07:16 <rgerganov> yes, it is
17:07:21 <tjones1> :-(
17:07:26 <rgerganov> I discussed that with mdbooth
17:07:59 <rgerganov> he believes that we should enforce only the uniqueness for now
17:08:03 * mdbooth waves
17:08:09 <rgerganov> mdbooth: hey :)
17:08:25 <tjones1> would be really good to get in - he mdbooth.  you guys think this is likely for k given a db change??
17:08:39 <mdbooth> rgerganov: Yes, I'm in favour of the change, but don't want to mix it in with another change.
17:09:05 <rgerganov> mdbooth: agree. let's try to make the field unique first
17:09:28 <tjones1> it's a step in the right direction.  do you have a link handy?
17:09:48 <rgerganov> https://review.openstack.org/#/c/158269/
17:10:46 <mdbooth> tjones1: As for K, it's related to a critical bug, so the process *should* allow it.
17:10:46 <tjones1> thanks
17:10:52 <tjones1> added it to the list
17:10:53 <mdbooth> Whether it will is a different matter.
17:11:01 <tjones1> yeah :-P
17:11:03 <rgerganov> mdbooth: I didn't know that Ironic is also using non-hostnames for hypervisor_hostname
17:11:12 <mdbooth> Yeah, uuids
17:12:09 <mdbooth> As I'm here, will there be an opportunity to discuss https://bugs.launchpad.net/nova/+bug/1329261?
17:12:10 <openstack> Launchpad bug 1329261 in VMwareAPI-Team "vmware: VCdriver creates same hypervisor_hostname for different vcenters with same Cluster name" [Critical,In progress]
17:12:25 <mdbooth> apologies if it was covered earlier
17:12:44 <tjones1> it was not - and yes we can
17:13:04 <mdbooth> Is now good?
17:13:25 <tjones1> yes - go for it
17:13:52 <mdbooth> So, I picked this up because rgerganov mentioned it and it's kinda related to the other thing
17:14:29 <mdbooth> I've rebased the change, but I've been thinking about the data migration issue
17:15:06 <mdbooth> Instances with the wrong node seems less severe than instances with the wrong host
17:15:29 <mdbooth> But I can't help but feel that bad things will happen if we don't migrate them
17:15:35 <mdbooth> Does anybody here have a good handle on that?
17:16:31 <rgerganov> so we need to migrate both compute nodes *and* instances?
17:17:11 <mdbooth> Compute nodes should fix themselves
17:17:26 <mdbooth> i.e. a new one will be created automatically on startup
17:17:37 <mdbooth> And the old one will just go stale
17:17:49 <mdbooth> there's some mechanism which will clean it up iirc
17:18:19 <mdbooth> But instance.node will now point to a non-existent compute node
17:18:32 <mdbooth> I scanned the code, and almost nothing outside the driver uses it
17:18:43 <mdbooth> But almost > nothing
17:18:56 <rgerganov> I remember that some of the core reviewers wanted to remove the node property
17:18:56 <mdbooth> And I couldn't convince myself that it was definitely safe to leave alone
17:19:27 <mdbooth> Well that's not going to happen any time soon without kicking Ironic out of tree
17:19:39 <rgerganov> what if we create a script which updates the node field of existing instances?
17:20:02 <rgerganov> there was a nova-manage or something like that ...
17:20:04 <rgerganov> sec.
17:20:12 <mdbooth> I thought of that. It's going to need to be passed the vcenter's uuid as a parameter
17:21:19 <rgerganov> that should be fine I guess
17:21:33 <mdbooth> I had an idea to do it in init_host
17:21:46 <mdbooth> It's already getting a list of all instances associated with a host
17:22:07 <mdbooth> If it passed that list to the driver, we could update it at startup
17:22:27 <rgerganov> but that means putting VMware specific code in the compute manager?
17:22:43 <rgerganov> maybe I am missing something
17:22:50 <mdbooth> It would mean adding an extra driver method
17:23:05 <mdbooth> and having the vmware driver implement it
17:23:09 <rgerganov> no one will approve that :)
17:23:16 <tjones1> hahahaha
17:23:19 <mdbooth> My thoughts precisely :/
17:23:51 <rgerganov> let's go with a migration plan which involves running a script
17:24:06 <rgerganov> we did the same when deprecated the ESX driver as far as I remember
17:24:38 <mdbooth> So the current patch does this:
17:24:40 <mdbooth> https://review.openstack.org/#/c/99623/16/nova/virt/vmwareapi/driver.py,cm
17:24:45 <mdbooth> _normalize_nodename
17:25:37 <mdbooth> How about we leave that in there, and handle the data migration independently?
17:26:09 <rgerganov> in other words supporting the old node names for some period of time?
17:26:47 <mdbooth> To be precise, it would mean that the *driver* would support the old node names
17:27:03 <mdbooth> There may be other Nova code that doesn't like the mix of node names
17:27:11 <mdbooth> That's the bit I was concerned about
17:27:23 <mdbooth> I couldn't convince myself it doesn't exist
17:27:28 <rgerganov> ok, I get it now
17:28:08 <rgerganov> are you going to post the rebased patch?
17:28:13 <mdbooth> rgerganov: Yes
17:28:17 <rgerganov> ok, thanks
17:28:19 <mdbooth> Not this evening, though
17:28:26 <rgerganov> no hurry :)
17:28:27 <mdbooth> It's mostly done.
17:28:34 <mdbooth> Passing all tests.
17:28:34 <tjones1> i've added this one to the list BTW
17:29:12 <tjones1> we'll want to get a minesweeper run on it of course
17:29:26 <mdbooth> +1
17:29:59 <tjones1> any other critical bugs we should be trying to get into k?
17:33:31 <tjones1> anything else anyone wants to bring up?
17:33:34 <tjones1> if not we are done
17:34:17 <rgerganov> I don't have anything else
17:34:31 <tjones1> ok thanks guys.  have a good week
17:34:35 <tjones1> #endmeeting