14:00:46 #startmeeting nova-scheduler 14:00:47 Meeting started Mon Aug 10 14:00:46 2015 UTC and is due to finish in 60 minutes. The chair is n0ano. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:51 The meeting name has been set to 'nova_scheduler' 14:00:51 o/ 14:00:58 anyone here to talk about the scheduler? 14:01:59 actually, I'm here after all 14:02:07 * johnthetubaguy kinda lurking 14:02:30 edleafe, cool - so `house leveling', what, it's on a 45 degree angle suddenly :-) 14:03:06 n0ano: nah, some of the support piers have settled a few inches. You get seasick walking from room to room. :) 14:03:30 But they were going to be there all day, and didn't seem like I could help, so I left 14:03:50 ich, out here we have `expansive soil', I have friends that have 2 inch cracks that appear down the side of their house 14:05:19 They said you couldn't build a castle in a swamp 14:05:21 * alex_xu actually around here also 14:05:27 n0ano: well, we just closed the purchase on Friday, and want to get this stuff done before we start anything else 14:05:38 Congratulations :) 14:05:52 morning fellers. 14:06:16 datetime.informal() to you too 14:06:27 OK, looks like we have quorum (except for the europeans still on vacation) so... 14:06:36 #topic liberty patches 14:07:04 the biggest items are jaypipes & bauzas series, hows your's going jaypipes 14:07:50 n0ano: ran into a bunch of annoyances with the PCI handling code and so pushed a patch series to begin refactoring it: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:pci-cleanup,n,z 14:07:57 n0ano: reviews welcome. 14:08:14 n0ano: I plan to rebase resource objects patch series on top of that. 14:08:18 I heard rumblings about PCI issues, sorry you hit that 14:08:31 ick, does the rebase look hard? 14:09:08 * n0ano seems to be a lot of rebasing going on 14:09:23 * edleafe prefers that to freebasing 14:09:50 n0ano: no, just a lot of object version changes. 14:10:26 OK, sounds like it's under control, bottom line is do our reviews 14:10:31 yes. 14:10:53 anything else on patches? 14:11:10 not from me 14:11:36 moving on then... 14:12:05 #topic CPU feature representation 14:12:31 n0ano: just responded to Michal's thread. 14:12:34 I started the thread, got a little response but nothing major yet 14:12:59 jaypipes, I just saw that, need to take time to think about it and the message from Tony about power 14:13:34 n0ano: well, the message from tony was really just mentioning the difference between intel and power "discovery" of cpu caps. 14:14:02 n0ano: bottom line for me on this is that we need to move forward with separating the resource stuff from the capabilities stuff. 14:14:13 I think some people think we're trying to create a common set of capabilities, which is not what I am thinking of... 14:14:31 a common representation but the specific features would indeed be different between architectures 14:14:35 n0ano: with the resources stuff being all the quantitative things and the capabilities stuff being all the qualitative things 14:15:09 n0ano: the fact that we jam all that stuff together into a flavor right now is making our lives much harder than it needs to be. 14:15:25 jaypipes: +1 million 14:15:27 jaypipes, my favorite, how does NUMA topology fit in, since it has quantitateive issues also but is rather static 14:16:02 no, it's not static at all. it's a quantitative measure. 14:16:41 It's possible to hotplug CPUs in some archs I think 14:16:42 jaypipes, `rather` static, it doesn't change without hot plugging something 14:17:04 let's not overthink this... 14:17:18 NUMA topology is a request for a specific set of NUMA resources, nothing more. 14:18:07 it just happens to have a multi-dimensional set of constraints on those resources, unlike a single-dimensional integer-based constraint like amount of RAM. 14:18:29 but at the end of the day, it's just a quantity requested of some resource. 14:18:55 in the same way cpu feature request is a request for a specific set of cpu capabilities 14:19:18 no, it's the opposite of that... 14:19:36 n0ano: there is no quantity/amount in the request fo capabilities/faetures. 14:19:46 n0ano: which is what makes it different from resources. 14:20:05 you don't ask for "5 sse features" 14:20:16 hmm, maybe I'm thinking wrong, resources are consumable but capabilities are just there 14:20:23 right. 14:21:33 so we need common api for capabilities stuff? 14:23:24 sorry, had to strap my wife into here torture device, I'm back now 14:23:30 we need an API for mapping "product service levels" (I think that's what n0ano called them in Rochester?) to a set of host capabilities 14:24:06 jaypipes: can some form of aggregates be used for that? 14:24:09 jaypipes, that's what we've been doing with flavor extra_specs for now, a separate API would be good 14:25:04 edleafe, I'd have to think about that, I don't know off the top of my head if aggregates fits 14:25:26 edleafe: so, they already are... host capabilities are stored in aggregate extra_specs. The problem is there is no user-facing API that would allow them to see "fast crypto" as a capability instead of "sse, mmx, blah blah" 14:26:11 jaypipes: ah, ok. I didn't understand that it was the user-facing stuff that's the issue 14:26:45 edleafe: yeah. 14:28:56 so we'd need to add a way to specify each of these generic things, and add logic in the filter to correlate them to the specific host capabilities? 14:29:34 the logic is already there (to deal with the exta_specs), just redefine that in terms of the new api 14:29:42 * PaulMurray o/ - sorry - just back from hols - need to get used to new time 14:30:28 n0ano: there is logic to say "they asked for fast crypto, and this host has mmx, so it's ok"? 14:30:41 PaulMurray: welcome back! 14:31:12 edleafe, no, `they asked for mmx and this host has mmx, so it's OK' 14:32:10 n0ano: but what jaypipes mentioned is the ability for users to ask for what they need, and have that apply to each hardware's naming of that feature 14:32:23 jaypipes: or am I still understanding it wrong? 14:33:24 n0ano: no, edleafe is correct. the whole idea is to NOT have the cloud user asking for things like sse or mmx or Nehalem processors. We are trying to *abstract* hardware, not hard-code it into our APIs. 14:33:40 I think defining a common feature name that works across all architectures is not going to be possible 14:34:46 I think of it as abstracting the capability, so a Intel uses asks for MMX and a power user asks for foobar, the user still has to know about the underlying architecture if the user wants specific things 14:35:35 n0ano: but what about "cloud" users? They shouldn't have to know jack about what the underlying arch is 14:35:53 the user is already supplying a different image for Intel vs. Power so they already have to know about different architectrures 14:36:14 edleafe, note my last comment 14:38:39 * jaypipes reading EC2 isntance types documentation 14:38:55 which would argue that the capability requirements should be stored in the glance meta-data, not in the flavor 14:39:16 and who define "fast crypto"? The operator? maybe some operator call it as "quick crypto". That means different openstack cloud have different definition for same capcabilites. 14:39:19 n0ano: there are a number of problems with that (see my response to michal) 14:39:56 can we work out a base capability such that users who do know the underlying arch can address specific features, then build an abstraction on top of that? 14:39:58 jaypipes, indeed, I didn't say that was the definitive arguement, I see problems with using glace also, but there is an arguement for it 14:40:08 alex_xu: yes, the operator determines what their service classes map to, capability wise. and yes, each deployment's service levels would be different. 14:40:20 This has the advantage of not boiling the ocean 14:40:33 *not trying to 14:41:03 jaypipes: so image creator can't ensure his image can be used for any opensack cloud...is that ok? 14:41:30 lxsli, an abstraction on top of specifics is fine, trying to create a common abstraction across all architectures - not sure that's possible or needed 14:41:54 alex_xu, n0ano: I am trying to think of an API that doesn't become one big advertisement for Intel-specific stuff. 14:42:06 jaypipes, +1 14:42:20 up until now, we've been able to keep vendor-specific things from leaking out of the API. 14:42:25 I'd like to continue to do that. 14:42:36 n0ano: it sounds useful but not easy to create; so I'm suggesting to worry about that later and make a generic baseline possibility first 14:42:36 so that we don't become "the Intel Nova API" 14:42:50 lxsli: suggestions welcome. 14:42:51 jaypipes: yes, we didn't want that. 14:43:13 jaypipes, no arguement, I think of host capabilities as arbitrary strings, different architectures provide different strings 14:43:32 n0ano: sure, the issue is what gets leaked out fo the API to the end user. 14:44:02 jaypipes: so if users explicitly depend on an an Intel feature they've added that dependency themselves, we didn't impose it on them 14:44:27 n0ano: Amazon is fine being an Intel-only shop and advertising certain things like AES-NI or AVX2 capabilities, but we can't assume that HP Cloud is similar or RAX CLoud. 14:44:57 lxsli, as long as they can also explicitly depend upon a Power feature also 14:45:02 +1 14:46:17 so, if I can summarize, we want... 14:46:21 So I think we can probably get the best of both worlds by allowing vendor-specific capabilities to be set on images (as they are now) and keeping the flavor stuff more generic. 14:46:42 1) arch specific features presented in a generic way 14:46:55 2) explicit features for now 14:47:08 3) aggregated features later 14:47:23 4) not looking for common features across archs 14:47:24 n0ano: what do you mean by "explicit features for now"? 14:48:19 on intel as for AES, on power ask for foobar, sometime in the future maybe ask for `fast crypto' which includes AES 14:48:55 n0ano: that can already be done on the image metadata level, though. 14:49:02 n0ano: which I'm saying is fine... 14:49:13 e.g. asking for AES would be an explicit features, asking for fast crypto would be an aggregate 14:49:23 n0ano: since, in theory, the creator of rthe image knows what is on the image and its dependencies on vebndor-specific stuff. 14:50:38 jaypipes, but we also need a way (currently with flavors) for the cloud provider to contol pricing tiers (since the image is provided by the user not the provider) 14:52:39 n0ano: /me thinks 14:53:09 jaypipes, indeed, hence the ML is a good place for this 14:53:13 running out of time so 14:53:15 #topic opens 14:53:21 anything new for today? 14:53:31 I could use a review of: https://review.openstack.org/211215 14:53:58 lxsli: lol. 14:54:02 It's not really scheduler specific but I need to understand this to do my patch 14:54:06 oh shoot 14:54:09 wrong link >.< 14:54:17 I meant https://review.openstack.org/#/c/210467 14:54:22 but yeah that too >.> 14:54:29 lxsli, sorry only one chance, we'll only review the first link :-) 14:54:45 the first one is just me procrastinating 14:55:12 lxsli: will review that shortly. 14:55:18 thanks 14:56:05 lxsli: are you a vim user? 14:56:10 Oh yes 14:56:30 lxsli: any chance you can ggVGgq that? :) 14:57:03 jaypipes: sure, I looked at some of the others and they used long lines, but I prefer short lines too :) 14:57:20 http://docs-draft.openstack.org/67/210467/1/check/gate-nova-docs/3a9e454//doc/build/html/trace.html is the formatted link 14:57:23 lxsli: cheers :) 14:57:46 OK, I have to run to my next meeting so tnx everyone, talk again next week 14:57:49 #endmeeting