14:00:17 <edleafe> #startmeeting nova_scheduler
14:00:18 <openstack> Meeting started Mon Oct 10 14:00:17 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:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:24 <edleafe> Anyone around?
14:00:25 <mriedem> o/
14:00:29 <alex_xu> o/
14:00:35 <Yingxin> o/
14:00:36 <pkholkin> +
14:01:26 <edleafe> Let's give everyone one more minute
14:01:27 <bauzas> \o
14:01:51 <jaypipes> o/
14:02:07 <edleafe> Let's start
14:02:18 <edleafe> #topic Specs and Reviews
14:02:32 <edleafe> No one added anything to the agenda
14:02:38 <mriedem> i have something
14:02:44 <mriedem> https://review.openstack.org/#/c/362863/ - the series starting there,
14:02:45 <edleafe> (which is at https://wiki.openstack.org/wiki/Meetings/NovaScheduler BTW)
14:02:49 <edleafe> sure
14:02:51 <mriedem> quick nit, we need a new ocata bp for that
14:02:57 <mriedem> since generic-resource-pools was closed in newton
14:03:00 <mriedem> doesn't need a spec
14:03:11 <mriedem> just a generic-resource-pools-ocata blueprint for tracking, something like that
14:03:27 <edleafe> mriedem: sure, sounds good
14:03:37 <bauzas> mriedem: +1
14:03:47 <edleafe> #action edleafe to add an Ocata BP for https://review.openstack.org/#/c/362863/ series
14:04:01 <jaypipes> mriedem: I'll create one.
14:04:06 <edleafe> jaypipes: too late
14:04:08 <jaypipes> oh, ok edleafe can :)
14:04:10 <edleafe> already called it
14:04:16 <edleafe> :-P
14:04:34 <edleafe> Anything else?
14:04:35 <mriedem> just ping me
14:04:38 <mriedem> and i'll approve it
14:04:40 <edleafe> sure
14:04:42 <alex_xu> the traits API spec was update https://review.openstack.org/345138
14:05:00 <jaypipes> alex_xu: yup, currently re-reviewing that one.
14:05:00 <edleafe> #link https://review.openstack.org/345138
14:05:09 <alex_xu> jaypipes: thanks
14:05:40 <edleafe> alex_xu: saw your replies - will review again later
14:05:49 <alex_xu> edleafe: cool, thanks
14:06:02 <Yingxin> and there's a spec for performance improvement for get_all_host_states
14:06:06 <jaypipes> I'd love some review on both nested resource providers and custom resource classes work.
14:06:13 <Yingxin> #link https://review.openstack.org/#/c/345874
14:06:14 <edleafe> Yingxin: link?
14:06:14 <jaypipes> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-resource-providers
14:06:21 <jaypipes> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/custom-resource-classes
14:06:38 <edleafe> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-resource-providers
14:06:42 <edleafe> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/custom-resource-classes
14:06:52 <jaypipes> heh, thanks ed
14:07:15 <edleafe> jaypipes: hey, it helps me remember what I need to review
14:07:29 <edleafe> Any others?
14:07:48 <mriedem> the resource classes spec isn't approved?
14:07:52 <edleafe> And a reminder: it helps to add those to the agenda *before* the meeting so that they can be reviewed ahead of time
14:08:04 <bauzas> mriedem: nope AFAKK
14:08:06 <mriedem> https://review.openstack.org/#/c/312696/
14:08:27 <mriedem> jaypipes: are you and dansmith on the same page about https://review.openstack.org/#/c/312696/ ?
14:08:29 <jaypipes> mriedem: no, I've been working on *code* not spec to prove it out, since lots of folks at the midcycle complained about too much focus on the specs and not enough on code.
14:09:02 <dansmith> yeah, and I've reviewed some of that code
14:09:06 <jaypipes> mriedem: the code is what dansmith has been reviewing. been waiting on more reviews on that before I update the spec.
14:09:19 <edleafe> jaypipes: do you think it should  still be an enum now that custom classes are a thing?
14:09:39 <dansmith> edleafe: it's not an enum anymore
14:09:40 <jaypipes> edleafe: it's no longer an enum... it's a StringField.
14:09:49 <edleafe> ah, ok
14:09:54 <mriedem> jaypipes: dansmith: ok i guess we need to sort out the bp then, since it's not approved
14:10:04 <edleafe> the version I had the field was still BaseEnum
14:10:12 <jaypipes> I need to push another rev that fixes up the test_objects.py and updates the version, but that should be done shortly.
14:10:14 <mriedem> so i guess we're saying, approve the bp, review the code, write the spec afterward as a doc artifact?
14:10:19 <edleafe> caused all sorts of problems changing ALL to STANDARD
14:10:30 <jaypipes> mriedem: that works for me.
14:10:36 <mriedem> dansmith: ^?
14:10:42 <dansmith> mriedem: that sounds fine to me, but I was just getting a little spec tired
14:10:52 <mriedem> ok
14:10:53 <bauzas> mriedem: jaypipes: I'd rather love to see an updated spec saying that is an implementation detail
14:10:56 <jaypipes> mriedem: though it's more "update the spec afterward" instead of "write the spec afterward"
14:11:03 <edleafe> Isn't a spec to keep from writing dead-end code?
14:11:17 <dansmith> cripes
14:11:22 <bauzas> mriedem: jaypipes: so we could +A the spec, and then discuss on the implementation detail afterwards
14:11:31 <bauzas> during the change review
14:11:40 <edleafe> bauzas: that sounds saner to me
14:11:44 <jaypipes> edleafe: I wrote 9 specs -- and the accompanying hell of reviews/revisions -- last cycle. Feedback at the midcycle was I focused too much on specs and not enough on code. trying to change that now.
14:11:47 <mriedem> if there is momentum i don't want to stifle this
14:11:55 <edleafe> jaypipes: agreed
14:11:59 <dansmith> mriedem: +1
14:12:06 <mriedem> i use the spec as a reference to review a thing i haven't been involved in,
14:12:13 <mriedem> but if dansmith is on this right now i'll just approve the bp
14:12:16 <mriedem> and the spec can be updated later
14:12:23 <edleafe> jaypipes: but I think the problem is that the specs had too much detail, and were being reviewed like they were code
14:12:25 <bauzas> we have a process ?
14:12:25 <mriedem> my guess is the spec is overly detailed and it was getting bogged down in that
14:12:51 <bauzas> I mean, if we say that needs a spec, then let's update the spec, remove that detail and accept that
14:13:06 <bauzas> sure, some details are probably nitty
14:13:22 <edleafe> The process is supposed to *help* development, right?
14:13:24 <bauzas> and I don't want to have jaypipes working during all the cycle about the specs
14:13:43 <bauzas> but there is also something we say about having at least the design written in specs
14:14:06 <bauzas> but like I said, discussing about the format of that field seems a detail to mre
14:14:08 <bauzas> me
14:14:13 <dansmith> bauzas: how about you update the spec to remove all the detail while we work on the code? maybe they can be merged in parallel then,
14:14:14 <bauzas> not really a design point
14:14:17 <dansmith> if the impl details are out
14:14:24 <bauzas> dansmith: okay, I can do that
14:14:35 <dansmith> otherwise I'm kinda sick of delaying the code for things that have to be figured out in code just so we can write them as text first
14:14:37 <edleafe> I can chip in too
14:14:51 <mriedem> bp is approved
14:15:42 <edleafe> Let's move on then
14:15:49 <edleafe> Anything else?
14:15:55 <pkholkin> I have one thing to propose
14:16:00 <pkholkin> #link https://review.openstack.org/#/c/381912
14:16:18 <pkholkin> similar one was merged for Juno (but for images only)
14:16:26 <pkholkin> the link in the spec
14:16:43 <edleafe> pkholkin: Do you have any questions, or just want some eyeballs on that?
14:16:52 <jaypipes> the latter I think
14:17:15 <pkholkin> I don't have questions now, just a presentation for now) because there were no reviews except alaski
14:17:30 <edleafe> pkholkin: ok, thanks - just wanted to make sure
14:17:40 <pkholkin> want reviews/opinions
14:17:48 <pkholkin> I want to implement this in Ocata
14:17:59 <pkholkin> PoC is ready, too, the link is in the spec
14:18:31 <pkholkin> I decided to make another review and bp for this
14:18:48 <edleafe> pkholkin: ok, added to my review list
14:19:01 <pkholkin> ok, thanks
14:19:05 <edleafe> #topic Opens
14:19:15 <edleafe> First up : summit topics
14:19:32 <edleafe> We have two slots for scheduler/placement, right mriedem?
14:19:56 * edleafe hasn't checked recently
14:20:06 <mriedem> edleafe: yes
14:20:10 <mriedem> first is quantitative,
14:20:12 <mriedem> 2nd is traits
14:20:23 <edleafe> cool
14:20:26 <mriedem> 3 slots if you count the retrospective
14:20:37 <edleafe> Are we still good with those two topics?
14:20:49 <edleafe> (asking the group)
14:20:50 <mriedem> btw the etherpads are up
14:20:59 <mriedem> so can start filling in the agenda
14:22:03 <edleafe> OK, next up: Cells awareness in scheduler
14:22:07 <edleafe> alaski: around?
14:22:36 <pkholkin> I think no
14:23:09 <edleafe> #link https://review.openstack.org/#/c/381275/
14:23:37 <edleafe> The spec looks good, but there are a lot of "to be figured out later" sections
14:24:00 <edleafe> It would be good to get some more reviews on that
14:24:04 <edleafe> pre-summit
14:24:26 <edleafe> I had one other thing to discuss
14:24:53 <edleafe> Should we have this meeting next week? I don't know if people will be too busy one week before the summit
14:25:02 <edleafe> I'll be available to run it
14:26:14 <edleafe> The silence is deafening!
14:26:20 <bauzas> edleafe: I'd rather ask what could be the objective
14:26:22 <mriedem> might as well leave it here
14:26:31 <mriedem> if there is nothing to talk about, then end early
14:26:37 <mriedem> you might want to double check on summit prep
14:26:40 <edleafe> OK, I'll keep it just in case last-minute questions come up
14:26:42 <bauzas> maybe
14:27:14 <edleafe> So are we done?
14:27:43 <jaypipes> yes from me :)
14:27:51 <edleafe> #endmeeting