17:03:22 #startmeeting VMwareAPI 17:03:23 Meeting started Wed Nov 13 17:03:22 2013 UTC and is due to finish in 60 minutes. The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:26 The meeting name has been set to 'vmwareapi' 17:03:48 it's not replication it standard call migrate_volume 17:04:19 Hey folks. Last week was the summit. 17:04:31 So we're just starting our IceHouse efforts. 17:05:01 I'm going to spend some quality time with the bugs & reviews today and send out a note later. 17:05:59 but, for today, I'll post the etherpad link Tracy & Gary used during the HK summit. 17:06:01 #link #link https://etherpad.openstack.org/p/T4tQMQf5uS 17:06:09 #undo 17:06:09 Removing item from minutes: 17:06:12 #link https://etherpad.openstack.org/p/T4tQMQf5uS 17:06:58 Do we want to discuss blueprints that came out of that talk? 17:07:46 i've started one on the heathcheck (config check) item. Ive gotten some interest from another team as well 17:08:21 https://launchpad.net/rubick 17:08:35 hi 17:08:40 tjones: hello 17:08:46 hi ogelbukh 17:08:47 Hey all, Sabari here. Didn't realize Daylight ended, and we have the meeting an hour earlier. 17:09:04 I confirm we're working on the configuration validation topic 17:09:05 i have not had a chance to look into your project yet but will today. 17:09:13 thanks! 17:09:21 great - lets not duplicate work :-) 17:09:26 tjones: it would be awesome to get your feedback 17:09:39 Today I Learned (TIL) project Rubick. 17:10:12 :-) hartsocks it would be great if you can take a look too as this started out as your idea 17:10:21 ogelbukh: so you are on Rubick? 17:10:28 hartsocks: yes 17:10:32 tjones: Ideas are cheap, execution is hard. :-) 17:10:37 LOL 17:10:47 we're getting it to stackforge atm 17:11:09 ogelbukh: so we started out (not just me) thinking we should fail-fast if our driver is configured wrong. 17:11:11 we have a basic framework and reference implementation 17:11:24 for keystone and couple other services 17:11:39 nice 17:11:39 hartsocks: that's reasonable 17:11:58 ogelbukh: so this project would fit that? 17:12:45 I guess I'm asking if it will be a library, service, or etc. 17:13:10 well, we're planning it to be a service 17:13:18 but we're in early stage now 17:13:38 so we could adjust it 17:13:51 for example, get a library and API service around it 17:14:16 nice. 17:15:19 and as I understand you want some call that will tell if the configuration is valid 17:15:30 as a hook in startup script 17:15:33 correct? 17:15:46 basically, I'm all about accomplishing more with less work. If something validates the config already, let's not do that again. 17:15:49 (one option) 17:15:52 ok 17:15:53 yes there were 2 issues - bad config and servce health 17:16:19 good point. Service health is a separate but related thing. 17:16:30 yep 17:17:25 hartsocks: tjones: could you explain your vision of service health check? 17:17:42 * hartsocks defers to tjones c 17:17:51 just check that vCenter API is responsive? or something else? 17:18:16 perhaps we can meet separately on this once we have a chance to take a look ? so for checking our connection to VC - we would check that we can talk to it, that the clusters defined are there, that there are hosts in the cluster (other stuff probably) 17:18:42 I think there is health service in vCenter 17:18:49 sure 17:19:01 there is but this is more checking that the nova.conf info matches what is in VC 17:19:01 that deserves separate meeting 17:19:11 and probably more than one ) 17:19:29 ogelbukh: yes i am sure more than 1 ;-) 17:19:38 okay. 17:19:52 We'll watch that one with interest. 17:20:09 hartsocks: does it worth an action item? 17:20:46 #action tjones, hartsocks to follow up with ogelbukh on project Rubick 17:20:57 excellent! 17:21:00 thanks 17:21:03 ogelbukh: what timezone are you in? 17:21:12 GMT+4 17:21:47 ok will schedule appropriately 17:22:01 thx 17:22:45 Any other interesting/new things to come out of Hong Kong's design summit folks want to talk about? 17:23:25 I heard live-snapshots were nixed. I was looking forward to writing that one. 17:24:16 i've got a link somewhere with notes… looking 17:24:57 here we go - https://etherpad.openstack.org/p/IcehouseNovaSummit 17:25:10 hartsocks, they said NO to discovery of existing vm(s) 17:25:26 dims: they said NO many many times :-D 17:25:49 *lol* 17:25:50 :) 17:26:25 NO 17:26:29 oh, sorry, it's a reflex 17:26:35 *lol* 17:26:59 see - he did it again ;-) 17:27:00 i have a TODO to write a blueprint for passing hints to select specific datastore / compute based on tags or something else 17:27:07 dansmith, LOL 17:27:27 dims: oh! wait... 17:27:41 #link https://blueprints.launchpad.net/nova/+spec/vmware-datastore-selection-by-scheduler-filter 17:28:18 I wrote this BP up a while ago, 'cuz the way we're doing datastore now is kind of forced by not getting any hints down from the scheduler. 17:28:21 another feedback was to find a better abstraction other than the virt driver (may be something similar to cells) over time 17:28:52 +1024 17:28:56 hartsocks, right, if we can get scheduler to help select something, then the driver would honor that 17:29:29 dims: yeah, our current driver design is just the way it is because the scheduler doesn't know about the datastores. 17:30:01 dims: however, I don't know much about cells. 17:30:11 dims: is that a distributed scheduler design? 17:31:29 hartsocks: cells breaks nova up into .. cells 17:31:51 hartsocks: but specifically, it breaks it up into chunks of things that have their own scheduler inside them, and a group of compute hosts 17:32:05 so something gets scheduled quickly to a cell, and then again within the cell 17:32:23 hartsocks, a nova cell would be one implementation is what i heard being said - https://wiki.openstack.org/wiki/Blueprint-nova-compute-cells...someone has to come up with API's so a nova cell or a vsphere impl would be 2 implementations of something higher than a virt driver 17:32:43 the way you guys are treating a whole vsphere cluster as a single compute host through the virt driver API is something we want to do away with at some point, and exposing yourself as a cell may be the way to do that 17:32:56 you're not the only offender, just the most icky one :) 17:33:05 * hartsocks bows 17:33:44 hartsocks, there was general admiration for the minesweeper work. so kudos. 17:33:46 and I meant "vmware" not "hartsocks" as the target of my "you're" of course 17:33:56 In our defense, we kind of inherited what's there now and had to make it "work" :-) 17:34:18 :-) 17:34:24 hartsocks: not only that, but there is no higher abstraction in which to plug yourselves in, so it couldn't be any different right now anyway 17:34:57 right 17:35:00 dansmith: isn't VC like a cell then? 17:35:23 tjones: I don't actually know the details of VC, VS, etc 17:35:34 Just for group knowledge... 17:35:50 tjones: but anything that hides >1 compute node behind a single virt driver in nova is what we're trying to avoid 17:35:53 concepts look very similar to me 17:35:58 vCenter is a server that binds multiple ESXi together. 17:36:06 i.e. anything that ends up scheduling underneath nova 17:36:10 though I'm not an expert in vmware nor in cells 17:36:13 the hypervisor + API are in aggregate called vSphere. 17:36:43 hartsocks: meaning vcenter is a thing, and vcenter+esx == vsphere ? 17:36:49 yeah 17:36:53 more or less. 17:36:54 okie 17:37:04 The bare hypervisor has API 17:37:07 the main difference between cell and vsphere+vcenter is that cells communicate via rpc 17:37:08 hartsocks, problem is right now we implement driver.ComputeDriver - someone needs to define driver.CellDriver and Nova Cell and VC and ovirt would be implementations 17:37:10 The vCenter has API 17:37:16 so yeah, if the nova driver is managing an ESX, then that's fine. if it's managing a vcenter then it's bad 17:37:39 BTW … together all the API are vSphere 17:37:46 which would not be a case with VC to my knowledge 17:38:52 vCenter can do some things that are scheduler level… but… I think there are some things it doesn't do. 17:39:23 The API are easier to work with through vCenter… so what I would hope is ... 17:39:34 * hartsocks digs out blueprint 17:39:47 #link https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory 17:40:06 … this would be having vCenter just act as an API proxy to the driver. 17:40:09 so some driver will be required in cells 17:40:23 to plug in vc api to replace an rpc 17:40:28 right? 17:40:46 hartsocks: is vcenter a horizontally scalable service? 17:40:54 not really. 17:41:12 it's a kind of management API server. 17:41:13 hartsocks: then it's pretty uncloudy to use it for more than one compute node, right? 17:41:24 I don't mean to take up your meeting time with this, it just snowballed 17:41:43 heh. I'm kind of bad for letting things go into the weeds. 17:42:00 Just to cap this off tho' 17:42:10 you can link multiple VC to scale out 17:42:27 wow - sorry for the bold - dunno how that happened 17:42:39 tjones: I don't see bold 17:42:49 ok good - i do 17:42:53 looks like shouting 17:42:59 *lol* 17:43:57 Long and short… I don't think the metaphors match up cleanly so I think we need some creative lee-way... 17:44:06 hartsocks: i think we need to look into cells and see how this maps out 17:44:20 again, cells is not really suitable for this right now, 17:44:38 dansmith: is that something we should invest in helping with? 17:44:47 we're just saying you seem a lot more like a cell than a virt driver, but I'm happy to have a discussion about the real architecture of vmware stuff so we know what we're talking about 17:45:06 hartsocks: yes, definitely 17:45:11 cool. 17:45:27 #action vmwareapi team to spend some time with cells 17:45:27 but lets have a discussion about what vmware really looks like under the covers sometime before we get too far towards anything 17:45:45 #undo 17:45:46 Removing item from minutes: 17:45:49 okay how about this... 17:46:19 #action vmwareapi team to discuss driver and cells with core team 17:46:25 sure 17:47:34 #topic open-discussion 17:47:45 not that we weren't kind of there already. 17:47:56 :-) 17:48:02 :-D 17:48:40 ) 17:49:09 If you have a "my pants are on fire" bug… nows the time to mention it :-) 17:50:34 is it ok to work on this bug: https://bugs.launchpad.net/nova/+bug/1216209 17:50:46 or this is in conflict with the scheduler story 17:50:50 from the blueprint? 17:51:51 rgerganov: IMHO we have to make what's there work reasonably, many of these things will take significant time to iron out… so… especially if it's back-port potential we should still fix it. 17:52:19 vuil: are you working on that one? 17:52:27 it's assigned to you 17:53:59 I'm going to target that one to icehouse-1 … that seems like a significant thing to get working. 17:54:15 ok 17:54:34 rgerganov: thanks for highlighting it. 17:54:40 vuil: please tell if you don't mind to help on this 17:54:47 sure 17:55:05 #action followup on +bug/1216209 17:55:13 im looking for him in the other room but he's not around. 17:55:50 yeah, we'll have to follow up later. I figured the DST change would mess up some people 17:57:02 Anything else folks need to talk about? 17:58:40 Okay. 17:59:27 We're over in #openstack-vmware if you want to chat. 17:59:31 #endmeeting