14:00:16 <edleafe> #startmeeting nova_scheduler
14:00:17 <openstack> Meeting started Mon Aug 15 14:00:16 2016 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:21 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:31 <edleafe> Anyone here today?
14:00:35 <alex_xu> o/
14:00:40 <Yingxin> here
14:01:05 * johnthetubaguy lurks
14:01:06 <woodster_> o/
14:01:50 <edleafe> Let's wait another minute or so
14:03:02 * edleafe notes that it's the height of summer vacation season
14:03:07 * notmyname lurks
14:04:16 <edleafe> Hmmm... was waiting for jaypipes and cdent to discuss their specs/reviews, but neither is here
14:04:35 <edleafe> So let's move straight to Opens
14:04:40 <edleafe> #topic Opens
14:04:49 <edleafe> Nothing on the agenda
14:05:00 <edleafe> Is there anything anyone wants to bring up?
14:05:45 <Yingxin> edleafe: I removed the "preference" part in the spec "request standardized caps"...
14:06:04 <jaypipes> edleafe: hey, sorry, was fixing up a patch... here now.
14:06:06 <edleafe> Yingxin: yes, thanks
14:06:17 <alex_xu> edleafe: Yingxin i'm also thinking we need API to tell user which preference caps they got
14:06:33 <edleafe> Yingxin: with caps tied to flavors, that would have been impossible to implement
14:06:43 <Yingxin> alex_xu: just see your comments
14:06:55 <Yingxin> edleafe: got you
14:06:58 <edleafe> Yingxin: once we can break the reliance on flavors, we can consider preferences
14:07:23 <johnthetubaguy> so we do already have most of these options somewhere, its just an ad hoc mess right now
14:07:26 <edleafe> welcome, jaypipes!
14:07:40 <jaypipes> johnthetubaguy: right.
14:07:54 * alex_xu is thinking whether he miss something...why preference part removed....
14:08:15 <jaypipes> alex_xu: I'm also wondering the same thing.
14:08:39 <edleafe> because of the 1:1 need for flavors
14:08:49 <johnthetubaguy> I get building out the basics, then adding in the extra bits later, but we need preferences, long term
14:08:58 <johnthetubaguy> edleafe: sorry, what do you mean by 1:1?
14:09:06 <edleafe> Each combination of preferences would require a distinct flavor
14:09:13 <jaypipes> edleafe: I don't see how continuing to use the flavor as some thing that Nova uses to describe "templates for instances" means that preferences cannot be a part of the placement REST API.
14:09:55 <jaypipes> edleafe: right, agreed, but that's a different problem than the problem we're trying to solve with capabilities, which is a standardized way of representing the qualitative side of the launch request.
14:10:18 <edleafe> jaypipes: I'm all for preferences in a request
14:10:46 <edleafe> I just don't believe that those can be expressed adequately with flavors
14:11:54 <jaypipes> edleafe: I think the flavor concept introduces a rigidity that isn't ideal, but again I think that's a separate problem we need to solve. That problem is something to solve in Nova. The problem we're trying to solve with the capabilities stuff is a problem that needs to be solved in the placement API.
14:11:59 <jaypipes> edleafe: agreed?
14:12:10 <edleafe> sure
14:12:18 <edleafe> but that's not what we were discussing
14:12:32 <edleafe> It was the Nova API
14:12:36 <edleafe> not placement
14:12:45 <johnthetubaguy> jaypipes: +1 treat flavor as a request template, ish
14:12:50 <alex_xu> may I ask why user want to preferences caps, what kind of case user don't care whether he can get specific caps....
14:13:36 <jaypipes> edleafe: I'm misunderstanding something then..
14:14:03 <edleafe> alex_xu: when a capability would be nice to have, but not essential. I'd prefer SSD, but I'd rather have spinning disk than have the request fail]
14:14:14 <johnthetubaguy> do you have the link to the spec, feels like I am thinking about a different spec
14:14:38 <Yingxin> johnthetubaguy: https://review.openstack.org/#/c/351063/
14:14:46 <johnthetubaguy> cool, thanks
14:14:51 <edleafe> #link https://review.openstack.org/#/c/351063/
14:14:56 <alex_xu> edleafe: if user can get sdd or spinning disk with same price, why not just get sdd for me
14:15:24 <edleafe> alex_xu: even if they're different prices
14:15:29 <alex_xu> edleafe: if user get sdd or spinning with different price, if user really require sdd, why just save the money...
14:15:43 <edleafe> I might be willing to pay for the nice stuff, but I don't want to fail if I can't get it
14:16:04 <alex_xu> s/if user really require sdd/if user really didn't require sdd/
14:16:11 <alex_xu> s/sdd/ssd/....
14:16:15 <edleafe> anyway, that's a different discussion.
14:16:30 <edleafe> require is one thing; prefer is another
14:16:44 <johnthetubaguy> Yingxin: it feels like some nice "real" use cases for several combinations will really help us here
14:17:07 <edleafe> Anyway, the spec deals with the Nova API, not the placement API
14:17:27 <johnthetubaguy> I assumed, long term, you would have per boot request, in the flavor and in the image requests and caps
14:17:49 <johnthetubaguy> so an image has some requirement, also an image is known to run best when it has X
14:18:02 <johnthetubaguy> your app might be the same, i.e. per boot request
14:18:12 <edleafe> johnthetubaguy: long term I'd like to see flavors for the quantitative part of the request only
14:18:15 <johnthetubaguy> some set of hardware might be the same, i.e. a flavor
14:18:35 <johnthetubaguy> edleafe: -1 that, that should be an option, but others want more than that
14:18:45 <johnthetubaguy> but I don't think we should fix this all at once
14:19:00 <edleafe> johnthetubaguy: we're not (hence "long-term") :)
14:19:18 <johnthetubaguy> yep, I am just thinking how we would roll this out slowly
14:19:29 <edleafe> We want to add capability *requirements* to flavors
14:19:31 <johnthetubaguy> I guess thats why we look at flavor first? so we can deprecate the use of extra specs
14:19:49 <edleafe> and then have a way for nova to express that to the placement API
14:20:05 <alex_xu> +1 deprecate the use of extra specs :)
14:20:45 <edleafe> Yeah, even the name says "this is an ugly hack"
14:21:06 <johnthetubaguy> yeah, I don't want an API thats an ugly hack, if I am honest
14:21:15 <johnthetubaguy> now adding an incomplete bit of the full story, is cool
14:21:35 <Yingxin> edleafe: I meant to build up qualitative part of request of placement service in the spec...
14:21:44 <Yingxin> edleafe: there is a section
14:21:54 <jaypipes> apologies all, pooter died :(
14:22:13 <edleafe> Yingxin: The REST TODO?
14:22:29 <Yingxin> edleafe: "Build up qualitative part of request in the request_spec object"
14:23:13 <edleafe> Yingxin: yes, that's the part I am strongly in favor of
14:24:30 <edleafe> Let's grab jaypipes before his computer dies again :)
14:24:40 <edleafe> #topic Specs and Reviews
14:25:00 <edleafe> So Jay, want to discuss either the RT cleanup or os-caps?
14:25:14 * alex_xu search why pooter means computer...
14:25:52 <jaypipes> edleafe: RT cleanup is almost done. couple remaining unit test patches to merge. dansmith already +2'd. once those land, I'll push the patches for the delete of test_resource_tracke.rpy and renaming test_tracker -> test_resource_tracker.
14:25:59 <edleafe> alex_xu: in English, the 'u' can have two sounds: 'oo' and 'yoo'
14:26:09 <jaypipes> edleafe: I'm responding via email to alaski on the os-caps thing about naming.
14:26:28 <edleafe> Good, I saw the DNS comment :)
14:26:32 <alex_xu> edleafe: ah, got it
14:26:34 <jaypipes> alex_xu: lol, sorry about my slang "pooter" term...
14:27:04 <alex_xu> jaypipes: np, happy to learn one more word
14:27:16 <jaypipes> alex_xu: well, it's not really a word :)
14:27:23 <jaypipes> alex_xu: it's just me being silly.
14:27:43 <alex_xu> ok...
14:27:50 <edleafe> alex_xu: 'pooter' is a word, but it means someone who is farting
14:28:18 <alex_xu> edleafe: really?
14:28:39 <edleafe> Yes, but I think we're getting off-topic just a bit
14:28:49 <alex_xu> yea
14:29:13 <edleafe> jaypipes: since cdent isn't around, are there any blocks regarding the placement API development work?
14:29:15 <jaypipes> lol
14:29:31 <jaypipes> edleafe: no, just reviews on his stuff to do. he'll be back tomorrow.
14:29:42 <edleafe> ok, great
14:29:55 <edleafe> Any other specs or reviews to discuss?
14:30:38 <johnthetubaguy> does the usual etherpad carry the best hit list of stuff to go and review still?
14:31:02 <edleafe> johnthetubaguy: dunno, haven't checked it in a while
14:31:18 * edleafe relies on lots of browser tabs
14:32:07 <johnthetubaguy> finding it hard to keep track of all the different threads, etherpad updates are good as we get close to the wire
14:32:42 <edleafe> johnthetubaguy: +1
14:33:05 <edleafe> johnthetubaguy: I'll go through the scheduler stuff today
14:33:09 <edleafe> updating as needed
14:33:16 <johnthetubaguy> that would be awesome, thank you!
14:33:30 <edleafe> #action edleafe to ensure priority etherpad is up-to-date
14:34:26 <edleafe> So... anything else before we adjourn?
14:35:11 <jaypipes> edleafe, alex_xu, Yingxin, alaski: so, I've proposed using the term "capabilities" to describe alaski's actions/policies things and the term "traits" to describe the adjectives/attributes of a provider of some resource.
14:35:44 <jaypipes> I think those two terms align best with the meaning for these different things that we are trying to convey.
14:36:16 <edleafe> jaypipes: so os-traits?
14:36:22 <jaypipes> edleafe: yeah
14:37:08 * edleafe senses a bikeshedder's paradise coming up...
14:37:14 <jaypipes> hehe
14:37:19 <jaypipes> it's what we do, ed.
14:37:35 <Yingxin> short is good to me, at least
14:37:40 <alex_xu> anyway I trusted you guys :)
14:38:04 <alex_xu> Yingxin: yea, sometime I failed to read 'capabilities',
14:39:25 <edleafe> So let's fight over naming on the ML
14:39:28 <edleafe> Anything else?
14:40:13 <edleafe> OK, thanks everyone!
14:40:15 <edleafe> #endmeeting