Friday, 2019-03-22

*** mriedem_afk is now known as mriedem00:12
*** irclogbot_0 has joined #openstack-placement00:17
*** mriedem has quit IRC03:29
openstackgerritBoxiang Zhu proposed openstack/nova-specs master: Scheduler filters evaluated even forced host  https://review.openstack.org/64545803:30
openstackgerritBoxiang Zhu proposed openstack/nova-specs master: Scheduler filters evaluated even forced host  https://review.openstack.org/64545803:46
*** takashin has joined #openstack-placement06:10
*** david-lyle has joined #openstack-placement06:27
*** dklyle has quit IRC06:27
*** david-lyle has quit IRC06:29
*** dklyle has joined #openstack-placement06:29
*** dims has quit IRC06:39
*** dims has joined #openstack-placement06:41
*** takashin has left #openstack-placement07:30
*** ttsiouts has joined #openstack-placement08:13
*** helenaAM has joined #openstack-placement08:23
*** ttsiouts has quit IRC08:26
*** ttsiouts has joined #openstack-placement08:27
*** ttsiouts has quit IRC08:31
*** ttsiouts has joined #openstack-placement08:33
*** ttsiouts has quit IRC08:45
*** ttsiouts has joined #openstack-placement08:46
*** ttsiouts has quit IRC08:50
*** ttsiouts has joined #openstack-placement09:04
*** tssurya has joined #openstack-placement09:04
openstackgerritChris Dent proposed openstack/placement master: Initial structure for in-tree specs  https://review.openstack.org/64519509:07
*** ttsiouts has quit IRC09:21
*** ttsiouts has joined #openstack-placement09:22
*** ttsiouts has quit IRC09:26
*** ttsiouts has joined #openstack-placement09:44
*** cdent has joined #openstack-placement09:51
cdentpupdate: https://anticdent.org/placement-update-19-11.html10:40
*** ttsiouts has quit IRC10:42
*** ttsiouts has joined #openstack-placement10:43
*** ttsiouts_ has joined #openstack-placement10:48
*** ttsiouts has quit IRC10:48
*** ttsiouts_ has quit IRC11:54
*** ttsiouts has joined #openstack-placement11:55
*** ttsiouts has quit IRC11:59
*** ttsiouts has joined #openstack-placement12:09
*** altlogbot_2 has quit IRC13:01
*** irclogbot_0 has quit IRC13:01
*** altlogbot_1 has joined #openstack-placement13:02
*** irclogbot_1 has joined #openstack-placement13:02
*** dklyle has quit IRC13:07
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862913:11
*** dklyle has joined #openstack-placement13:12
*** ttsiouts has quit IRC13:20
*** ttsiouts has joined #openstack-placement13:21
*** ttsiouts has quit IRC13:26
openstackgerritChris Dent proposed openstack/placement master: Initial structure for in-tree specs  https://review.openstack.org/64519513:33
*** mriedem has joined #openstack-placement13:51
*** efried is now known as fried_rice13:58
fried_ricecdent: This has come up in my head several times while thinking about what the next enhancements to placement might "need to" be:14:19
cdentoh hi14:20
fried_riceperhaps it's time we reopen the idea of a GET /a_c that accepts a JSON request payload.14:20
fried_ricebasically, whatever we add to GET /a_c *next* is going to be super awkward to fit into querystring-ness.14:20
cdentit does seem like something that will happen someday and we can do it when someday comes14:21
cdentbut until then, why worry?14:22
cdentthe flip side of that is: the query string handling is a useful constraint that prevents us from writing war and peace when making a GET /a_c query, which helps keep that API better14:23
cdentyou're right that we will probably find a reason, eventually14:23
cdentbut your statement was a classic YAGNI14:23
cdent(especially given how much catch up with need to do from services that use placement)14:23
cdentwhich makes it sounds like I'm being all "no, don't think about that". I do think it is worth thinking about, just not doing (yet)14:24
edleafe"We'll burn that bridge when we come to it"14:26
cdentburn all the bridges14:27
fried_riceI agree we shouldn't just do it with the syntax we have today14:27
fried_ricewhat I'm saying is, everything that's "coming next" that I've pondered (e.g. subtree affinity) I can't think of a way to slot into querystring without it being really horrible.14:27
cdentin that vein I wish we could get some input from edge folk who talk about wanting partitioned placement. it's a thing on the radar too, but needs real info14:28
fried_ricewhereas when I start contemplating what it would look like in a JSON payload, I'm like, "oh, yeah, that makes sense and is pretty"14:28
cdentare you familiar with the phrase: "make it work then make it right" and its variants14:28
fried_ricemore or less.14:29
edleafeI would need to see the request that would be too cumbersome for a query string first14:29
cdentwhile you may not have had ideas on how to do it pretty in a query string, if you do it ugly, other people (and you too) can look at that concrete thing and say either "you could do that like X" or, conclusisvely and concretely "we need json for this"14:29
cdentyeah edleafe said it shorter14:29
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862914:30
fried_riceedleafe: Okay, for this particular example, I'm trying to express:14:35
fried_riceI want providers from group 3 (e.g. NUMA VCPU+MEMORY_MB) and group 4 (e.g. VGPU affined to same NUMA node) to come from the same subtree, and that sub-root is indicated $somehow, but14:35
fried_ricea) we don't want to hardcode it to something like "always one level down from the root"; and14:35
fried_riceb) we want it to be generic enough so that, if there are N subtrees that could satisfy, we don't have to build an N-component OR, especially since N could be different from one host to the next.14:35
fried_riceInitial thought is something like:14:37
fried_riceTag the subtree roots with a trait, e.g. NUMA_SUBTREE_STARTS_HERE. Importantly, the trait is the *same* for each numa subtree provider. (This gets us (b).)14:37
fried_riceProvide a syntax that says, "the resources from group numbers [...] should be satisfied by providers under a common NUMA_SUBTREE_STARTS_HERE"14:37
edleafefried_rice: I'm not able to visualize that request, so I can't suggest how it should be done. I would need to sit down and study the NUMA arrangements and corresponding trees to see what would work best14:37
fried_ricein querystring format, it would be something like:14:38
fried_ricecommon_subtree_required=NUMA_SUBTREE_STARTS_HERE&common_subtree_request_groups=3,414:38
fried_rice...assuming we only want to do it once per query. If more than once, we need to somehow number the new keys.14:38
fried_riceit also means promoting the request group numbers to first-class citizens in some sense.14:38
fried_ricewhich we've kind of started talking about doing to return the "which providers correspond to which request groups" metadata.14:39
fried_rice...whereas if we had a JSON request payload, we could do the grouping simply by wrapping the $trait(s) and $request_groups in a dict. Which would allow us to do multiple without awkward numbering, etc.14:41
fried_ricethinking about that ^ makes, like, my chest relax and I start breathing easier.14:41
cdenthave you considered that the difficulty you are having with your chest is an important signal, a true fear, which should not be ignored?14:41
cdentif the thing you are trying to do is making you sweat14:42
cdentmaybe it is wrong14:42
cdent(is only a bit serious)14:42
edleafethinking about any of this makes my head spin. It's difficult for me to conceive when a) I'm distracted by other work and b) I don't have an image in my head to work with14:42
fried_riceSure I've considered that cdent.14:42
cdentI think an email with some pretty drawings might help move the conversation along, IRC is unlikely to get anywhere14:43
cdentas I said in today's pupdate, I'm hoping we can have many of the conversations of the PTG nearly finished before we get to the PTG, otherwise none of them will finish14:43
cdentso we'll have to do email in advance14:43
cdentyou should put this topic on the ptg etherpad if you haven't already)14:44
fried_ricecdent: yeah, this is the inter-provider affinity thing. I haven't fleshed it out yet.14:51
cdentI figured that, but was saying if you wanted to put the general topic of "json body on request" on the agenda, the option is there14:52
*** Sundar has joined #openstack-placement14:53
fried_riceack14:55
fried_ricedid that14:57
cdentI have to edit inter-provider affinity to intra-provider affinity in my head15:05
cdentbecause it's all in one parent15:05
*** Sundar is now known as DarthNau15:14
*** altlogbot_1 has quit IRC15:21
*** altlogbot_1 has joined #openstack-placement15:26
*** irclogbot_1 has quit IRC15:30
*** irclogbot_2 has joined #openstack-placement15:32
*** irclogbot_2 has quit IRC15:36
*** irclogbot_1 has joined #openstack-placement15:38
fried_riceintra-tree, not intra-provider15:41
cdentright, I'm not saying it's right, just that I do it as a mental tweak to distinguish from inter-tree15:48
cdentintra-tree is maybe the best term for the thing you're actually wanting to do (assuming you're pursuing the limited scope plan)15:49
cdentbecause otherwise every time you say inter-provider people will have the same questions and concerns that I keep raising15:50
*** mriedem is now known as mriedem_afk16:07
*** helenaAM has quit IRC16:15
* cdent walkies16:19
fried_riceYeah, "subtree" is the best working title imo. Intra-tree is a superset, and the extras are weirdness I can't even come up with a scenario for.16:30
*** fried_rice is now known as fried_rolls16:30
*** e0ne has joined #openstack-placement16:48
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574916:52
*** e0ne has quit IRC16:59
cdentI think I'm tapped out, unless somebody has something lsat minute for me to care about?17:15
*** cdent has left #openstack-placement17:18
*** cdent has joined #openstack-placement17:24
*** cdent has left #openstack-placement17:24
*** tssurya has quit IRC17:30
openstackgerritKashyap Chamarthy proposed openstack/nova-specs master: Add "CPU selection with hypervisor consideration" spec  https://review.openstack.org/64581417:33
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574917:37
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574917:40
*** mriedem_afk is now known as mriedem17:55
openstackgerritMerged openstack/nova-specs master: Update Network Bandwidth resource provider spec  https://review.openstack.org/64481018:22
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574918:45
openstackgerritMerged openstack/nova-specs master: Update alloc-candidates-in-tree  https://review.openstack.org/63903319:01
*** fried_rolls is now known as fried_rice19:07
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574919:12
*** mriedem has quit IRC19:46
*** DarthNau has quit IRC19:46
*** mriedem has joined #openstack-placement19:47
*** e0ne has joined #openstack-placement21:54
*** e0ne has quit IRC22:36
openstackgerritmelanie witt proposed openstack/nova-specs master: Move Stein implemented specs  https://review.openstack.org/64574922:37
*** mriedem has quit IRC23:04
*** N3l1x has quit IRC23:34

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