14:00:08 <edleafe> #startmeeting nova_scheduler
14:00:12 <openstack> Meeting started Mon Mar 12 14:00:08 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:15 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:28 <tssurya> o/
14:00:29 <gibi> o/
14:00:31 <jaypipes> o/
14:00:39 <edleafe> Good UGT morning! Especially to those recently switched to DST
14:00:53 <alex_xu_> o/
14:01:29 * bauzas ressurects from his house
14:01:54 <arvindn05> DST got me up 1 hr early :)
14:02:25 <edleafe> arvindn05: I usually need lots of coffee to do that :)
14:03:27 <edleafe> Small crowd today - guess we'll blame DST for that
14:03:46 <edleafe> Let's try to make this quick
14:03:51 <edleafe> #topic Specs
14:04:07 <edleafe> There are a bunch of 'em
14:04:18 <edleafe> I've listed them in the agenda:
14:04:26 <edleafe> #link Meeting Agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting
14:04:29 * gibi just inserted an extra one to the end of that list
14:04:31 <cdent> o/
14:04:41 <bauzas> I also need to add another one
14:04:46 <bauzas> for NUMA
14:04:49 <edleafe> Please do!
14:05:12 <cdent> was distracted trying to explain cache allocation support to non-openstack person...
14:05:28 <edleafe> Rather than go through each, I wanted to have a central list of those we need to review
14:05:38 <jaypipes> edleafe: you can remove the second one. it was just some ideas I had after the PTG and is long-term thinking, not for Rocky.
14:05:42 <edleafe> And then only discuss the ones that have questions
14:05:54 <edleafe> jaypipes: ack
14:06:16 <edleafe> I should give credit - I compiled the list of things (and review topics) from cdent
14:06:20 * efried waves late (IRC client disconnected without warning)
14:06:32 <edleafe> the placement email is wonderful
14:06:38 <jaypipes> ++
14:06:40 <edleafe> saves me a lot of time :)
14:07:15 <edleafe> So... anything in those specs we need to discuss?
14:08:17 <arvindn05> https://review.openstack.org/#/c/541507/ - latest comment from john garbutt
14:08:34 <cdent> not specifically on the traits, but perhaps later for the opens, some general things came up
14:10:00 <cdent> (my comment is semi-related to arvindn05's spec too)
14:10:13 <bauzas> I need to review those specs, that's it :)
14:10:40 <arvindn05> the concern seems to be user can add traits on glance image which can request "chargable" traits without the need to go through flavor
14:10:44 <edleafe> I have it open for re-review, too
14:12:34 <arvindn05> we could solve it by adding a configuration option to force image traits with flavor traits and not be a union....but wanted to get thoughts
14:12:48 <edleafe> arvindn05: it doesn't seem to to be fresh in anyone's mind at the moment
14:13:01 <edleafe> Let's review and leave comments / thoughts there
14:13:04 <bauzas> ++
14:13:19 <arvindn05> ahh..k...i will leave the comments there....not major so should be able to resovle via comments
14:13:33 <edleafe> Any other specs to discuss? Noting cdent's traits thing for Open
14:14:11 <jaypipes> edleafe: it's fresh in my mind. just not sure it's something we want to tackle at this point. frankly, certain image metadata has *always* been a "chargeable" trait -- for instance all the NUMA crap -- and it's not like we have a special solution to that other the protected properties.
14:15:07 <jaypipes> this is just one of those problems with having billing based on a tightly-coupled concept like flavors.
14:15:49 * edleafe shakes his fist at Rackspace
14:16:12 <jaypipes> not just RAX :) AWS, GCE, Azure all do billing this way...
14:16:35 <edleafe> jaypipes: but it was RAX that insisted it be that way in Nova
14:16:42 <bauzas> ...
14:16:47 <jaypipes> edleafe: sure, but that's ancient history ;)
14:16:57 <edleafe> Well, I'm an ancient guy
14:17:01 <jaypipes> hehe
14:17:20 <jaypipes> anyway, I'm happy to move on past this and just say protected image properties are, well, protected...
14:17:20 <edleafe> OK, let's move on then
14:17:22 <bauzas> fortunately, image metadata changed a lot since 1.5 years
14:17:24 <edleafe> #topic Reviews
14:17:33 <bauzas> now they are objectified
14:17:41 <jaypipes> bauzas: actually, it's barely changed in 7 years.
14:18:05 <jaypipes> bauzas: at least, what's coming from glance I mean.
14:18:14 <edleafe> I listed the "main themes" of development that cdent had in his email in the agenda
14:18:14 <bauzas> yeah from the glance standpoint, I agree
14:18:26 <bauzas> but from a nova standpoint, that's much better
14:18:39 <edleafe> We can go through them quickly
14:18:42 * jaypipes has one patch to discuss -- more about resource tracking..
14:18:58 <edleafe> efried: I assume Update Provider Tree work hasn't moved much since PTG?
14:19:23 <jaypipes> edleafe: needs a rebase.
14:19:25 <efried> edleafe: I haven't had a chance to check up on it yet.
14:19:38 <efried> okay, I'll try to get to that today, unless someone else wants to volunteer.
14:19:49 <edleafe> efried: cool, just checking
14:20:19 <jaypipes> efried: I would, but I'm going to be busy on the mirroring aggs thing
14:21:02 <edleafe> jaypipes: yeah, I had you to talk about the mirroring work
14:21:17 <edleafe> jaypipes: anything to discuss? Or still being worked on?
14:21:35 <jaypipes> edleafe: still need to finalize the spec. haven't started on the code yet.
14:21:46 <edleafe> jaypipes: gotcha
14:22:01 <edleafe> next theme: Request Filters
14:22:08 <jaypipes> dansmith: around?
14:22:16 <dansmith> yeah
14:22:35 <edleafe> I'm just starting the API change for agg filtering of A/Cs
14:22:52 <jaypipes> dansmith: besides reviews on your series, anything you need to bring up?
14:23:10 <dansmith> my series is blocked on getting that api added to placement,
14:23:20 <dansmith> which edleafe is gonna do
14:23:27 <dansmith> so I haven't really been doing much with it until that happens
14:23:34 <jaypipes> k
14:23:48 <edleafe> dansmith: will have something by late today or tomorrow, I hope
14:23:57 <dansmith> sweet, thanks
14:24:11 * edleafe hopes he doesn't keep getting pulled into meetings
14:24:39 <edleafe> Next: the tantalizingly-titled "Forbidden Traits"
14:24:48 <jaypipes> heh
14:24:49 <edleafe> cdent?
14:24:56 * jaypipes still needs to finalize that spec review.
14:25:01 <bauzas> just a question, why "forbidden" and not "avoided" ?
14:25:08 * bauzas loves to rathole during meetings
14:25:19 <cdent> I was waiting on the spec to resolve before starting on an implementation
14:25:20 <bauzas> call me pedantic
14:25:22 <edleafe> bauzas: dunno - I wanted "negative"
14:25:31 <dansmith> bauzas: avoided is not the right word, IMHO
14:25:31 <cdent> forbidden and avoided mean different things
14:25:41 <bauzas> heh, no worries
14:25:43 <efried> ditto negative
14:25:44 <dansmith> negative would be okay, although I personally like forbidden
14:25:56 <bauzas> anyway, it was just a pun
14:26:08 <bauzas> won't comment on the spec for that :)
14:26:09 <jaypipes> I try to avoid rat-holing on semantics, but I'm not forbidden from doing so.
14:26:10 <edleafe> it's just adding a boolean NOT
14:26:27 <jaypipes> edleafe: NOT any or NOT all?
14:26:29 <bauzas> shit, I created a discussion just about a pun
14:26:43 <bauzas> kill me
14:26:58 <edleafe> jaypipes: since required is all, forbidden should be all too, no?
14:27:11 <jaypipes> edleafe: I would actually think it should be NOT any...
14:27:26 <jaypipes> edleafe: i.e. "if the provider has any of these traits, filter it out"
14:27:52 <edleafe> jaypipes: yeah, that's what I thought I was saying
14:28:00 <edleafe> IOW, all are forbidden
14:28:20 * cdent gets out his semantics workbook
14:28:27 <bauzas> anyway
14:28:43 <bauzas> let's call it "forbidden" and just add a nice documentation explaining what's for
14:29:04 <edleafe> It was noted in the placement email that Consumer Generations has not been started, so the last main theme to discuss is Extraction
14:29:35 <cdent> I split up the resource provider object move into three patches as requested by dansmith
14:30:04 <cdent> including above those are some other extraction related patches
14:30:15 <bauzas> Inventories, Allocations, RPs ?
14:30:51 <jaypipes> bauzas: no... resource class fields, nova/objects/resource_provider.py move, and oslo.versionedobjects basing.
14:30:59 <cdent> #link move rp objs to placement https://review.openstack.org/#/c/540049/
14:31:18 <jaypipes> bauzas: this isn't about splitting out the objects inside resource_provider.py but rather removing it from the nova/objects directory.
14:31:18 <bauzas> ack
14:31:28 <bauzas> thanks
14:31:30 <jaypipes> np
14:31:34 <cdent> splitting up the file based on object type would be nice to do eventually but is not currently on the radar (as far as I know)
14:31:42 <jaypipes> ack
14:31:53 * bauzas nods (about not being a priority)
14:32:10 <edleafe> yeah, the file is big but not unworkable
14:32:38 <edleafe> Any other reviews anyone wants to discuss
14:32:40 <edleafe> ?
14:33:02 <jaypipes> yes
14:33:21 <jaypipes> this one: https://review.openstack.org/#/c/532924/
14:34:28 <bauzas> hah
14:34:59 <bauzas> it's related to the allocations discussion
14:35:04 <jaypipes> with all respect to maciej, the mess of default values and upgrade steps in there is too dangerous to mess with like that, IMHO.
14:35:42 <bauzas> jaypipes: well, we should maybe add him to the convo we had about alloc ratios
14:35:46 <bauzas> and the spec itself
14:36:07 <bauzas> the fact that people would like to change the ratio default value is understandable
14:36:24 <jaypipes> the whole block of cruft in the ComputeNode._from_db_obj() to deal with "Liberty computes" is going to lead to a situation where it will be impossible to tell whether or not an allocation ratio on an aggregate should be applied to a resource provider or not.
14:36:30 <bauzas> but maybe those operators would prefer to rather discuss about the next spec;)
14:37:19 <bauzas> like, I don't remember whether OVH said they were okay with deprecating the possibility to set ratios thru nova.conf
14:37:28 <bauzas> but that folk was at the PTG
14:37:32 <jaypipes> and if the default allocation ratios are changed (back) to 16.0/1.5/1.0 from the current 0.0 values, there will be no conceivable way to determine what to set the dang values to.
14:38:07 <jaypipes> bauzas: at the PTG, dansmith offered up a solution to use new configuration options (default_xxx_allocation_ratios) that would only be used for initializing a new compute node's allocation ratios
14:38:12 <bauzas> jaypipes: I'll comment the patch and tell him to look at https://review.openstack.org/#/c/544683/
14:38:24 <bauzas> yeah I remember
14:38:42 <jaypipes> bauzas: and I think dansmith is correct to say that we will need a new option and not try to jury-rig this crap any more than it already has been
14:38:51 <bauzas> what I'm trying to explain is that instead of him working on his sole patch, I'd be interested in him chiming on the spec :)
14:39:00 <dansmith> we need *something* other than just this
14:39:02 <jaypipes> bauzas: so if you don't mind, I'm going to -2 that particular patch./
14:39:29 <bauzas> I'm fine with that
14:39:32 <jaypipes> bauzas: that's cool with me, of course.
14:39:44 <bauzas> again, just make sure that he knows https://review.openstack.org/#/c/544683/
14:39:51 <bauzas> if you -2 it
14:40:14 <jaypipes> dansmith: did we decide at the PTG who might be responsible for doing this? you didn't volunteer for that right? just want to make sure I'm not stepping on something you wanted to work on.
14:40:27 <bauzas> the spec needs an update
14:40:31 <bauzas> at least
14:40:40 <bauzas> with what we agreed at the PTG
14:40:43 <dansmith> no, I guess I didn't think it got much traction, so I don't know that anyone is on the hook for it
14:40:52 <jaypipes> bauzas: yeah, I'm not even talking about the agg allocation ratio spec (yet).
14:40:57 <bauzas> I'll *try* to help
14:41:14 <bauzas> once I'm done with shitty paperworking
14:41:31 <jaypipes> dansmith: k, I will work with bauzas and maciej on this then. we definitely need to solve this default allocation ratio (for the compute node, not agg) before proceeding with anything else on the aggregate side.
14:41:50 <jaypipes> bauzas: heh.. yeah, I need to expense report stuff today as well.
14:41:54 <dansmith> ack
14:42:12 * edleafe just realized he has expense report crap too
14:42:31 <bauzas> jaypipes: see my note on #nova about the paperwork thingy
14:43:01 <jaypipes> heh. ok, back to you edleafe
14:43:11 <edleafe> jaypipes: thank you kind sir
14:43:16 <edleafe> #topic Bugs
14:43:19 <edleafe> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement&orderby=-id
14:43:27 <edleafe> No new bugs this week
14:43:32 <bauzas> sec
14:43:36 <bauzas> abotu bugs
14:43:41 <edleafe> go for it
14:43:42 <bauzas> I haven't triaged for 3 weeks
14:43:53 <bauzas> now we have a shit number of untriaged and new bugs
14:44:27 <bauzas> so, disclaimer: that's not because you had no new placement bugs that there couldn't be placement bugs :p
14:44:48 <cdent> there is a new bug this week: https://bugs.launchpad.net/nova/+bug/1751692
14:44:49 <openstack> Launchpad bug 1751692 in OpenStack Compute (nova) "os_region_name an unnecessary required option for placement " [Undecided,Confirmed]
14:44:54 <bauzas> if folks feel enough brave to face the beast and fight it
14:44:55 <bauzas> ...
14:44:55 <cdent> which I think needs some deciding
14:45:19 <edleafe> cdent: oh, that was from a few weeks ago
14:45:34 <edleafe> I thought it would have been discussed last week
14:45:36 <bauzas> cdent: we used that option for a signal
14:45:46 <cdent> its the wrong option
14:45:48 <jaypipes> bauzas: signal for what?
14:45:57 <cdent> edleafe: yeah, not new, rather unchanged
14:46:10 <bauzas> jaypipes: for finding whether nova.conf was set for placement
14:46:57 <bauzas> I don't exactly remember why the others were not possible to use, but AFAIK os_region_name was like the rare only ones that were good for signaling
14:47:09 * edleafe is very calendar-literal
14:47:29 * jaypipes doesn't remember the patch that added this signal or discussing it
14:47:35 <bauzas> the idea was that you had to amend nova.conf to amend placement things before restarting nova-compute in Ocata
14:47:55 <bauzas> now we are post that, maybe that defensive approach becomes useless
14:48:07 <bauzas> it was more for an upgrade perspective
14:48:19 <bauzas> like, you have to make things in order to have things to works
14:48:42 <jaypipes> bauzas: right, but just trying to connect to the placement service would provide the same signal, no?
14:48:44 <efried> os_region_name should be deprecated at this point, since the ksa adapter work.
14:49:13 <bauzas> jaypipes: IIRC, we weren't hard-failing when I introduced that
14:49:23 <bauzas> ie. the RT was just working "the old way"
14:49:33 <bauzas> now, it's indeed a blocking error
14:49:35 <cdent> efried: that's the exact point of the bug
14:49:44 <bauzas> hence my point, just kill the conditional I guess
14:50:00 <bauzas> but the ideal would be to test
14:50:42 <bauzas> my point being that configuring access to placement is a prerequisite
14:51:03 <bauzas> if you haven't done that in Rocky, you should be already in serious trouble
14:52:25 <edleafe> So are we agreed?
14:52:33 <bauzas> I guess
14:52:37 * bauzas just adding a bug comment
14:53:00 <edleafe> Let's move on, then
14:53:07 <edleafe> #topic Open Discussion
14:53:22 <edleafe> cdent: did you have something about traits?
14:53:47 <cdent> my two comments on the end of https://review.openstack.org/#/c/541507/ and https://review.openstack.org/#/c/497733/ are related to the general topic of "what's authoritative about traits" and "do we ever need to block them being reported"
14:54:01 <cdent> neither comments is directly related to the reviews, just inspired by them
14:55:15 <bauzas> that reminds me some good efried's point about removing traits if the virt driver tells nothing
14:55:33 <cdent> yes, that's part of it
14:56:14 <bauzas> so, I think there is an agreement that if the driver reports nothing, then remove the trait
14:56:26 <bauzas> trait(s) even
14:57:01 <edleafe> since traits are on RPs, then the RP should be authoritative. For compute, that would be the virt driver, right?
14:57:10 <bauzas> I'm not sure a CPU feature could just suddently disappear, but from a conceptual PoV, I just feel we need to keep the driver responsible for passing the traits accordingly
14:57:14 <efried> That's how I feel edleafe
14:57:19 <bauzas> yeah that
14:57:21 <efried> But there was disagreement at the PTG.
14:57:23 <bauzas> now, there is a trap
14:57:38 <bauzas> ironic can have some intermittent issues
14:57:46 <bauzas> where it could report dumb
14:58:12 <efried> That sounds like an ironic bug (title: Ironic reports dumb)
14:58:14 <bauzas> I think we basically said that that special case was just an exception handling
14:58:45 <jaypipes> bauzas: if the virt driver reports nothing, but an admin has set a trait on the compute node, we delete what the admin set? I don't think that's correct.
14:58:48 <bauzas> during the ironic/nova discussion at the super loudy and noisy breakfast room
14:59:02 <bauzas> jaypipes: hah, sec
14:59:06 <bauzas> that's another concern
14:59:37 <bauzas> here, I'm just talking of the fact that if the driver says "I have foo" and later says "I have bar", then we should add bar and remove foo
14:59:39 <cdent> nearly out of time, continue in #openstack-nova?
14:59:54 <efried> jaypipes: IMO, what that means is that "admin sets a trait" needs to take some form that ultimately means "virt driver sets that trait".
14:59:55 <jaypipes> FTR, I have the exact same concern about allocation ratios being set externally by an admin and being overwritten by the compute node resource tracker every periodic interval
15:00:15 <efried> jaypipes: Which may or may not be what your spec suggests.
15:00:24 <bauzas> I think at the PTG, we agreed on the fact that we can merge operator's defined traits with driver's defined traits
15:00:34 <bauzas> on an additive way
15:00:35 <efried> That way lies madness ^
15:00:42 <edleafe> Moving to -nova. Thanks everyone!
15:00:44 <edleafe> #endmeeting