14:00:01 <efried> #startmeeting nova_scheduler
14:00:02 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:05 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:14 <jaypipes> o/
14:00:15 <takashin> o/
14:00:17 <ttsiouts> o/
14:00:27 <cdent> o/
14:00:58 <efried> Let's do this.
14:01:13 <efried> #topic Reviews: Nested Resource Providers
14:01:32 <efried> ComputeDriver.update_provider_tree() series starting with: https://review.openstack.org/#/c/532563/ (efried)
14:01:39 <jaypipes> efried: I will get back to those reviews today
14:02:12 <efried> jaypipes Thanks.  Actually the most urgent thing from you is what's queued up for open discussion.
14:02:31 <efried> For the above, I need to tweak the current bottom of the series per cdent comments.
14:03:01 <efried> 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 <efried> Nested affordance in GET /allocation_candidates series starting with: https://review.openstack.org/#/c/531443/1 (jaypipes)
14:03:30 <efried> Poor jaypipes has been laid up for the past week.
14:04:05 <efried> The above needs to be rebased with some refactoring in light of test helpers which (finally!) merged.
14:04:06 <jaypipes> yeah, sorry about that :(
14:04:12 <jaypipes> will do today.
14:04:38 <jaypipes> I noticed from the small amount of email checking I did last week that the gate looked fairly horrible...
14:04:42 <efried> 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 <efried> Anything on NRP?
14:05:30 <efried> #topic Reviews: Alternate Hosts
14:06:21 <efried> 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 <efried> Anything on alt hosts?
14:07:25 <efried> #topic Placement bugs
14:07:27 <efried> https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:07:47 <efried> We should plan on doing a leetle scrubbyscrub shortly after ff
14:07:48 <cdent> I made a new bug about unnecessary imports
14:07:53 <cdent> #link imports: https://bugs.launchpad.net/nova/+bug/1743120
14:07:55 <openstack> 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 <cdent> and I'm working on some changes to fix it
14:08:16 <efried> neat
14:08:45 <efried> Anything else on bugs, placement or otherwise-scheduler?
14:09:07 <jaypipes> nothing from me, post flu-ness.
14:09:20 <efried> #topic Open discussion
14:09:26 <efried> One item on the agenda
14:09:33 <efried> ProviderTree accessors (see https://review.openstack.org/#/c/533244/)
14:09:47 <efried> Mainly needing jaypipes to weigh in here before I get too much further.
14:10:00 <efried> Assuming you're not yet caught up on emails and whatnot, here's the executive summary:
14:10:39 <efried> 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 <efried> The above patch is one possible way of doing it, that still protects the privacy/integrity of _Provider.
14:11:53 <efried> 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 <efried> My plan is to start implementing that method that diffs and flushes ProviderTree changes today.
14:12:51 <efried> 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 <jaypipes> 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 <jaypipes> 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 <efried> jaypipes Even that method would be ProviderTree needing to get at the individual fields of _Provider.
14:15:35 <jaypipes> efried: of the other ProviderTree's _Provider(s), yes.
14:15:39 <efried> I.e. what we're talking about is at a lower level than ProviderTree.delta (or whatever)
14:16:17 <jaypipes> efried: understood.
14:16:30 <efried> So the proposed patch is one way of doing that: it basically provides a copyout of a podo version of _Provider
14:16:56 <jaypipes> 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 <efried> jaypipes Just so.
14:17:16 <jaypipes> efried: yeah, I get it.
14:17:58 <cdent> (there ya go efried, that's some of the additional context for your commit message...)
14:18:05 <efried> 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 <efried> cdent ack
14:18:27 <jaypipes> 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 <jaypipes> efried: definitely like the snapshot approach over a bean-like getter approach.
14:19:34 <jaypipes> 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 <efried> 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 <jaypipes> what does edleafe think? or should I read the reviews? :)
14:20:38 <efried> jaypipes Well, edleafe was involved in the brainstorm on Friday.  Not much beyond that in the review.
14:20:51 <jaypipes> efried: well, I see his reviews on PS1
14:21:06 <jaypipes> efried: in short, I think the snapshot approach is perfectly fine.
14:21:15 <jaypipes> efried: it does one job and accomplishes that job.
14:21:21 <efried> jaypipes Great, I will proceed.
14:21:22 <jaypipes> efried: let's move forward, I think
14:21:37 <efried> That's everything on the agenda.  Anyone have anything else to discuss?
14:22:03 <jaypipes> cdent: what were your thoughts on the snapshot/clone thing?
14:23:03 <cdent> 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 <efried> 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 <efried> But IMO having the code take that for granted and violate the privacy markings of _Provider is not a good approach.
14:25:03 <jaypipes> efried: never say never..
14:25:16 <efried> Exactly.  And those protections *are* necessary for the ProviderTree that report client uses as a cache.
14:25:22 <jaypipes> ya
14:26:06 <efried> So we need *something* there.  And this is about as lightweight/unintrusive as I can think of.
14:26:33 <cdent> if we need something, then yeah, seems okay to me, it is pretty clean and comprehensible
14:26:53 <efried> Good deal.  Thanks y'all.
14:27:00 <efried> Anything else?
14:27:06 <jaypipes> 42
14:27:18 <cdent> WRONG
14:27:22 <jaypipes> heh
14:27:37 <efried> Okay, thanks everyone.
14:27:40 <efried> #endmeeting