14:00:13 <efried> #startmeeting nova-scheduler
14:00:15 <openstack> Meeting started Mon Feb 18 14:00:13 2019 UTC and is due to finish in 60 minutes.  The chair is efried. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:18 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:23 <cdent> o/
14:00:25 <takashin> o/
14:00:31 <cdent> jay sends his apologis, he's got appt
14:00:31 * gibi is on another meeting in parallel
14:00:36 <efried> #link agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting
14:00:40 <tetsuro> o/
14:00:42 <gibi> o/
14:00:53 <efried> US holiday today. I, for one, will be off after this.
14:01:10 <mriedem> presidents day is an intel corporate holiday?
14:01:19 <efried> yeah, it was a surprise to me too.
14:01:21 <cdent> I was just gonna say, people get that off?
14:01:22 <mriedem> wow
14:01:23 <efried> I was informed on Friday.
14:01:26 <mriedem> not i
14:01:43 <efried> Apparently my badge has all the holidays on it.
14:01:57 <efried> But I don't wear my badge to "the office", so I didn't notice.
14:02:42 <efried> Let's get started.
14:02:49 <alex_xu> o/
14:02:51 <efried> #topic last meeting
14:02:51 <efried> #link last minutes http://eavesdrop.openstack.org/meetings/nova_scheduler/2019/nova_scheduler.2019-02-11-14.00.html
14:02:56 <efried> Any old business?
14:03:14 <efried> #topic specs and review
14:03:14 <efried> #link latest pupdate http://lists.openstack.org/pipermail/openstack-discuss/2019-January/002055.html
14:03:14 <efried> #link blueprint tracking https://etherpad.openstack.org/p/nova-stein-blueprint-status
14:03:29 <alex_xu> mriedem: not intel china holiday
14:03:34 <efried> #link libvirt reshaper (new bottom of series) https://review.openstack.org/#/c/636591/
14:04:03 <efried> An issue was discovered about relating RPs to real devices, so the new bottom of the series is trying to solve that.
14:04:08 <mriedem> alex_xu: :)
14:04:48 <efried> bauzas on the hook for a new PS there to add tests, but it looks correct to me.
14:04:58 <bauzas> oops
14:05:03 * bauzas waves late
14:05:04 <efried> #link xen reshaper (middle of series) https://review.openstack.org/#/c/521041
14:05:04 <efried> still ditw afaik
14:05:24 <efried> #link in_tree allocation candidates series starting at https://review.openstack.org/#/c/635722/
14:05:25 <efried> needs review (incl from me)
14:05:41 <efried> #link Placement OVO-ectomy series starting at https://review.openstack.org/#/c/636631/
14:05:53 <mriedem> i think i'm going to abandon the xenapi series
14:05:57 <mriedem> so we can stop talking about it
14:06:00 <efried> ight
14:06:02 <cdent> mriedem++
14:06:08 <efried> I'll mention next time that it was abandoned.
14:06:37 <efried> ...And on top of the OVO-ectomy series:
14:06:37 <efried> #link DRY/clean up placement objects starting at https://review.openstack.org/#/c/637325/
14:06:52 <cdent> efried: in case you haven't seen it yet, jay has some ideas on how to further simplify your simplifications to my simplifications in the ovo-ectomy
14:07:12 <efried> cdent: thanks, I did. Basically get rid of *List and just use [].
14:07:12 <cdent> I suggested he put them on top of yours
14:08:20 <efried> I'll have to have a think about that. If the methods currently in ObjectList are actually needed, I guess I would rather they be object methods than module-level.
14:08:51 <efried> unless they're @static. But the top patch makes it @classmethod.
14:09:29 <efried> anyway, will look more later. Nothing super urgent about this in any case.
14:09:39 <cdent> naw
14:09:44 <efried> Anyone have anything to discuss on any of the above, or any other specs/reviews?
14:10:06 <cdent> naw
14:10:21 <cdent> (ed also sends his apologies, getting a new knee)
14:10:48 <mriedem> president's day discount at the knee store
14:10:50 <efried> (looking at it, I'm actually not sure what value _set_objects adds over __init__)
14:11:18 <efried> anyway...
14:11:29 <efried> #topic Extraction
14:11:29 <efried> #link Extraction https://etherpad.openstack.org/p/placement-extract-stein-5
14:11:50 <cdent> (probably none, it was simply a matter of iteration)
14:12:24 <efried> #link Placement governance separation https://review.openstack.org/#/c/636416/
14:12:24 <efried> Approvable on Wednesday.
14:13:20 <efried> #link The bizarre and confusing election patch that allows us to have PTL elections with the rest https://review.openstack.org/#/c/636510/
14:13:21 <efried> ^ is merged.
14:13:47 <efried> anything else about extraction? cdent?
14:13:59 <cdent> not that I'm aware of, thanks.
14:14:40 <efried> #topic bugs
14:14:40 <efried> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:14:40 <efried> anything of note here?
14:14:50 <mriedem> i've got a bug mention
14:14:53 <mriedem> not placement related
14:15:07 <efried> placement schmacement, this is a n-sch meeting
14:15:10 <mriedem> #link https://review.openstack.org/#/c/509206/ we finally have a fix for renaming AZs with instances in them
14:15:21 <mriedem> that's approved, but need another +2 on the api-ref change below it
14:15:38 <mriedem> we agreed on doing this at a few ptgs should it shouldn't be a surprise, avolkov was the one to get it done
14:15:45 <mriedem> *so it shouldn't
14:16:20 <bauzas> yup
14:16:27 <cdent> time
14:16:30 <cdent> moves
14:16:33 <efried> I'll mention
14:16:33 <efried> https://bugs.launchpad.net/nova/+bug/1816086
14:16:35 <openstack> Launchpad bug 1816086 in OpenStack Compute (nova) "Resource Tracker performance with Ironic driver" [Undecided,In progress] - Assigned to Eric Fried (efried)
14:16:36 <cdent> slowly
14:17:19 <mriedem> efried: we're waiting for tssurya to test that out right?
14:17:20 <efried> CERN started upgrading ironic things to rocky and found out that update_from_provider_tree is spending a *lot* of time locally spinning through the ProviderTree object.
14:17:24 <efried> Yeah
14:17:44 <efried> I proposed https://review.openstack.org/#/c/637225/ to see if it helps, but I suspect it will not be all of the solution.
14:17:56 <mriedem> related to that same upgrade, they hit https://bugs.launchpad.net/nova/+bug/1816034 which i have a patch for: https://review.openstack.org/#/c/637217/ which will need to be tweaked on stable
14:17:57 <openstack> Launchpad bug 1816034 in OpenStack Compute (nova) "Ironic flavor migration and default resource classes" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)
14:17:59 <cdent> O notation! This is computers. I know this.
14:18:26 <efried> Not just any O. Big-O.
14:19:09 <efried> okay, any other bugs?
14:19:31 <efried> #topic opens
14:19:31 <efried> Post governance change plans for this meeting. Keep as is? Have two separate meetings? Does placement need a regular meeting? Office hours? Something else?
14:20:04 <cdent> Ed has mentioned that ^ to me and I said "let's decide later" and he said "we should at least allow people some time to think about it" so here it is.
14:20:19 <efried> Yeah, it's not crucial that we "fix" this ^ immediately on some event, like governance patch merging or a PTL being elected.
14:20:23 <mriedem> i don't think we need a separate n-sch meeting on its own, since we have a nova meeting
14:20:28 <efried> ++
14:20:59 <bauzas> so this meeting should be renamed ?
14:21:24 <mriedem> yeah this should likely be the placement meeting
14:21:32 <cdent> For my own purposes, once I start the pupdate back up, the meeting has less value, but is still nice to sort of empathetically sync up.
14:21:34 <mriedem> since that's mostly what's been discussed here for a couple of years
14:21:46 <bauzas> heh, this slot : nova-sch > gantt > nova-sch > placement \o/
14:21:55 <gibi> then nova-scheduler stuff goes back to the nova-meeting?
14:22:02 <efried> yeah
14:22:03 <bauzas> I'm fine with that
14:22:05 * cdent is really burnt on irc
14:22:25 <cdent> as before, we don't have to decide immediately, but sounds like there's an emerging consensus to rename and carry on
14:22:34 <bauzas> we needed meetings beforehand because we had large discussions about the scheduler
14:22:39 <efried> Well, I agree that I'm not sure if we really need a meeting.
14:22:51 <bauzas> now that we have placement, I'm not sure we need a timeslot
14:23:13 <efried> yeah, what bauzas said. As long as things are fairly stable and uncontroversial, there's not really a good reason to get us all together to simply list patches being worked.
14:23:36 <efried> I say we let the new PTL send an email to the ML to get feedback and go from there.
14:23:43 <bauzas> less meetings is always a good idea FWIW
14:24:12 * bauzas hopes he isn't controversial :p
14:25:19 <efried> Any other input on the meeting logistics?
14:25:25 <cdent> sounds like we're done with that topic
14:25:31 <efried> (We're really breaking the fourth wall here. It's so meta.)
14:25:33 <bauzas> call it done
14:25:40 <efried> Any other topics for open discussion?
14:25:42 <gibi> I have one
14:25:48 <gibi> do we want nova manage heal_allocations to handle the missing neutron port allocations or shall I add a separate command for that?
14:26:12 <efried> would it be a neutron manage command?
14:26:16 <efried> The allocations belong to the instance.
14:26:23 <efried> Makes sense to me that it should be done in nova-manage.
14:26:41 <efried> and in the same place as we would heal any allocations for the instance.
14:26:42 <gibi> efried: yeah it belongs to nova-manage
14:27:01 <efried> but that sounds like a mriedem question.
14:27:13 <bauzas> I have a related question
14:27:27 <bauzas> so, we now have a reshape API
14:27:34 <bauzas> for moving allocations
14:27:34 <mriedem> gibi: i thought we already said it should be done in heal_allocations
14:27:36 <bauzas> all good
14:27:54 <gibi> mriedem: I had vague memories about the location, but I'm OK to put it there
14:28:06 <gibi> mriedem: but then I will carry on
14:28:46 <bauzas> I just wonder when we should ask operators to trigger heal_allocs vs. us doing a reshape
14:29:11 <bauzas> of course, reshapes are for upgrades
14:29:12 <gibi> reshape moves inventories
14:29:22 <gibi> heal_allocation creates missing allocations
14:29:32 <gibi> this is the distinction in my head
14:29:44 <bauzas> here I see two distinct patterns
14:29:48 <bauzas> one is automatic
14:29:56 <bauzas> the other one requires operator trigger
14:30:10 <mriedem> reshape is on the compute needing info from the virt driver
14:30:14 <mriedem> heal_allocations does not
14:30:16 <mriedem> or should not
14:30:41 <mriedem> heal_allocations is basically "do the thing the scheduler should have done if the scheduler would have created these allocations"
14:30:50 <gibi> bauzas: heal_allocation for neutron port might not be possible if there is not enough inventory while reshaping vgpu tree should always work
14:30:53 <mriedem> it was written for caching scheduler users originally
14:31:11 <bauzas> yeah, I totally got all of what you both say
14:31:35 <bauzas> I'm just trying to make sure we don't use both reshape and heal_allocs in some wrong way
14:32:03 <efried> does the user understand the distinction?
14:32:07 <bauzas> but, if somehow, we say that reshape should be only for updating our view by the virt driver, I'm ok
14:32:11 <efried> s/user/operator/ bah
14:32:29 <bauzas> efried: that's my concern, I think most of us know the distinction
14:32:33 <mriedem> reshape moves *existing* things
14:32:43 <mriedem> heal_allocations fills gaps
14:32:49 <gibi> ^++
14:33:03 <bauzas> OK, I think we are all in agreement
14:33:10 <bauzas> I don't want to nit this
14:33:15 <mriedem> there are other scripts floating out there that ops are using as well https://bugs.launchpad.net/nova/+bug/1793569
14:33:16 <openstack> Launchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,Confirmed]
14:34:04 <cdent> (something or the ptg: should there be an /audit _in the api_ ?)
14:34:08 <cdent> s/or/for/
14:34:28 <mriedem> sounds like a healthcheck goal, but that's a bit different i guess
14:34:35 <cdent> similar
14:34:45 <cdent> it's more for support people who want to "at a glance"
14:34:51 <mriedem> GET /does_it_look_like_someone_fed_up
14:35:04 <cdent> people keep writing db scripts for the same thing
14:35:30 <mriedem> i tend to think it depends on the client-side context to figure out what is wrong
14:35:36 <mriedem> placement probably doesn't have that context
14:35:37 <efried> #link nova train etherpad https://etherpad.openstack.org/p/nova-ptg-train
14:35:37 <efried> (are we going to make a separate placement one?)
14:36:50 <cdent> prolly?
14:36:55 <cdent> what do people want?
14:37:23 <cdent> the ptg is going to painful in a variety of ways
14:37:36 <cdent> but having some focus to the etherpads will help
14:37:48 <cdent> (painful mostly because we already did 3 days of other stuff)
14:38:19 <efried> well, we've had a separate placement etherpad for the last couple of ptgs anyway.
14:38:19 <bauzas> I feel the Saturday afternoon won't be productive anyway
14:38:38 <efried> I guess the question is whether we want to have a separate placement "room"
14:38:45 <efried> for a day or a half day or something.
14:38:49 <cdent> In case anyone wants to join me, I think saturday as a hack day instead of talk day would be nice
14:39:00 <bauzas> I don't disagree
14:39:03 <cdent> pizza, beer, code
14:39:24 <cdent> juggling, etc
14:39:38 <gibi> separate room means I have to float between rooms
14:39:46 <bauzas> well
14:39:53 <efried> Seems like placement should be primarily "cross-project", with initially the majority of time spent with nova.
14:40:05 <mriedem> what we'd do is organize a cross-project time slot
14:40:06 <bauzas> every PTG, we are exhausted by all placement things we discuss
14:40:10 <mriedem> like we do with nova/cinder, nova/neutron, nova/ironic
14:40:31 <cdent> yeah, I think we can probalby limit the total time of "just placement" quite a lot, and mostly be with other folk
14:40:32 <mriedem> placement things are discussed 9-noon friday or something
14:40:47 <gibi> works for me
14:40:54 <efried> We also need e.g. placement/blazar cross-project...
14:41:04 <cdent> I'm hoping (optimism!) that without placement out, it will finally allow nova to get on with other stuff
14:41:07 <bauzas> if all the placement thingies go to a separate timeslot, and nova gets a 2-hour cross-project timeslot, then it'll be actually better than today
14:41:14 <bauzas> cdent: yeah me too
14:41:22 <cdent> s/without/with/
14:41:47 <efried> Anyone know offhand when PTL elections finish up, relative to the PTG?
14:42:02 <bauzas> efried: https://governance.openstack.org/election/
14:42:36 <bauzas> hem
14:42:42 <efried> bauzas: yeah, does that actually say?
14:42:48 <cdent> it's not been updated for next yet
14:42:52 <bauzas> my bad, no agenda for PTL :)
14:42:58 <cdent> one sec
14:43:03 * bauzas checks the gerrit repo for election
14:43:15 <efried> the gerrit patch still talks about the TC.
14:43:20 <cdent> https://review.openstack.org/#/c/629749/
14:43:37 <cdent> end around march 19
14:43:44 <efried> o, I guess that needs a Placement.placeholder.
14:44:20 <cdent> a bureucrat somewhere presumably thinks that has to wait on the gov thing
14:44:28 <cdent> (reasonably so I guess)
14:44:43 <efried> I have posted the question.
14:45:16 <efried> Anyway, this would be another useful thing for the PTL to ask the ML, assuming there's time, which if the election finishes in mid-March, there probably will be.
14:46:45 <efried> Okay, are we ready to wrap up?
14:46:49 <cdent> yes please
14:47:11 <efried> Thanks all.
14:47:11 <efried> o/
14:47:11 <efried> #endmeeting