14:00:20 <efried> #startmeeting nova_scheduler
14:00:21 <openstack> Meeting started Mon Oct  1 14:00:20 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:37 <edleafe> \o
14:00:53 <gryf> hi ed.
14:01:05 <efried> #link Agenda https://wiki.openstack.org/wiki/Meetings/NovaScheduler#Agenda_for_next_meeting
14:01:06 <takashin> o/
14:01:12 * efried waits for folks to file in
14:01:39 <cdent> o/
14:01:44 <tetsuro> o/
14:03:07 <bauzas> i'm in but for 20 mins
14:03:40 <efried> Okay, let's get started.
14:03:51 <efried> #topic last meeting
14:03:51 <efried> #link last minutes: http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-09-24-14.00.html
14:03:51 <efried> Any old business?
14:05:15 <efried> #topic specs and review
14:05:15 <efried> #link latest pupdate: http://lists.openstack.org/pipermail/openstack-dev/2018-September/135229.html
14:05:15 <efried> Anything to discuss from the pupdate?
14:06:02 <efried> <crickets>
14:06:21 <efried> #link Consumer generation & nrp use in nova: Series now starting at https://review.openstack.org/#/c/583667
14:06:21 <efried> In a runway (ends Oct 4)
14:06:21 <efried> Any comments/questions/discussion on this?
14:07:10 <cdent> sorry, slow, the only thing I'd mention from the pupdate is the thing about belmoreia
14:07:28 <efried> That's on the agenda under opens
14:07:34 <cdent> cool
14:08:06 <efried> Extraction
14:08:06 <efried> #link mriedem ML update on extraction http://lists.openstack.org/pipermail/openstack-dev/2018-September/135276.html
14:08:06 <efried> cdent, edleafe, mriedem, status?
14:08:33 <cdent> i've got nothing new, other than what I wrote in the pupdate about docs and database stuff
14:08:41 <edleafe> Me neither
14:08:50 <edleafe> I'll have some cycles this week to work on thigns
14:08:54 <edleafe> things, even
14:09:27 <efried> mriedem isn't around, but the email --^ is good news.
14:09:40 <efried> #topic bugs
14:09:40 <efried> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:09:40 <efried> Any bugs to discuss specifically?
14:11:28 <efried> #topic opens
14:11:28 <efried> Placement "metadata" via traits or a new key/value primitive?
14:11:28 <efried> #link ML thread on "intended purpose" of traits http://lists.openstack.org/pipermail/openstack-dev/2018-September/135209.html
14:11:54 <efried> Some key interested players aren't here, so any discussion may be lopsided.
14:12:08 <efried> Continuing the discussion on the ML is probably best
14:12:21 <efried> Anyone want to discuss here?
14:12:29 <edleafe> Jay was supposed to push a spec
14:12:40 <edleafe> I thought that would be a good starting point for further discussion
14:12:47 <bauzas> honestly, it could be a never-ending story
14:13:01 <efried> yah. I haven't gotten through my emails yet to know whether that has happened or not.
14:13:39 <efried> Okay, let's move on.
14:13:51 <efried> How to handle min_unit (and others) in a forward-looking (i.e. generic NRP) way?
14:13:52 <efried> #link IRC discussion with belmoreira http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-09-20.log.html#t2018-09-20T14:11:59
14:13:52 <efried> #link Post-last-meeting discussion on generic configuration of provider settings http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-09-24.log.html#t2018-09-24T15:02:05
14:14:01 <cdent> on metadat stuff: I think there are at least three different problems that are trying to be solved with the same name, and that's going to lead to difficult resolution, so if the spec is able to separate out one of the issues, that will be good
14:14:46 <leakypipes> cdent, edleafe, efried: I just posted a response to jroll in the one ML thread about deprecating ComputeCapabilitiesFilter.
14:14:48 <efried> Yes, agree that "passing config info to nova" is one of the problems in the mix, and agree with Jay that that one shouldn't be placement's business (either by architecture or by usage)
14:15:00 <leakypipes> cdent, edleafe, efried: which outlines the type of solution I'd like to see.
14:15:07 <efried> oh, hello leakypipes, didn't see you there under your Friday guise.
14:15:17 <jaypipes> ack, sorry
14:15:36 <efried> So yeah, if that removes a bit of the noise, that's goodness.
14:16:10 <efried> I believe we still have lots of use cases for key/value used to make placement (allocation candidate) decisions.
14:18:58 <jaypipes> I'm still reviewing tetsuro's nested with alloc cands series.
14:19:06 <jaypipes> it's slow going to say the least.
14:19:15 <efried> And I'll mention that saying I "don't care" which way we go was indeed a poor choice of words and/or oversimplification.
14:19:15 <efried> I would like, ideally, long-term, to see a true key/value primitive, because I think it's much more powerful and less hacky.
14:19:15 <efried> But am sympathetic to what Chris brought up about full plate and timeline.
14:19:15 <efried> So while we're waiting for that to fit into the schedule, I wouldn't mind the ability to use "encoded" traits to some extent to satisfy the use cases.
14:19:39 * bauzas needs to leave you now
14:20:12 <efried> Like we used a single provider to represent compute resources while we were waiting for nested/sharing to mature.
14:20:54 <efried> I'll reiterate -^ on the ML in some form or fashion.
14:21:02 <efried> Further discussion here?
14:21:07 <cdent> efried: only to say one thing:
14:21:17 <jaypipes> efried: nothing other than "it's my advice not to do that" is preventing callers from doing the encoded string traits stuff.
14:21:32 <efried> true story
14:21:36 <jaypipes> efried: there's nothing, unfortunately, about our API that discourages that misuse.
14:21:46 <efried> also true
14:21:54 <jaypipes> but good for the ML, as said earler.
14:22:09 <jaypipes> _get_trees_matching_all() is a giant ball of spaghetti.
14:22:25 <cdent> I don't think it is useful for us to say that "nested" is the expected and correct way to represent compute resources once we have the capability. It's only useful for performance workloads. For boring cloud-simple workloads non-nested is the easiest and cleanest and most immediate way to do compute resource providers. We should be making that clear.
14:22:31 <jaypipes> making reviews on tetsuro's patch very difficult.
14:22:44 <jaypipes> cdent: ++
14:23:14 <jaypipes> cdent: which was the reason behind that "use simple code path when you can" patch, FWIW.
14:23:25 * cdent nods
14:23:34 <efried> hm, I would say it's not that simple. E.g. you can't use non-nested when you have multiple networks on separate NICs.
14:23:42 <efried> i.e. it's not just performance that's the use case for nested.
14:23:58 <cdent> "cloud-simple" cares naught for that
14:24:03 <efried> but taking the point of, "don't use nested unless you have to"
14:25:10 <efried> Which is somewhat of a segue back to:
14:25:10 <efried> How to handle min_unit (and others) in a forward-looking (i.e. generic NRP) way?
14:25:10 <efried> #link IRC discussion with belmoreira http://eavesdrop.openstack.org/irclogs/%23openstack-placement/%23openstack-placement.2018-09-20.log.html#t2018-09-20T14:11:59
14:25:10 <efried> #link Post-last-meeting discussion on generic configuration of provider settings http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-09-24.log.html#t2018-09-24T15:02:05
14:25:44 <jaypipes> efried: I'm a little confused how the min_unit discussion is related to nested?
14:26:04 <efried> Because with no nested, you don't have the boggle of how to identify which provider you're tweaking.
14:26:21 <efried> the mechanisms we have today will work.
14:26:48 <efried> cdent: if you recall, you brought up a concern about deploy tools (osa, tripleo) being able to lay down the provider tweaks in a single step, rather than having to deploy, detect, write config, and possibly restart.
14:26:48 <jaypipes> efried: oh, you're referring to how the allocation ratio for child providers would actually be discovered. gotcha.
14:26:52 <efried> yeah
14:26:55 <jaypipes> ack.
14:27:11 <jaypipes> sorry, I thought you were talking about the "why is max_unit == total" thing.
14:27:20 <cdent> it's related
14:27:41 <efried> Well, for reference, belmoreira says they've sorted out this specific issue for now. So really this is just the more general discussion.
14:27:45 <jaypipes> cdent: in so much as "what does 'total' mean in a nested scenario"? :)
14:27:45 <cdent> the argument is that if you want something different than == total you need tools to default it and to also manage it later
14:27:54 <jaypipes> ack
14:28:42 <efried> So the discussion (second link above) went down the path of being able to determine *before deploy* a way to identify providers, which we (Jay) figured we could do with a deterministic naming scheme for providers.
14:29:36 <efried> Which we've been more or less converging on with e.g. the vgpu stuff, but it being deterministic has been almost accidental. We should make that strict, now, to anticipate this potential future need.
14:30:07 <jaypipes> efried: could you be more specific? are you referring to encoding the supported vGPU type into the provider name somehow?
14:30:16 <efried> So for example, making sure provider names are unique by composing them with their parent name - not by e.g. appending a random UUID.
14:30:37 <jaypipes> efried: ack, yes, I think that's generally agreed upon, yeah?
14:30:40 <efried> jaypipes: No, encoding the VGPU type in the name would be fine, because that should also be deterministic.
14:31:09 <jaypipes> efried: for the record, I *don't* think encoding the vGPU type in the provider name is a good idea.
14:31:27 <efried> Ack, that's clear from the review. This is a separate topic, tho.
14:31:35 <jaypipes> ok
14:31:38 <efried> jaypipes: Yes, it's agreed upon, but like I say, we made that decision without really thinking about the aspect of the name needing to be *deterministic* as well as being unique.
14:32:03 <efried> Point being, we made a decision that works for this, but it satisfies this criterion by coincidence, not because we were thinking of this.
14:32:09 <jaypipes> efried: isn't a PCI (or other bus type) address deterministic?
14:32:09 <efried> So I'm saying moving forward, we should think of this
14:32:12 <efried> yes
14:32:21 <jaypipes> k
14:32:30 <jaypipes> so we're in violent agreement. :)
14:32:37 <efried> Yup. Kisses.
14:32:41 <jaypipes> lol
14:33:20 <efried> Meanwhile, the file format proposals being worked by me, kosamara, and sean should be at least somewhat anticipating the ability to use these names to identify the providers.
14:33:50 <efried> Which ought to be pretty straightforward given the direction they're going, but again, I'm not sure we've actually put a focus on that criterion yet. So we should.
14:34:26 <efried> Any questions, comments, discussion?
14:34:37 <jaypipes> efried: link to that spec again pls?
14:34:43 <efried> stand by
14:35:14 <efried> #link kosamara's spec for modeling passthrough https://review.openstack.org/#/c/591037/
14:35:15 <efried> and
14:35:42 <jaypipes> danke
14:35:45 <efried> #link sean-k-mooney's wip spec for generic device discovery/modeling https://review.openstack.org/#/c/603805/
14:36:18 <cdent> I'll just throw out there that several decades of data storage design have made it clear that using meaningful names for identifiers is an antipattern
14:36:25 <efried> jaypipes: indeed, it would be helpful if you could express a preference for one or the other of those directions so we can narrow and focus on just one.
14:36:47 <cdent> so we need to be damn sure that these are labels
14:37:13 <efried> jaypipes: Note that both are currently far from perfect
14:37:47 <efried> cdent: Mm. The provider identification mechanisms in those specs are actually centered around other attributes at the moment, things like PCI addresses or whatever.
14:38:26 <efried> which, actually, might also work just fine. As long as, again, those things are deterministic and relatively easy to predict.
14:39:06 <jaypipes> efried: ack. I can try and review both today.
14:39:12 <efried> cool, thanks.
14:40:42 <efried> Anything else before we close?
14:41:21 <jaypipes> not from me.
14:41:29 <jaypipes> looks like it's gonna be a spec and review day for me. :)
14:41:56 <cdent> nothing from me
14:42:07 <efried> Okay, thanks all.
14:42:08 <efried> #endmeeting