14:00:01 #startmeeting nova_scheduler 14:00:02 Meeting started Mon Jan 15 14:00:01 2018 UTC and is due to finish in 60 minutes. The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 The meeting name has been set to 'nova_scheduler' 14:00:14 o/ 14:00:15 o/ 14:00:17 o/ 14:00:27 o/ 14:00:58 Let's do this. 14:01:13 #topic Reviews: Nested Resource Providers 14:01:32 ComputeDriver.update_provider_tree() series starting with: https://review.openstack.org/#/c/532563/ (efried) 14:01:39 efried: I will get back to those reviews today 14:02:12 jaypipes Thanks. Actually the most urgent thing from you is what's queued up for open discussion. 14:02:31 For the above, I need to tweak the current bottom of the series per cdent comments. 14:03:01 It should be noted that I recently reordered that guy to get set_traits_for_provider done earlier, because mgoddard needs that for the ironic-traits bp. 14:03:18 Nested affordance in GET /allocation_candidates series starting with: https://review.openstack.org/#/c/531443/1 (jaypipes) 14:03:30 Poor jaypipes has been laid up for the past week. 14:04:05 The above needs to be rebased with some refactoring in light of test helpers which (finally!) merged. 14:04:06 yeah, sorry about that :( 14:04:12 will do today. 14:04:38 I noticed from the small amount of email checking I did last week that the gate looked fairly horrible... 14:04:42 Granular resource requests (efried): https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/granular-resource-requests (waiting for ^^) 14:05:04 Anything on NRP? 14:05:30 #topic Reviews: Alternate Hosts 14:06:21 We're down to Just One More Patch mode here. https://review.openstack.org/526436 looks like it needs a pep8 fix. 14:06:58 Anything on alt hosts? 14:07:25 #topic Placement bugs 14:07:27 https://bugs.launchpad.net/nova/+bugs?field.tag=placement 14:07:47 We should plan on doing a leetle scrubbyscrub shortly after ff 14:07:48 I made a new bug about unnecessary imports 14:07:53 #link imports: https://bugs.launchpad.net/nova/+bug/1743120 14:07:55 Launchpad bug 1743120 in OpenStack Compute (nova) "placement inadvertently imports many python modules it does not need" [Low,Triaged] - Assigned to Chris Dent (cdent) 14:08:05 and I'm working on some changes to fix it 14:08:16 neat 14:08:45 Anything else on bugs, placement or otherwise-scheduler? 14:09:07 nothing from me, post flu-ness. 14:09:20 #topic Open discussion 14:09:26 One item on the agenda 14:09:33 ProviderTree accessors (see https://review.openstack.org/#/c/533244/) 14:09:47 Mainly needing jaypipes to weigh in here before I get too much further. 14:10:00 Assuming you're not yet caught up on emails and whatnot, here's the executive summary: 14:10:39 In order to have a way to compare the ProviderTree I get back from ComputeDriver.update_provider_tree with the one cached in report client, I need to be able to get to the actual fields in the _Provider 14:11:13 The above patch is one possible way of doing it, that still protects the privacy/integrity of _Provider. 14:11:53 Another way would be individual getters at the ProviderTree level for each attribute of _Provider. So like get_traits_for(name_or_uuid) etc. 14:12:32 My plan is to start implementing that method that diffs and flushes ProviderTree changes today. 14:12:51 So whereas I don't need +2s or anything, I'd at least like general buy-in on the approach. 14:13:07 * efried hands the mic to jaypipes 14:13:54 efried: I was thinking more along the lines of a ProviderTree.delta(ProviderTree) method which would return a list of dicts of changed provider information 14:14:43 efried: and that ProviderTree.delta() method would only be used/called by the reportclient once the update_provider_tree() virt driver method returns True (indicating *something* was modified in the tree) 14:14:54 jaypipes Even that method would be ProviderTree needing to get at the individual fields of _Provider. 14:15:35 efried: of the other ProviderTree's _Provider(s), yes. 14:15:39 I.e. what we're talking about is at a lower level than ProviderTree.delta (or whatever) 14:16:17 efried: understood. 14:16:30 So the proposed patch is one way of doing that: it basically provides a copyout of a podo version of _Provider 14:16:56 efried: so ProviderTree.delta() would need to call this ProviderTree.snapshot() method and operate against those snapshots of the other tree's _Provider objects 14:17:09 jaypipes Just so. 14:17:16 efried: yeah, I get it. 14:17:58 (there ya go efried, that's some of the additional context for your commit message...) 14:18:05 So the question is: you cool with the snapshot idea or do we go for a more bean-like set of getters? 14:18:08 cdent ack 14:18:27 efried: you could also do a ProviderTree.clone() method that would return a new identical ProviderTree that the delta() method would then fully own (and not have to worry about potentially other threads writing to.) 14:19:01 efried: definitely like the snapshot approach over a bean-like getter approach. 14:19:34 efried: I also think a clone() approach would be more Pythonic, though -- in the mould of copy.deepcopy()-like semantics against dicts 14:19:39 jaypipes Yes; I wasn't as much a fan of simple clone (deepcopy) because it still breaks the (albeit nominal) privacy boundary. 14:19:52 what does edleafe think? or should I read the reviews? :) 14:20:38 jaypipes Well, edleafe was involved in the brainstorm on Friday. Not much beyond that in the review. 14:20:51 efried: well, I see his reviews on PS1 14:21:06 efried: in short, I think the snapshot approach is perfectly fine. 14:21:15 efried: it does one job and accomplishes that job. 14:21:21 jaypipes Great, I will proceed. 14:21:22 efried: let's move forward, I think 14:21:37 That's everything on the agenda. Anyone have anything else to discuss? 14:22:03 cdent: what were your thoughts on the snapshot/clone thing? 14:23:03 I'm okay with now that I've read the additional context here. It wasn't clear what the calling context was going to be, but now that it is more clear, I think a read only snapshot is a reasonable way to go, if that level of protect is important (I'm still not _entirely_ clear why it is) 14:24:15 Realistically, the ProviderTree given to and returned by ComputeDriver.update_provider_tree doesn't need all this careful locking at all, ever. 14:24:48 But IMO having the code take that for granted and violate the privacy markings of _Provider is not a good approach. 14:25:03 efried: never say never.. 14:25:16 Exactly. And those protections *are* necessary for the ProviderTree that report client uses as a cache. 14:25:22 ya 14:26:06 So we need *something* there. And this is about as lightweight/unintrusive as I can think of. 14:26:33 if we need something, then yeah, seems okay to me, it is pretty clean and comprehensible 14:26:53 Good deal. Thanks y'all. 14:27:00 Anything else? 14:27:06 42 14:27:18 WRONG 14:27:22 heh 14:27:37 Okay, thanks everyone. 14:27:40 #endmeeting