14:00:16 <edleafe> #startmeeting nova_scheuler
14:00:16 <openstack> Meeting started Mon Apr 30 14:00:16 2018 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:20 <openstack> The meeting name has been set to 'nova_scheuler'
14:00:23 <efried> ō/
14:00:24 <tssurya> o/
14:00:27 <edleafe> Good UGT morning! Who's here?
14:00:31 <melwitt> o/
14:00:42 <Sundar> o/
14:01:35 <mriedem> o/
14:02:27 * efried draws pentagram, summons jaypipes
14:03:07 <edleafe> #topic Specs & Reviews
14:03:12 <edleafe> #link Latest Placement Update http://lists.openstack.org/pipermail/openstack-dev/2018-April/129941.html
14:03:43 <edleafe> posting a single link is so much easier than prepping a full list :)
14:04:38 * jaypipes appears from the mist
14:04:42 <Sundar> Since https://review.openstack.org/#/c/554529/ is merged, can we say that nested resource providers support is now officially in?
14:04:49 <efried> Sundar: No
14:05:14 <efried> Sundar: That's some of the internal framework, but we still don't have API support for nrp in alloc cands.
14:05:20 <edleafe> Well, it *is* in. It just can't be used
14:05:34 <efried> To my knowledge, that patch (which will come with a microversion) is not yet proposed.
14:06:13 <efried> On that subject, I would like to request that mriedem and melwitt ack https://review.openstack.org/#/c/559466/ as we're one patch away from needing that to proceed with ^
14:06:33 <mriedem> i was waiting for updates, will (re)review this morning
14:06:40 <efried> thx
14:06:44 <melwitt> yep, will do
14:07:01 <edleafe> I also wanted to ask for some reviews for the consumer generation stuff
14:07:16 <edleafe> There are two ways posted for handling it:
14:07:30 <edleafe> #link Using Consumer Objects https://review.openstack.org/561407
14:07:41 <Sundar> Is there a comprehensive list of things that are pending for full nRP support?
14:07:47 <edleafe> #link Not using objects https://review.openstack.org/564641
14:08:21 <edleafe> The object-based approach got very messy very quickly, which is why I went back to my original approach
14:08:45 <efried> Sundar: Here's the current bottom of the series: https://review.openstack.org/#/c/556450/
14:08:57 <edleafe> Unless someone has strong feelings about the object approach, I'm going to proceed with the other
14:09:11 <efried> edleafe: I'll take a look at that this morning.
14:09:19 <edleafe> efried: thx
14:09:25 <efried> though I expect jaypipes to be the deciding vote.
14:09:45 <edleafe> cdent shared my distaste for Consumer objects
14:12:08 <edleafe> Speaking of the absent cdent, his patch for the optional separate db for placement has been sitting ready for merging for some time
14:12:22 <edleafe> #link Optional placement db https://review.openstack.org/#/c/362766/
14:12:33 <jaypipes> edleafe: I'll look at the new series today.
14:12:36 <edleafe> It would be nice to get that in
14:12:51 <edleafe> jaypipes: kewl
14:13:00 <jaypipes> edleafe: you know you've got unit test failures on it, though, right?
14:13:49 <edleafe> jaypipes: you mean the one labeled 'WIP'? Yes
14:14:51 <efried> When a problem comes along, you must WIP it....
14:15:28 <edleafe> OK, anything else for specs/reviews?
14:16:20 <edleafe> #topic Bugs
14:16:27 <edleafe> One new bug this week
14:16:38 <edleafe> Although it's more of a feature request
14:17:15 <edleafe> #link Make association_refresh configurable https://bugs.launchpad.net/nova/+bug/1767309
14:17:17 <openstack> Launchpad bug 1767309 in OpenStack Compute (nova) "Placement - Make association_refresh configurable" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)
14:17:19 <Sundar> efried: "we still don't have API support for nrp in alloc cands." Is there a plan to propose a changeset for that?
14:17:41 <efried> edleafe: I think we talked about this with tssurya last week.
14:17:59 <tssurya> yes
14:18:09 <efried> We're eventually going to get rid of the association_refresh timer entirely.
14:18:25 <tssurya> efried: yea, but would be nice to have some solution in queens
14:18:27 <efried> tssurya: You were going to try extending that interval in your env and see if it helped your load issues.  Did it?
14:18:31 <tssurya> even if we fix this in master
14:18:39 <efried> hm, I see.
14:18:42 <tssurya> efried: yea! big time improvement
14:19:21 <bauzas> holy shit, forgot that meeting
14:19:27 <efried> Okay; is it a done thing to introduce a conf option in a backport?
14:19:30 <bauzas> and now I need to leave :/
14:19:44 <efried> And immediately deprecate/remove it in master?
14:20:01 <melwitt> I was going to say, I don't think adding a config option just to queens is going to be desirable
14:20:04 <tssurya> efried: maybe we introduce the config in master first since the deprecation is not yet merged
14:20:32 <melwitt> and I didn't think we normally backport config options in general anyway
14:20:42 <bauzas> we don't indeed
14:20:43 <tssurya> melwitt: okay, yea I understand
14:20:52 <mriedem> um
14:20:58 <efried> tssurya: I'm trying to think whether we could just rip it out in queens.  But we can't, because not all of the generation stuff was there.  We would have to backport several supporting patches.
14:21:06 <mriedem> backporting a config option which by default is the same thing that is hard-coded seems fine to me
14:21:07 <bauzas> https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
14:21:08 <efried> (rip out the association refresh)
14:21:18 <mriedem> this isn't a new feature
14:21:21 <bauzas> if that's defaulted, sure we can
14:21:26 <melwitt> okay, mriedem is the expert
14:21:29 <mriedem> yes it would default to 300
14:21:36 <mriedem> so no change in behavior
14:21:39 <mriedem> but lets ops tweak it
14:21:40 <bauzas> but that needs to not change anything
14:21:44 <tssurya> mriedem: cool!
14:22:05 <efried> I'm fine with that.  Should be a pretty trivial change.  More paperwork than code.
14:22:11 <mriedem> if we didn't backport config options, kashyap's pcid thing wouldn't be in ocata right now...
14:22:34 <tssurya> efried, mriedem: awesome thanks so will introduce this in master and then backport to Queens
14:22:41 <melwitt> that was an exceptional case. originally we (redhat) thought we weren't going to be allowed to backport it
14:22:47 <mriedem> tssurya: sounds good, ping me when the patch is up
14:22:54 <efried> tssurya: don't forget reno :)
14:23:47 <edleafe> Glad that's settled. Any other bugs to discuss?
14:24:29 <tssurya> mriedem, efried : ack
14:24:46 <edleafe> #topic Open Discussion
14:25:02 <edleafe> Anything else to discuss? Or should we get back to work?
14:25:43 <edleafe> I'll take that as a sign that everyone's already back at work
14:25:45 <edleafe> #endmeeting