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