17:02:04 <hartsocks> #startmeeting vmwareapi
17:02:04 <openstack> Meeting started Wed Oct 30 17:02:04 2013 UTC and is due to finish in 60 minutes.  The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:05 <avishay> i think we can start with this, and EhudTrainin can expand on the BP to see if other options work and why not
17:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:08 <jgriffith> winston-d: that would be cool, especially since we don't even disconnect int eh current code
17:02:09 <openstack> The meeting name has been set to 'vmwareapi'
17:02:11 <twoputt> hi
17:02:18 * hartsocks waves
17:02:21 <hartsocks> Who's about.
17:02:30 <rgerganov> hi
17:02:43 <garyk> hi
17:02:47 <tjones1> hi
17:03:16 <hartsocks> I know HK is looming. So, my plan was to cover blueprints, then bugs, then yield for any HK discussion.
17:03:55 <hartsocks> #topic blueprints
17:04:15 <hartsocks> I've been looking through this:
17:04:32 <hartsocks> https://blueprints.launchpad.net/nova?searchtext=vmware
17:05:14 <hartsocks> Seeing what folks already proposed. There's been some changes minor in the blueprint process…
17:05:41 <hartsocks> for something to get higher than "low" priority you are supposed to get 2 core developers on board for reviews.
17:06:16 <hartsocks> I think the theory there is to get better review cycles.
17:06:41 <smurugesan> Hi, this is Sabari here.
17:07:08 <hartsocks> hey.
17:07:54 <garyk> hopefully after hk we will have a list of bp's
17:08:07 <hartsocks> well,
17:08:10 <hartsocks> yes.
17:08:23 <garyk> ideally the vmware session will give us an opportunity to share with the community changes we'ed like to make and get their inputs
17:08:38 <garyk> i would hope that this will enable to core reviewers to get an idea what each one is about
17:08:55 <hartsocks> Would you like to discuss anything in this forum or are you saving it all for HK?
17:09:44 <hartsocks> I wanted to bring a few BP that are not nova/vmware specific that I think we should be aware of.
17:09:54 <hartsocks> #link https://blueprints.launchpad.net/oslo/+spec/pw-keyrings
17:10:21 <garyk> there is the etherpad for the session - https://etherpad.openstack.org/p/T4tQMQf5uS
17:10:22 <hartsocks> … I think this blueprint will solve one of our stated goals of getting plain text passwords out of our configurations.
17:10:49 <dims> o/
17:10:49 <garyk> cool
17:11:07 <rgerganov> I guess our SSO blueprint is also related to this goal
17:11:14 <hartsocks> yep.
17:11:24 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/vmware-sso-support
17:11:56 <hartsocks> My thought there was to use our SSO in vCenter with nova some how.
17:12:07 <hartsocks> My current thinking is this might be best broken into two halves...
17:12:18 <garyk> can you please elaborate on the sso?
17:12:23 <hartsocks> … a Keystone plugin and a nova plugin.
17:12:47 <hartsocks> vCenter has a built in SSO facility.
17:12:58 <hartsocks> It implements various security token schemes.
17:13:12 <hartsocks> In particular Holder of Key (HoK) tokens.
17:13:15 <garyk> ok, sounds interesting
17:13:33 <hartsocks> The idea behind a full featured SSO is that you can do "identity proxy" actions...
17:13:46 <hartsocks> that is a person could log in on the CLI or from Horizon and if SSO works properly...
17:14:00 <hartsocks> that identity could be broadcast all the way through to Nova driver communications.
17:14:10 <twoputt_> hartsocks: let's say with have the vmware sso implemented, do you think this is something that can go easily to Oslo?
17:14:17 <hartsocks> I'm trying to get time with the VMware security group to make sure w can do that.
17:14:39 <twoputt_> from my perpective the keyring approach is something that all the projects will get for free
17:14:44 <hartsocks> twoputt_ not sure how to do it yet.
17:14:48 <rgerganov> I have some hands-on experience with our sso because of my other project at vmw
17:15:04 <hartsocks> twoputt_: but yes, that oslo BP I linked to is a better more general solution.
17:15:15 <twoputt_> yes I think so too
17:16:18 <hartsocks> twoputt_ but I'll be running down a few more details to see if there isn't something better to use. The Oslo crypto solution uses a symmetric cipher embedded in the conf.
17:16:32 <twoputt_> ok
17:17:04 <hartsocks> So… there's an added benefit if there can be a transient key security context used… but we can only do that if there's an advanced way to integrate Keystone and vCenter SSO… not sure if it can happen yet.
17:17:33 <hartsocks> But… the Oslo thing. If some of you have a cycle & interest, that's something to watch.
17:17:42 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/vmware-datastore-selection-by-scheduler-filter
17:18:15 <hartsocks> I posted this a while ago… not sure if it fits with Gary's current direction. I would like to kill it if it doesn't.
17:19:25 <garyk> this is one of the topics we'll discuss at the session
17:19:27 <smurugesan> My opinion, I think this is bettter handled at the driver level.
17:19:47 <smurugesan> but it will be interesting to see the other approach as well
17:20:12 <hartsocks> I would actually like to see more distributed logic in OpenStack… but the current design … style? … ethic? … is to locate *everything* in the scheduler.
17:20:40 <hartsocks> Centralized knowledge in the scheduler requires one big thing to know *everything* and decide everything. That can't possibly scale well.
17:21:38 <hartsocks> well, Gary, let me know if I can help or if I need to clarify something for your session.
17:21:48 <smurugesan> I proposed a change to decouple datastore retrieval and selection in the driver. https://review.openstack.org/#/c/52557/1
17:21:59 <smurugesan> the selection can be expanded to add more filters.
17:22:20 <smurugesan> probably we can do it once and better. Need everyones thoughts
17:22:58 <smurugesan> That is one of the ways to collect aggregate stats.
17:23:19 <garyk> help with the scheduling will be great. feel free to jump into the scheduling meetings on tuesdays. there are lots of ideas for improving things
17:24:27 <hartsocks> Hmm… I think something similar to how the Scheduler does filters (these are rules systems rules similar to a Prolog program) is probably a better way to specify some of the policy we have lying around in methods like datastore_ref_and_name …
17:24:30 <garyk> smurugesan: it would be nice if that change also has the regex per clister
17:24:55 <smurugesan> I will incorporate the same as a dependent patch.
17:24:58 <garyk> cluster. not clister
17:25:01 <hartsocks> nice.
17:25:09 <hartsocks> I like small patches.
17:25:11 <hartsocks> :-)
17:25:39 <hartsocks> My concern is the config for our driver will get too big, too complex, and too brittle...
17:25:45 <hartsocks> Which brings me to this BP...
17:25:55 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/vmware-driver-configuration-validator-module
17:26:19 <hartsocks> Dan W. had asked for something like this… which alleviates some problems from a big-heavy config.
17:26:32 <hartsocks> But I think this treats a symptom of a bigger problem.
17:26:47 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/vmware-auto-inventory
17:27:23 <hartsocks> Which was to find some way to "tag" and read vCenter inventory and report it up to the scheduler better.
17:27:42 <tjones1> that would be very cool
17:27:55 <hartsocks> yeah… but *how* to do it is what I'm stuck on.
17:28:12 <hartsocks> I think I've heard other people with the same/similar ideas so… it's something to talk about.
17:28:19 <garyk> thats just an implementation detail :)
17:28:29 <hartsocks> *lol*
17:28:40 <hartsocks> In theory, theory and practice are the same… in practice...
17:28:46 <hartsocks> :-)
17:29:29 <hartsocks> So the decision is how to create the inventory filter to do the job. Ideally you would implement this in such a way you could easily change your mind about that implementation detail later.
17:29:48 <garyk> if it compiles on paper then it will work. or in our case, if it interprets on paper
17:29:58 <hartsocks> ;-)
17:30:13 <hartsocks> All my best work is imaginary.
17:31:09 <hartsocks> I really wish I was going to Hong Kong … *sigh*
17:31:16 <hartsocks> Anyway.
17:31:28 <hartsocks> Just wanted it on y'alls list if it made sense.
17:31:45 <hartsocks> There's one more BP I was browsing and found ...
17:31:50 <hartsocks> #link https://blueprints.launchpad.net/nova/+spec/auto-vm-discovery-on-hypervisor
17:32:11 <hartsocks> This isn't VMware API specific… but it runs counter to some of the assumptions we made in our driver construction.
17:32:49 <hartsocks> It's a VM discovery BP.
17:33:15 <hartsocks> So that when you turn on OpenStack … VMs currently on the … say vCenter … show up in your nova list.
17:33:50 <hartsocks> Just something to watch for.
17:34:22 <dansmith> hartsocks: I don't think that will ever fly, fwiw
17:34:38 <dansmith> hartsocks: so if you're concerned about it, you're "doing it right" IMHO :)
17:34:39 <hartsocks> I'm actually relieved to hear you say that.
17:35:15 <hartsocks> groovy :-)
17:35:50 <hartsocks> I'll try to do my best "ghost in the machine" impression for you during the conference if anyone needs it.
17:36:13 <hartsocks> Any other BP people want to chat about here before HK?
17:36:37 <garyk> at the moment i have two in review
17:36:53 <garyk> 1. start of the implementaion for the image caching
17:37:05 <garyk> 2. vm diagnostics (parity with other drivers)
17:37:48 <hartsocks> nice. I've seen a lot of email flying around on image caching… is there anything in BP, etherpads, or public ML?
17:37:54 <garyk> i hope that by the end of the week there will be a first draft of the actual cache aging (i am debugging and writing unit tests)
17:38:05 <hartsocks> *very* nice.
17:38:29 <garyk> i'll hopefully get a wiki out soon
17:38:53 <garyk> it will just fit into the generic driver model
17:38:54 <hartsocks> okay, it would be good to have public discussion of these things.
17:39:45 <hartsocks> The vm diagnostics work is in a BP? or is it a bug?
17:40:10 <garyk> vm diagnostics is a bp. it was missing functionality in the driver
17:40:22 <hartsocks> link?
17:40:38 <rgerganov> https://blueprints.launchpad.net/nova/+spec/vmware-vm-diagnostics
17:41:10 <hartsocks> okay, I've seen that.
17:41:45 <hartsocks> Any bugs we need to talk about?
17:41:47 <hartsocks> #topic bugs
17:42:09 <hartsocks> BTW: I didn't cut off anyone who had a BP that they wanted to bring up did I?
17:42:57 <hartsocks> Any bugs burning a hole in someone's cloud?
17:43:35 <garyk> from the tags there are 46 vmware bugs.
17:43:50 <garyk> it would be nice if we could make a dent in that and help bring down the amount of nova bugs
17:44:07 <garyk> some are in progress https://bugs.launchpad.net/nova/+bugs?field.tag=vmware (which we need to get reviews)
17:44:33 <garyk> i do not know why the query shows commited one too ;)
17:45:07 <rgerganov> If I want to take a bug I should be looking for status CONFIRMED which is not assigned, right?
17:45:30 <hartsocks> I've been holding off on the weekly review email because I figure everyone is probably focused on the summit. I'll start that up again the week of November 11th
17:45:33 <garyk> part of our triage responsibilities are to confirm the bugs
17:45:45 <rgerganov> ok, I see
17:45:46 <hartsocks> yep. So I have a query...
17:46:00 <hartsocks> https://bugs.launchpad.net/nova/+bugs?field.tag=vmware+&field.status%3Alist=NEW
17:46:10 <vuil> feel free to talk to person assigned to the bug if you are interested in taking over too.
17:46:12 <hartsocks> To find new bugs that haven't been confirmed.
17:46:58 <hartsocks> Sometimes confirming a bug is a lot of work.
17:47:22 <tjones> i've not been able to repo https://bugs.launchpad.net/nova/+bug/1240355
17:47:33 <tjones> (which is why it is not confirmed)
17:47:57 <hartsocks> Yeah. I have a feeling that this break happens in special conditions.
17:48:56 <hartsocks> I can try and look at it, but so far only Gary's said he's seen it before.
17:49:24 <hartsocks> #action shawn follow up on https://bugs.launchpad.net/nova/+bug/1240355
17:50:16 <hartsocks> Any other bugs or is it time for open discussion?
17:51:06 <hartsocks> #topic open discussion
17:51:19 <hartsocks> I have a proposal for Hong Kong...
17:51:24 <hartsocks> OpenSnack
17:51:44 <hartsocks> You would have these informal snack times …
17:51:51 <hartsocks> that's all I got.
17:51:53 <hartsocks> Sound good?
17:52:11 <tjones> ha ha
17:53:23 <hartsocks> Well, with that… we'll plan on resuming on November 13th.
17:53:47 <hartsocks> Unless someone really wants to hold the meeting during the summit.
17:54:27 <tjones> what time is it in HK now?
17:54:31 <hartsocks> Also, a reminder that there's this pesky day-light-savings-time in parts of the world…
17:54:43 <hartsocks> This slot is UTC which has no DLS.
17:54:49 <hartsocks> um..
17:54:56 <hartsocks> 2am
17:55:13 <hartsocks> You don't want to meet at 2am?
17:55:19 <rgerganov> :)
17:55:20 <hartsocks> What?!?
17:55:22 <tjones> not even a little
17:55:23 <tjones> :-D
17:56:14 <hartsocks> okay folks, have fun at your summit. Us internet ghosts will scare up our own fun while you're out.
17:56:15 <vuil> I know you will be up at 2am, shawn. Probably not by choice
17:56:25 <hartsocks> *lol*
17:56:31 <hartsocks> yep.
17:56:53 <hartsocks> #endmeeting