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