14:00:46 <n0ano> #startmeeting nova-scheduler
14:00:47 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:51 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:51 <lxsli> o/
14:00:58 <n0ano> anyone here to talk about the scheduler?
14:01:59 <edleafe> actually, I'm here after all
14:02:07 * johnthetubaguy kinda lurking
14:02:30 <n0ano> edleafe, cool - so `house leveling', what, it's on a 45 degree angle suddenly :-)
14:03:06 <edleafe> n0ano: nah, some of the support piers have settled a few inches. You get seasick walking from room to room. :)
14:03:30 <edleafe> But they were going to be there all day, and didn't seem like I could help, so I left
14:03:50 <n0ano> 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 <lxsli> They said you couldn't build a castle in a swamp
14:05:21 * alex_xu actually around here also
14:05:27 <edleafe> n0ano: well, we just closed the purchase on Friday, and want to get this stuff done before we start anything else
14:05:38 <lxsli> Congratulations :)
14:05:52 <jaypipes> morning fellers.
14:06:16 <lxsli> datetime.informal() to you too
14:06:27 <n0ano> OK, looks like we have quorum (except for the europeans still on vacation) so...
14:06:36 <n0ano> #topic liberty patches
14:07:04 <n0ano> the biggest items are jaypipes  & bauzas  series, hows your's going jaypipes
14:07:50 <jaypipes> 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 <jaypipes> n0ano: reviews welcome.
14:08:14 <jaypipes> n0ano: I plan to rebase resource objects patch series on top of that.
14:08:18 <n0ano> I heard rumblings about PCI issues, sorry you hit that
14:08:31 <n0ano> 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 <jaypipes> n0ano: no, just a lot of object version changes.
14:10:26 <n0ano> OK, sounds like it's under control, bottom line is do our reviews
14:10:31 <jaypipes> yes.
14:10:53 <n0ano> anything else on patches?
14:11:10 <jaypipes> not from me
14:11:36 <n0ano> moving on then...
14:12:05 <n0ano> #topic CPU feature representation
14:12:31 <jaypipes> n0ano: just responded to Michal's thread.
14:12:34 <n0ano> I started the thread, got a little response but nothing major yet
14:12:59 <n0ano> jaypipes, I just saw that, need to take time to think about it and the message from Tony about power
14:13:34 <jaypipes> n0ano: well, the message from tony was really just mentioning the difference between intel and power "discovery" of cpu caps.
14:14:02 <jaypipes> 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 <n0ano> 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 <n0ano> a common representation but the specific features would indeed be different between architectures
14:14:35 <jaypipes> n0ano: with the resources stuff being all the quantitative things and the capabilities stuff being all the qualitative things
14:15:09 <jaypipes> 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 <edleafe> jaypipes: +1 million
14:15:27 <n0ano> jaypipes, my favorite, how does NUMA topology fit in, since it has quantitateive issues also but is rather static
14:16:02 <jaypipes> no, it's not static at all. it's a quantitative measure.
14:16:41 <lxsli> It's possible to hotplug CPUs in some archs I think
14:16:42 <n0ano> jaypipes, `rather` static, it doesn't change without hot plugging something
14:17:04 <jaypipes> let's not overthink this...
14:17:18 <jaypipes> NUMA topology is a request for a specific set of NUMA resources, nothing more.
14:18:07 <jaypipes> 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 <jaypipes> but at the end of the day, it's just a quantity requested of some resource.
14:18:55 <n0ano> in the same way cpu feature request is a request for a specific set of cpu capabilities
14:19:18 <jaypipes> no, it's the opposite of that...
14:19:36 <jaypipes> n0ano: there is no quantity/amount in the request fo capabilities/faetures.
14:19:46 <jaypipes> n0ano: which is what makes it different from resources.
14:20:05 <jaypipes> you don't ask for "5 sse features"
14:20:16 <n0ano> hmm, maybe I'm thinking wrong, resources are consumable but capabilities are just there
14:20:23 <jaypipes> right.
14:21:33 <alex_xu> so we need common api for capabilities stuff?
14:23:24 <n0ano> sorry, had to strap my wife into here torture device, I'm back now
14:23:30 <jaypipes> 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 <edleafe> jaypipes: can some form of aggregates be used for that?
14:24:09 <n0ano> jaypipes, that's what we've been doing with flavor extra_specs for now, a separate API would be good
14:25:04 <n0ano> edleafe, I'd have to think about that, I don't know off the top of my head if aggregates fits
14:25:26 <jaypipes> 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 <edleafe> jaypipes: ah, ok. I didn't understand that it was the user-facing stuff that's the issue
14:26:45 <jaypipes> edleafe: yeah.
14:28:56 <edleafe> 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 <n0ano> 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 <edleafe> n0ano: there is logic to say "they asked for fast crypto, and this host has mmx, so it's ok"?
14:30:41 <edleafe> PaulMurray: welcome back!
14:31:12 <n0ano> edleafe, no, `they asked for mmx and this host has mmx, so it's OK'
14:32:10 <edleafe> 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 <edleafe> jaypipes: or am I still understanding it wrong?
14:33:24 <jaypipes> 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 <n0ano> I think defining a common feature name that works across all architectures is not going to be possible
14:34:46 <n0ano> 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 <edleafe> n0ano: but what about "cloud" users? They shouldn't have to know jack about what the underlying arch is
14:35:53 <n0ano> the user is already supplying a different image for Intel vs. Power so they already have to know about different architectrures
14:36:14 <n0ano> edleafe, note my last comment
14:38:39 * jaypipes reading EC2 isntance types documentation
14:38:55 <n0ano> which would argue that the capability requirements should be stored in the glance meta-data, not in the flavor
14:39:16 <alex_xu> 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 <jaypipes> n0ano: there are a number of problems with that (see my response to michal)
14:39:56 <lxsli> 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 <n0ano> 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 <jaypipes> 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 <lxsli> This has the advantage of not boiling the ocean
14:40:33 <lxsli> *not trying to
14:41:03 <alex_xu> jaypipes: so image creator can't ensure his image can be used for any opensack cloud...is that ok?
14:41:30 <n0ano> 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 <jaypipes> 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 <n0ano> jaypipes, +1
14:42:20 <jaypipes> up until now, we've been able to keep vendor-specific things from leaking out of the API.
14:42:25 <jaypipes> I'd like to continue to do that.
14:42:36 <lxsli> 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 <jaypipes> so that we don't become "the Intel Nova API"
14:42:50 <jaypipes> lxsli: suggestions welcome.
14:42:51 <alex_xu> jaypipes: yes, we didn't want that.
14:43:13 <n0ano> jaypipes, no arguement, I think of host capabilities as arbitrary strings, different architectures provide different strings
14:43:32 <jaypipes> n0ano: sure, the issue is what gets leaked out fo the API to the end user.
14:44:02 <lxsli> 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 <jaypipes> 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 <n0ano> lxsli, as long as they can also explicitly depend upon a Power feature also
14:45:02 <lxsli> +1
14:46:17 <n0ano> so, if I can summarize, we want...
14:46:21 <jaypipes> 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 <n0ano> 1) arch specific features presented in a generic way
14:46:55 <n0ano> 2) explicit features for now
14:47:08 <n0ano> 3) aggregated features later
14:47:23 <n0ano> 4) not looking for common features across archs
14:47:24 <jaypipes> n0ano: what do you mean by "explicit features for now"?
14:48:19 <n0ano> 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 <jaypipes> n0ano: that can already be done on the image metadata level, though.
14:49:02 <jaypipes> n0ano: which I'm saying is fine...
14:49:13 <n0ano> e.g. asking for AES would be an explicit features, asking for fast crypto would be an aggregate
14:49:23 <jaypipes> 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 <n0ano> 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 <jaypipes> n0ano: /me thinks
14:53:09 <n0ano> jaypipes, indeed, hence the ML is a good place for this
14:53:13 <n0ano> running out of time so
14:53:15 <n0ano> #topic opens
14:53:21 <n0ano> anything new for today?
14:53:31 <lxsli> I could use a review of: https://review.openstack.org/211215
14:53:58 <jaypipes> lxsli: lol.
14:54:02 <lxsli> It's not really scheduler specific but I need to understand this to do my patch
14:54:06 <lxsli> oh shoot
14:54:09 <lxsli> wrong link >.<
14:54:17 <lxsli> I meant https://review.openstack.org/#/c/210467
14:54:22 <lxsli> but yeah that too >.>
14:54:29 <n0ano> lxsli, sorry only one chance, we'll only review the first link :-)
14:54:45 <lxsli> the first one is just me procrastinating
14:55:12 <jaypipes> lxsli: will review that shortly.
14:55:18 <lxsli> thanks
14:56:05 <jaypipes> lxsli: are you a vim user?
14:56:10 <lxsli> Oh yes
14:56:30 <jaypipes> lxsli: any chance you can ggVGgq that? :)
14:57:03 <lxsli> jaypipes: sure, I looked at some of the others and they used long lines, but I prefer short lines too :)
14:57:20 <lxsli> 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 <jaypipes> lxsli: cheers :)
14:57:46 <n0ano> OK, I have to run to my next meeting so tnx everyone, talk again next week
14:57:49 <n0ano> #endmeeting