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