14:00:11 <edleafe> #startmeeting nova_scheduler 14:00:12 <openstack> Meeting started Mon Sep 25 14:00:11 2017 UTC and is due to finish in 60 minutes. The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:15 <openstack> The meeting name has been set to 'nova_scheduler' 14:00:22 <edleafe> Good UGT morning! Who's here? 14:01:05 <cdent> o/ 14:01:09 <takashin> o/ 14:01:50 <jaypipes> o/ 14:02:30 <mriedem> o/ 14:02:31 <ralonsoh> hi 14:03:02 <bauzas> \o 14:03:18 * edleafe watches people slowly trickle in... 14:03:37 <edleafe> #topic Specs and Reviews 14:03:50 <edleafe> Let's start with the specs 14:03:57 <edleafe> #link WIP - CPU features to be reported as traits https://review.openstack.org/#/c/497733/ 14:04:09 <edleafe> alex_xu has that marked as WIP 14:04:54 <edleafe> #link Return Alternate Hosts https://review.openstack.org/504275/ 14:05:05 <edleafe> This looks like it's pretty close 14:05:15 <edleafe> #link Return Selection objects https://review.openstack.org/498830/ 14:05:29 <edleafe> Still some concerns about naming 14:05:45 <edleafe> The existing code refers to host, nodename, and limits 14:06:19 * bauzas gently reminds he has to run off for 20 mins in about 15 mins 14:06:28 <edleafe> Should 'host' be changed to 'compute_node'? 14:06:50 <bauzas> the Destination object mentions 'host' and 'node' 14:07:12 <bauzas> 'service' could be equivalent to 'host' but not 'compute node' 14:07:20 <edleafe> dansmith had a concern that it might be confused with the service 14:07:46 <bauzas> so, the thing is 14:08:01 <bauzas> (host, node) is an old tuple inherited from our dark past 14:08:06 <jaypipes> edleafe: if we're referring to the service endpoint, use host, if we're referring to the thing that provides compute resources call it compute_node. at least, that's MHO 14:08:20 <bauzas> what jaypipes said 14:08:30 <bauzas> but 14:08:50 <bauzas> keep in mind we can have multiple nodes per service 14:08:52 <edleafe> jaypipes: sure, understood. If this were greenfield I would agree. My concern is changing the name that is currently being used 14:10:02 <edleafe> I'm happy to call it compute_node, but I want to make sure that we agree on the name change 14:10:21 <jaypipes> edleafe: well, agree, it's tricky. especially since, frankly, the name right now is actually referring to *both* the service endpoint and the compute resource provider (because historically they have been tightly coupled) 14:10:46 * alex_xu waves late 14:11:06 <edleafe> jaypipes: I think the problem came when I added the compute_node's uuid, which was requested 14:11:23 <edleafe> calling it 'host_uuid' was the source of the confusion 14:12:10 <jaypipes> edleafe: will add thoughts on the spec. 14:12:12 <edleafe> So maybe: 'compute_node_uuid', 'host', 'node_name' ? 14:12:17 <jaypipes> edleafe: sorry, hadn't got to that one yet :( 14:12:26 <edleafe> no problem 14:12:53 <edleafe> next up 14:12:56 <edleafe> #link POST /allocations https://review.openstack.org/#/c/499259/ 14:13:04 <bauzas> edleafe: not sure I understand the problem, but I'll voice in the review 14:13:04 <edleafe> cdent: anything to add about that? 14:13:25 <cdent> just that the current blocker is deciding on which representation (listish or dictish) 14:13:29 <edleafe> bauzas: it's just naming. Naming is hard. 14:13:39 <cdent> (or both) 14:14:00 <bauzas> in my mind, host == service and is *never* equal to node or resource provider 14:14:47 <edleafe> #link Placement Agent https://review.openstack.org/#/c/504803 14:15:14 <edleafe> This proposes to have a separate entity report resources instead of nova compute 14:15:29 <edleafe> I haven't read this one yet 14:16:10 <edleafe> #link Minimal cache headers in Placement https://review.openstack.org/#/c/496853/ 14:16:19 <edleafe> This looks pretty straightforward 14:16:36 <jaypipes> yup 14:16:43 <edleafe> None of us want to be bad HTTP citizens, do we? 14:16:58 <jaypipes> I do! I do! 14:17:08 * cdent gives jaypipes a malformed cookie 14:17:19 <jaypipes> lol 14:17:21 <bauzas> do I need a visa for being a good HTTP citizen ? 14:17:34 <bauzas> or an ESTA is enough 14:18:08 <edleafe> Last spec on the list looks pretty dead 14:18:09 <edleafe> #link Detailed error info for Placement API https://review.openstack.org/#/c/418393/ 14:18:30 <edleafe> cdent: is this still a thing? 14:19:16 <cdent> I can’t really say. I had moved it to queen to see if anyone wanted to take it up 14:19:43 <cdent> I can, if people think it is worthwile, but if people are meh, then I can be meh too 14:20:25 <cdent> so, are people meh or not meh? 14:20:31 <edleafe> I'm kind of meh - it's nice, but is there a current problem that it would solve? 14:20:32 <mriedem> heh, 14:20:33 <mriedem> https://review.openstack.org/#/c/504803/1/specs/queens/approved/placement-agent.rst 14:20:36 <mriedem> so, resource tracker, 14:20:39 <mriedem> but not in nova-compute 14:20:40 <mriedem> -2 14:21:45 <cdent> that almost silence is a resounding meh, can someone with the power to do so abandon https://review.openstack.org/#/c/418393/ to get it off the radar? 14:21:56 <cdent> we can bring it back later if needed 14:22:11 <edleafe> yeah, it seems like noise right now 14:22:15 * cdent nods 14:22:30 <cdent> mriedem: how would you feel ab out “nova-compute, but not in nova”? 14:22:33 <bauzas> what meh are we weighting now ? 14:23:00 <cdent> bauzas: whether to do https://review.openstack.org/#/c/418393/ 14:23:11 <mriedem> cdent: so clint's thing from barcelona? 14:23:11 <cdent> so far the consensus seems to be “worry later, if ever" 14:23:31 <bauzas> cdent: ah, thanks 14:23:46 <cdent> mriedem: sort of yeah, I’m mostly just joshing 14:24:10 <bauzas> cdent: well, MHO is that it could be nice but we're almost already pretty full 14:24:16 <edleafe> Next up are a couple of Traits patches from alex_xu: 14:24:16 <edleafe> #link Add traits to GET /allocation_candidates https://review.openstack.org/479776 14:24:20 <edleafe> #link Add traits to get RPs with shared https://review.openstack.org/478464/ 14:24:26 <cdent> bauzas: agreed, so if you can abandon it that would be great (I can't) 14:25:09 <alex_xu> #link nova-spec add traits to /allocation_candidates https://review.openstack.org/497713 14:25:16 <alex_xu> edleafe: ^ the spec 14:25:51 <alex_xu> jaypipes, thanks for the review 14:26:00 <jaypipes> npo 14:26:16 <bauzas> cdent: ack 14:26:20 * bauzas has to leave 14:26:30 <edleafe> let's all take the time to review these, as traits support is critical 14:26:33 * bauzas will be back in 15-20 mins 14:26:37 <alex_xu> #link nova-spec request traits in nova https://review.openstack.org/468797 14:26:40 * edleafe waves 14:28:11 <edleafe> alex_xu: thanks - I missed those 14:28:21 <alex_xu> edleafe: np 14:29:39 <edleafe> moving on 14:29:41 <edleafe> #link Allow _set_allocations to delete allocations https://review.openstack.org/#/c/501051/ 14:29:59 <edleafe> cdent: that one looks about ready, no? 14:30:35 <cdent> yes, it and its parent are pretty done. it’s the child that still wanders 14:30:38 <mriedem> cdent: i can abandon https://review.openstack.org/#/c/418393/ - it's basically, no owner, low priority right? 14:30:52 <cdent> mriedem: yes 14:31:33 <mriedem> done 14:31:36 <cdent> danke 14:32:00 <edleafe> cdent: while I have your attention 14:32:04 <edleafe> #link WIP - POST /allocations for >1 consumer https://review.openstack.org/#/c/500073/ 14:32:12 <cdent> yes, that’s the wandering child 14:32:22 <cdent> which needs resolution of the asociated spec 14:32:31 <cdent> (the listish, dictish question earlier) 14:32:37 <edleafe> understood 14:33:15 <cdent> conceptually speaking it gets the job done okayish 14:33:50 <edleafe> listish, dictish, okayish 14:34:12 <cdent> ish 14:34:20 <edleafe> Moving onish... 14:34:21 <edleafe> #link Use ksa adapter for placement https://review.openstack.org/#/c/492247/ 14:34:35 <edleafe> this looks pretty straightforward 14:34:59 <edleafe> (if your into keystone stuff) 14:35:07 <edleafe> s/your/you're 14:35:16 <jaypipes> hmm... I thought we already used ksa for placement? 14:35:34 <cdent> jaypipes: this is the new style 14:36:02 <jaypipes> oh, for endpoint resolution... gotcha. 14:36:05 <cdent> adapter instead of session 14:36:18 <jaypipes> k 14:36:32 <edleafe> #link Add Alternate Hosts https://review.openstack.org/#/c/486215/ 14:36:40 <edleafe> this one's pretty close 14:36:45 <jaypipes> edleafe: just wrapped up a review on that one. 14:36:51 <jaypipes> very close. just some suggested renames 14:37:07 <edleafe> still some issues with how exactly to pull from the pool of hosts to get accepatble alternates 14:37:35 <edleafe> jaypipes: thx 14:37:59 <edleafe> Also: 14:38:00 <edleafe> #link Add Selection objects https://review.openstack.org/#/c/499239/ 14:38:11 <jaypipes> edleafe: what issues are you concerned about with pulling from the poolk of hosts? 14:38:17 <edleafe> This is kind of on hold until we can fix the naming issues in the spec 14:38:21 <jaypipes> edleafe: you mean how to choose one or more of them? 14:38:42 <edleafe> jaypipes: it is on the edge case of not many acceptable hosts 14:38:58 <jaypipes> edleafe: sorry, not following you... could you elaborate? 14:39:05 <edleafe> I thought itertools.cycle would help, but that can make an infinite loop 14:39:13 <mriedem> edleafe: do you have functional tests somewhere in the series for https://review.openstack.org/#/c/486215/ ? 14:39:20 <mriedem> unit tests aren't going to cut it for alternate hosts 14:39:34 <edleafe> mriedem: no 14:39:45 <edleafe> mriedem: I guess I'll have to add some 14:40:12 <mriedem> yeah.... 14:40:27 <edleafe> mriedem: ok, just WIP'd it 14:40:46 <mriedem> well, 14:40:56 <mriedem> i guess if you're going to add later in the series, yeah 14:41:08 <mriedem> the functional tests will really need to be after the conductor and compute parts are done 14:41:19 <mriedem> so we can test reschedules happening across services 14:41:47 <edleafe> mriedem: I had planned on creating functional tests when it came to the RPC changes 14:42:37 <jaypipes> mriedem: yeah, I think that particular patch doesn't change the signature of select_destinations()... 14:42:49 <jaypipes> mriedem: we really need func tests on the patch after that and the RPC changes. 14:43:02 <edleafe> jaypipes: exactly. Just the _schedule() method 14:43:40 <mriedem> ok 14:43:56 <mriedem> and, 14:44:05 <mriedem> to be clear, the rpc between conductor and scheduler isn't the interesting part so much 14:44:14 <mriedem> it's the interaction between conductor and the computes 14:44:30 <mriedem> like, wherever allocations are posted/removed during rescheduels 14:44:32 <mriedem> *reschedules 14:44:50 <edleafe> mriedem: yeah, that's happening in a much later patch 14:46:48 <edleafe> Moving on to... 14:46:50 <edleafe> #topic Bugs 14:46:53 <edleafe> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement 14:46:55 <ralonsoh> hi 14:46:59 <ralonsoh> There is an spec 14:47:01 <ralonsoh> missing 14:47:09 <ralonsoh> #link Enable SR-IOV NIC offload feature discovery https://review.openstack.org/#/c/504895/ 14:48:23 <edleafe> ralonsoh: ok, but that's only slightly concerned with the scheduler, right? 14:48:44 <ralonsoh> and placement. So, where do I put this one? 14:50:03 <edleafe> ralonsoh: seems like a mostly nova spec 14:50:22 <edleafe> ralonsoh: do you have questions about it? 14:50:38 <ralonsoh> edleafe: no, just time form you to review it 14:51:02 <edleafe> ralonsoh: ok, thanks! 14:51:36 <cdent> Was dan’s stack of migration uuid and allocation updates listed earlier? 14:51:43 <cdent> #link allocation by migration https://review.openstack.org/#/q/topic:bp/migration-allocations+status:open 14:52:18 <edleafe> cdent: ah, good catch. No, I missed that series 14:52:33 <dansmith> I'm still working on that of course 14:52:40 <dansmith> hence all the -1s 14:53:09 <edleafe> dansmith: ok, just let us know when they are ready for wider review 14:53:25 <dansmith> ack 14:53:53 <edleafe> So... we were on the topic of bugs :) 14:53:59 <edleafe> Only one new one this week 14:54:06 <edleafe> And it's in progress 14:54:22 <edleafe> #link https://bugs.launchpad.net/nova/+bug/1718212 14:54:23 <openstack> Launchpad bug 1718212 in OpenStack Compute (nova) "Compute resource tracker does not report correct information for drivers such as vSphere" [Medium,In progress] - Assigned to Radoslav Gerganov (rgerganov) 14:54:44 <edleafe> Anything else for Bugs? 14:55:19 <mriedem> i've got a fix that needs final +2 14:55:37 <mriedem> https://review.openstack.org/#/c/506458/ 14:55:39 <mriedem> and below 14:55:39 * bauzas is back 14:55:44 <mriedem> those will need to go to pike 14:56:11 <bauzas> mriedem: easy peasy 14:56:29 * edleafe admires bauzas' timing 14:56:39 <edleafe> #topic Open discussion 14:56:51 <edleafe> We have 3 minutes or so - anything to discuss? 14:56:59 <takashin> Hi 14:57:02 <takashin> #link Enable cold migration with target host(1/2) https://review.openstack.org/#/c/408955/ 14:57:24 <takashin> It is ready for review. Would you review it? 14:57:56 <edleafe> takashin: added to my review list 14:58:08 <takashin> edleafe: Thank you. 14:58:23 <edleafe> Anything else? 14:58:51 <cdent> call it 14:59:12 <edleafe> cdent: sure. What should I call it? :-P 14:59:25 <cdent> over under under done 14:59:38 <edleafe> OK, thanks everyone! 14:59:39 <edleafe> #endmeeting