Friday, 2019-06-14

*** yikun_ has joined #openstack-placement03:08
*** yikun has quit IRC03:09
*** yikun_ is now known as yikun03:09
*** mugsie has quit IRC03:22
*** guilhermesp has quit IRC03:22
*** mgagne has quit IRC03:22
*** sean-k-mooney has quit IRC03:22
*** licanwei has quit IRC03:32
*** mugsie has joined #openstack-placement03:37
*** guilhermesp has joined #openstack-placement03:38
*** mgagne has joined #openstack-placement03:38
*** sean-k-mooney has joined #openstack-placement03:38
*** irclogbot_3 has quit IRC03:41
*** irclogbot_0 has joined #openstack-placement03:42
*** e0ne has joined #openstack-placement05:21
*** tetsuro has joined #openstack-placement05:48
*** tetsuro has quit IRC06:39
*** gibi has joined #openstack-placement07:08
*** e0ne has quit IRC07:35
*** helenafm has joined #openstack-placement07:43
*** tetsuro has joined #openstack-placement08:09
*** tetsuro has quit IRC08:09
*** tetsuro has joined #openstack-placement08:10
*** tetsuro has quit IRC08:10
*** ttsiouts has joined #openstack-placement08:15
*** cdent has joined #openstack-placement08:33
cdentgibi: if you have a chance to get your eyes on https://review.opendev.org/662785 (allocation mappings) that would be excellent, seeing as it was kind of your idea08:35
cdentIf I had any bright ideas last night about nested stuff, I didn't remember them08:35
*** e0ne has joined #openstack-placement09:08
gibicdent: looking...09:09
cdentthanks09:10
cdentwill do that followup for the doc strings now09:10
openstackgerritChris Dent proposed openstack/placement master: Add missing suffix-related docstrings  https://review.opendev.org/66533509:18
cdentgibi: ^09:18
cdentbiab09:18
gibicdent: aack09:18
cdentaaaaaaaaaack :)09:18
gibicdent: thanks for implementing the mapping spec! I would not have time to do it09:21
cdentgibi: it was much easier than I feared, and the only reason I was doing it was trying to learn something, a very simple POC, and it proved to be good enough09:40
gibicdent: yeah, I was also suprised how small the real code impact was in your patches09:41
cdentthanks for the quick review. I'm going to head to town to write the pupdate09:43
* cdent waves09:43
*** cdent has quit IRC09:43
gibibye09:43
*** ttsiouts has quit IRC10:27
*** ttsiouts has joined #openstack-placement10:27
*** ttsiouts has quit IRC10:32
*** cdent has joined #openstack-placement10:32
*** helenafm has quit IRC10:57
*** ttsiouts has joined #openstack-placement11:04
openstackgerritMerged openstack/placement master: Prepare objects for allocation request mappings  https://review.opendev.org/66278511:13
openstackgerritMerged openstack/placement master: Implement allocation candidate mappings  https://review.opendev.org/66224511:23
openstackgerritBalazs Gibizer proposed openstack/placement master: Add support for osprofiler in wsgi  https://review.opendev.org/66394511:38
*** cdent has quit IRC11:58
*** cdent has joined #openstack-placement12:16
cdentstephenfin if you're around and want a quick thing to review: https://review.opendev.org/#/c/665335/13:07
stephenfincdent: Sure. Done13:21
cdentgreat thanks13:21
cdentthat's one more cycle goal done13:22
*** e0ne has quit IRC14:13
efriedcdent: ni haowdy14:14
cdentbonjour14:14
efriedI felt like we were close on nested magic 1, and then... nothing in the last 24h or so.14:14
efriedWhat is your feeling on the conclusion (I concluded, asking whether others agree it is a conclusion) that we just need to add a "traits/aggs on the ROOT" concept?14:15
*** ttsiouts has quit IRC14:16
efriedIf we can agree on that ^ then I proposed two possible ways to make it so.14:16
*** ttsiouts has joined #openstack-placement14:17
cdentI'm not up to date on your last comments (my email seemed to tell me about your response to bauzas, but I didn't notice the one just before that), so I need to digest that14:17
cdentbut as gibi and I were saying yesterday both of us were needing a bit of thinking time14:17
bauzascdent: efried: I need to look at the replies then14:17
cdenti'll catch up in a few minutes after I finish the thing I'm doing right now14:17
efriedbauzas: Shouldn't be anything surprising there. Replies to your comments weren't really related to the burning question we've been trying to extinguish.14:20
*** ttsiouts has quit IRC14:21
*** stephenfin is now known as finucannot14:26
cdentefried: yeah, that does seem close. That is, nothing you're saying there is making me do my traditional "omg, eric and I are thinking about this completely differently, something is very wrong" reaction14:26
cdentefried: a question of mine that you didn't seem to answer directly (at least not to my tired post-pupdate brain): "A question worth asking is: If we added a 'already_found..' why wouldn't I use that all the time instead of unsuffixed required? And if that's the case maybe unsuffixed required _is_ (that is should act like, but with the name required) 'already_found..'?"14:27
cdentplacement-folk: I wrote a bit about placement culture in https://anticdent.org/more-on-maintainership.html , in case you're curious14:28
cdentefried: if you can calm my sad on that question (which distill as "what's the best common path?") I think we've probably got a goer. At least until the next wrinkle...14:29
*** artom is now known as temka14:29
cdenti'll be back in a few minutes14:37
*** cdent has quit IRC14:38
*** dklyle has quit IRC14:42
*** dklyle has joined #openstack-placement14:42
*** cdent has joined #openstack-placement14:51
efriedcdent: composing, hang tight14:51
* cdent hangs14:52
*** e0ne has joined #openstack-placement14:57
*** e0ne has quit IRC15:00
efriedcdent: "why wouldn't I use that all the time instead of unsuffixed required" ... "maybe unsuffixed required ... should act like"15:02
efriedThe technical difference would be that unsuffixed required is (today) deliberately limited to the providers of unsuffixed resources. So theoretically you would use unsuffixed required if you wanted to *prevent* things from creeping in from the *implicit* parts of the solution path.15:02
efriedBut if you've modeled The Gibi Way (resource-specific traits are on providers of those resources) then you should get the same result either way.15:02
efriedHowever, you're *also* preventing things creeping in from the *explicit* parts of the solution path that result from *other* request groups. And this is where I have a problem. Because that's a fundamental change in the way request groups work.15:02
efriedIOW: extending to include *implicit* additions is at least justifiable in my head, because they aren't truly a part of the current (in master) concept space yet. But extending to include things from *other groups* is too big a leap IMO.15:02
efried========15:02
efriedSo this is where the "narrow to ROOT" idea comes in. Instead of introducing (and trying to explain) the "solution path" concept, we *just* introduce (and explain) that ROOT is always part of the solution, whether it provides resource or not.15:02
efriedNow we're automatically limited to the "implicit" aspects above, and I can be more comfortable overloading the existing unsuffixed required to subsume that meaning.15:02
efriedI still prefer adding a separate query param for it, because it is (at least in my head) cleaner.15:02
efried- It maintains the per-group vs. request-wide distinction crisply.15:02
efried- It moots weird edges like: If another (suffixed) request group is satisfied by the root, we have a weird bleedover when we calculate the root-y parts of the unsuffixed group, especially if group_policy=isolate.15:02
efried- Other things I would need to think about how to express. But maybe ^ is enough15:02
* cdent tries to digest15:04
cdentroot is always the part of the solution, and has always been in the way I think of it but you mean "things that 'give' to the solution"15:06
efriedright, things that satisfy any part of the actual query. Today (master) that always includes something to do with resources, which is why this isn't a thing yet (master).15:07
cdentgibi: you see all that ^15:09
cdentit might be too friday for me to think hard about this quickly15:11
efriedTL;DR:15:13
efried- If we keep to "solution path" I would be strongly opposed to overloading unsuffixed required. Like 95/515:13
efried- If we narrow to "ROOT is always included" I would be less opposed, but still much prefer a separate, explicitly request-wide rather than group-specific, query param.15:13
*** e0ne has joined #openstack-placement15:15
*** e0ne has quit IRC15:21
*** e0ne has joined #openstack-placement15:24
*** e0ne has quit IRC15:27
*** e0ne has joined #openstack-placement15:29
*** e0ne has quit IRC15:33
efriedcdent: before you leave, any chance you can conclude on ^ ?15:36
efriedcause I'd love to push a spec update and maybe even write some code (gasp)15:37
cdenti'll look again when I get home. in about 20 minutes. but I'm not making any guarantees.15:37
efriedight, thx15:37
cdentIf you're in a code writing way, it might be useful for you to do that, so there's something concrete for us to gaze over15:38
cdenthaving a few to throw away is fine and dandy15:38
*** cdent_ has joined #openstack-placement15:42
efriedack15:42
*** cdent_ has quit IRC15:43
*** cdent has quit IRC15:43
*** jaypipes has quit IRC15:51
*** cdent has joined #openstack-placement16:08
cdentefried: one more clarification/comment: you're proposing both root_required and root_member_of, yes? we should make sure to get tetsuro's thoughts on the latter because: http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004787.html .16:48
efriedyes I am proposing both, though it's possible we can get away without root_member_of for the nonce16:49
cdentI think at this point the right thing to do is try it.16:50
efriedcdent: Oh, good, that thread... has anything been implemented there yet?16:50
cdentBut when trying it, we need to make sure that we are super good about the tests, so that we are comparing and contrasting the right types of queries, not just...verification16:50
efriedCause if not, this would be a perfect answer, unified solution.16:50
cdentthat thread has a lot of useful stuff in it16:51
cdentsome of which we've managed to dismiss in our discussions16:52
efried"have done so in stein"?16:52
cdentaggregates flow down16:52
efriedargh16:53
cdentfrom the root16:53
cdentonly the root16:53
cdentthat's what that thread is saying16:53
cdentwe did it for root, should we do it for others16:53
efriedand that's implemented in master?16:53
efriedIMO we should (revert that and) implement root_member_of instead.16:53
cdentthat's what the thread says. you didn't go back and read like I assigned you. no gold star for you!16:53
efriedyeah, I've got a limited time with you now, I'll go read it once you've buggered off, easier for me just to ask.16:54
efriedI don't think we should have flow-down from anything to anything.16:54
efriedI think we should have "implicit root" for traits and aggregates16:54
efriedwhich satisfies same16:54
efriedIf we truly did implement that as a bugfix and not a microversion, perhaps we have the opportunity to revert it when we implement root_member_of16:55
efriedbut16:55
efriedwe could probably punt that conversation and just implement root_required initially16:55
cdentif I remember right, the fact that member_of already had that behavior was part of the draw of flow down (as discussed later in the thread) as well as make unsuffixed required be "root_required": grammatical (and other patterns) consistency as syntax limiting.16:57
cdenti'm already overdue, so I reckon: read that thread, have a think, implement root_required if you're feeling codey, and then we see where we're at. how much of a hurry do you feel we're in, from your perspective?16:58
efried...17:06
efried(sorry, I'm in a zillion places at once, if you don't tag me I take a while to get back here)17:06
efriedcdent: "hurry": I feel like we're in a reasonable hurry, because nova stuff depending on this isn't even going to get started until it's ready.17:07
efriedI feel like we could make the VGPU affinity thing disappear if we had this stuff ready soon enough17:07
cdentefried: okay. I wasn't trying to assert that weren't in a hurry, just trying to get a sense of what you're feeling. my "i reckon" above still stands. Especially the bit "implement" as I think it will be instructive17:09
efriedack17:09
* cdent waves17:13
*** cdent has quit IRC17:13
*** e0ne has joined #openstack-placement17:41
*** e0ne has quit IRC17:46
openstackgerritEric Fried proposed openstack/placement master: DNM: Separate mapping vs no-mapping code paths  https://review.opendev.org/66544818:23
*** e0ne has joined #openstack-placement18:42
*** Sundar has joined #openstack-placement18:56
*** e0ne has quit IRC19:16
*** e0ne has joined #openstack-placement19:16
*** e0ne has quit IRC19:21
*** e0ne has joined #openstack-placement19:23
*** e0ne has quit IRC19:33
openstackgerritEric Fried proposed openstack/placement master: Remove a redundant test  https://review.opendev.org/66546319:45
*** Sundar has quit IRC21:05
openstackgerritEric Fried proposed openstack/placement master: research_context._get_roots_with_traits()  https://review.opendev.org/66549122:55
openstackgerritEric Fried proposed openstack/placement master: WIP: Microversion 1.35: root_required  https://review.opendev.org/66549222:55
efriedcdent ^22:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!