| *** zzzeek has quit IRC | 00:47 | |
| *** zzzeek has joined #openstack-placement | 00:47 | |
| *** wwriverrat has quit IRC | 00:55 | |
| *** Sundar has quit IRC | 01:39 | |
| *** yikun has joined #openstack-placement | 01:56 | |
| *** zzzeek has quit IRC | 01:57 | |
| *** zzzeek has joined #openstack-placement | 01:58 | |
| *** zzzeek has quit IRC | 02:13 | |
| *** minmin has quit IRC | 02:16 | |
| *** zzzeek has joined #openstack-placement | 02:16 | |
| *** Sundar has joined #openstack-placement | 02:45 | |
| *** takashin has joined #openstack-placement | 03:32 | |
| *** yikun has quit IRC | 03:51 | |
| *** yikun has joined #openstack-placement | 04:03 | |
| *** e0ne has joined #openstack-placement | 05:51 | |
| *** e0ne has quit IRC | 06:22 | |
| *** Sundar has quit IRC | 06:40 | |
| *** gibi has joined #openstack-placement | 06:50 | |
| *** helenfm has joined #openstack-placement | 07:29 | |
| *** tetsuro has joined #openstack-placement | 07:30 | |
| *** ttsiouts has joined #openstack-placement | 07:57 | |
| *** e0ne has joined #openstack-placement | 07:57 | |
| *** takashin has left #openstack-placement | 08:01 | |
| *** guilhermesp has quit IRC | 08:01 | |
| *** guilhermesp has joined #openstack-placement | 08:03 | |
| *** tetsuro has quit IRC | 08:13 | |
| *** ttsiouts has quit IRC | 08:16 | |
| *** ttsiouts has joined #openstack-placement | 08:17 | |
| *** tetsuro has joined #openstack-placement | 08:19 | |
| *** ttsiouts has quit IRC | 08:21 | |
| *** ttsiouts has joined #openstack-placement | 08:24 | |
| *** tetsuro has quit IRC | 08:29 | |
| *** tetsuro has joined #openstack-placement | 08:30 | |
| *** tssurya has joined #openstack-placement | 08:35 | |
| *** tetsuro has quit IRC | 08:36 | |
| *** cdent has joined #openstack-placement | 08:58 | |
| cdent | gibi: if you're back and have the time there's quite a bit of interesting nested-related discussion/work going on that you'll probably want to catch up on when you get a chance. Also if you could kick this through if you have a chance that would be helpful: https://review.opendev.org/657463 | 09:03 |
|---|---|---|
| openstackgerrit | Merged openstack/placement master: Correctly limit provider summaries when nested https://review.opendev.org/664594 | 09:45 |
| *** ttsiouts has quit IRC | 10:05 | |
| gibi | cdent: ack. | 10:59 |
| cdent | thanks | 11:00 |
| gibi | cdent: I'm back so I will catch up | 11:00 |
| cdent | the discussion on the nested magic 1 spec is pretty interesting | 11:00 |
| *** ttsiouts has joined #openstack-placement | 11:01 | |
| openstackgerrit | Chris Dent proposed openstack/placement master: Add a blocker migration for missing consumer records https://review.opendev.org/664627 | 11:12 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Remove incomplete consumer inline migrations https://review.opendev.org/664858 | 11:12 |
| * cdent airport runs | 11:52 | |
| openstackgerrit | Balazs Gibizer proposed openstack/placement master: DNM: Visualize RP trees in gabbit fixtures https://review.opendev.org/664878 | 12:41 |
| cdent | gibi: https://github.com/gibizer/osc-placement-tree is awesome | 13:14 |
| cdent | maybe we should consider putting that in osc-placement proper? Or at least release it to pypi | 13:23 |
| *** artom has quit IRC | 13:29 | |
| *** dklyle has quit IRC | 13:34 | |
| gibi | cdent: I can definitly try to release it to pypi. do you have a good description how to do that? (this will be my first package on pypi) | 13:37 |
| cdent | gibi: one sec, looking for something | 13:37 |
| cdent | gibi: https://packaging.python.org/ is the canonical source of info | 13:39 |
| cdent | but mostly what you're after is 'python setup.py sdist bdist_wheel' and then 'twine upload' | 13:39 |
| gibi | cdent: pulling it to osc-placement can also be done I guess. But it is already an oppinionated repo. For example it is using black from the start | 13:40 |
| gibi | cdent: thank. I will read up | 13:40 |
| cdent | (black from the start)++ | 13:40 |
| *** mriedem has joined #openstack-placement | 13:49 | |
| cdent | efried: were you wanting to office hours chat this afternoon (in an hour). I can if required, but if not I have some other stuff I need to do (my sister's luggage didn't arrive, she needs to shop before moving on to another destination) | 14:06 |
| cdent | mriedem: I unwipped the ensure consumer blocker | 14:08 |
| mriedem | ok | 14:09 |
| mriedem | feels like we should have a reno in here somewhere... | 14:10 |
| mriedem | although, 'make sure you run your online data migrations' is already a thing | 14:11 |
| mriedem | and this one really should have been done before using extracted placement from nova anyway | 14:11 |
| mriedem | i think it was added to nova in...rocky? | 14:11 |
| mriedem | yeah https://github.com/openstack/nova/blob/stable/rocky/nova/cmd/manage.py#L416 | 14:12 |
| cdent | mriedem: yeah, that was the same logic I followed when not reno-ing | 14:13 |
| mriedem | +2 on both | 14:19 |
| cdent | thanks | 14:19 |
| * cdent is cruising through TODO/NOTE/FIXME looking for opportunities | 14:20 | |
| mriedem | i've got a question for you before proceeding, on https://review.opendev.org/#/c/657016/ | 14:21 |
| mriedem | i think the change itself is sound, the only hangup is the assertion in the commit message that if we fail to delete any providers that we'll stop and not delete the service, | 14:22 |
| mriedem | so i just need to fix that wording - since fixing the other thing is a different change IMOM | 14:22 |
| mriedem | *IMO | 14:22 |
| mriedem | cdent: do you agree? | 14:22 |
| mriedem | as noted inline, i've got a functional test recreating the "provider delete failed, compute service was still deleted" mess https://review.opendev.org/#/c/663737/ | 14:22 |
| cdent | mriedem: yeah, I think that's fine. | 14:26 |
| cdent | you're making things better, even though not perfect | 14:26 |
| cdent | so, win | 14:27 |
| *** ttsiouts has quit IRC | 14:27 | |
| mriedem | i believe the fix is we check if any provider for the service has allocations and if so we bail | 14:28 |
| efried | cdent: Yes, I was assuming we would try to make progress as a group on "flow down" etc. | 14:28 |
| *** ttsiouts has joined #openstack-placement | 14:28 | |
| mriedem | that would include currently running instances, unconfirmed migrations and evacuated instances that aren't cleaned up | 14:28 |
| cdent | efried: okay, I'll to situate myself appropriately, but may be slightly late depending on traffic | 14:30 |
| efried | cdent: That's assuming it'll be more than just you & me. If others don't show up to office hours, then we can have that chat any time. | 14:31 |
| cdent | as usual, I've left yet more questions in response on the magic 1 spec | 14:31 |
| efried | I'm responding to your response | 14:32 |
| * cdent plans to respond to your response to my response to your response ... | 14:32 | |
| cdent | bbs | 14:32 |
| *** cdent has quit IRC | 14:32 | |
| *** ttsiouts has quit IRC | 14:32 | |
| * gibi will be here for the office hour | 14:33 | |
| *** dklyle has joined #openstack-placement | 14:45 | |
| *** tetsuro has joined #openstack-placement | 14:46 | |
| *** ttsiouts has joined #openstack-placement | 14:47 | |
| efried | tetsuro: o/ You sticking around for office hours? | 14:56 |
| tetsuro | Yes I am | 14:56 |
| efried | ++ | 14:56 |
| openstackgerrit | Merged openstack/placement master: Add NUMANetworkFixture for gabbits https://review.opendev.org/657463 | 14:58 |
| gibi | o/ | 14:59 |
| efried | Hi gibi. edleafe, are you going to hang with us? | 14:59 |
| efried | cdent is on the road, but I think is trying to get back pretty shortly. | 15:00 |
| gibi | yes, I'm here | 15:00 |
| efried | Is everyone more or less caught up on the major issue of the day? | 15:00 |
| edleafe | I is here | 15:01 |
| edleafe | And that issue would be... ? | 15:01 |
| gibi | I got back from a long weekend today so I'm not up to speed on the nested magic thing yet | 15:01 |
| efried | Okay, the issue is that we have several use cases coming from nova that we're trying to address in the scope of the nested magic work, and the edges are really messy. | 15:02 |
| *** artom has joined #openstack-placement | 15:02 | |
| efried | especially if we try to address them in a way that's not completely nova-centric | 15:03 |
| *** cdent has joined #openstack-placement | 15:04 | |
| efried | For example, how do we add a component like "make sure I don't land on a WINDOWS_LICENSED host" to a request for other resources/traits/aggregates in such a way that it comes out the way we want/expect, whether our host is modeled flat or nested? | 15:04 |
| efried | o/ cdent | 15:04 |
| cdent | ahoy | 15:05 |
| efried | for now let's assume the above needs to be handled with a forbidden trait | 15:05 |
| efried | due to potential nesting of host, we can't guarantee that any resources will actually come from the root RP | 15:05 |
| efried | but the root RP is where the WINDOWS_LICENSED trait would be if it was present. | 15:05 |
| efried | "intuitively" I could add required_$UNIQUE=!WINDOWS_LICENSED (by _$UNIQUE I'm saying this request group isn't used for anything else) | 15:07 |
| * edleafe loses interest | 15:08 | |
| edleafe | It's a simple query in Neo4j: | 15:08 |
| edleafe | MATCH (root:RESOURCE_PROVIDER)-[*]->(rp:RESOURCE_PROVIDER)-[:PROVDES]->(:MEMORY_MB) | 15:08 |
| edleafe | WHERE not exists(root.WINDOWS_LICENSED) | 15:08 |
| edleafe | But I'm sure you're all sick of hearing that | 15:09 |
| efried | yes edleafe, it's just as simple a query in the existing established database structure | 15:09 |
| efried | That's not the point | 15:09 |
| efried | The point is that it confers a particular meaning to a "resourceless request group with a forbidden trait" | 15:09 |
| cdent | can we back up slightly | 15:09 |
| efried | which might be worded as "must not exist anywhere in the tree surrounding the providers that actually contribute resource to the request" | 15:09 |
| cdent | sorry for arriving late, was in a car | 15:09 |
| edleafe | My point is that you don't need to jump through the "resourceless request group" hoops | 15:10 |
| edleafe | BUt I'll shut up | 15:10 |
| gibi | can we assume that the client knows that WINDOWS_LICENSED traits is always on the root RP? | 15:10 |
| cdent | why "required_$UNIQUE=!WINDOWS_LICENSED" instead of "required=!WINDOWS_LICENSED"? | 15:10 |
| cdent | I ask this because I continue to think that efried's interpretation of "the solution is incorrect" | 15:11 |
| cdent | we are not askign for providers | 15:11 |
| cdent | we are asking for allocatation candidates | 15:11 |
| cdent | an allocation candidate is made up of a set of providers which satisfy the request | 15:11 |
| efried | right, I'm guessing you haven't had time to read the response to your response that I responded to mere minutes ago | 15:11 |
| cdent | no, I just did | 15:11 |
| cdent | and is why I'm bring it up. I still disagree with you. | 15:11 |
| cdent | your state about today's definition is wrong | 15:12 |
| efried | the part I have trouble with isn't "the set of providers which satisfy the request". The part I have trouble with is how that definition would *not* incorporate "bad cousins". | 15:12 |
| cdent | but we dont' want bad cousins, so what's wrong? | 15:12 |
| efried | the definition "set of providers which satisfy the request" would include them. | 15:13 |
| cdent | no, it does not | 15:13 |
| cdent | because they don't satisfy the request | 15:13 |
| cdent | a bad cousin is external to the set of providers | 15:13 |
| cdent | by its very nature of being a cousin | 15:13 |
| efried | so is a root node that doesn't provide any resource | 15:13 |
| cdent | there is no path to it in the graph | 15:13 |
| cdent | a root node is include because it is an ancestor of something that does provide | 15:14 |
| efried | ^ this | 15:14 |
| efried | is where my problem lies | 15:14 |
| *** amodi has joined #openstack-placement | 15:14 | |
| efried | That has always struck me as a completely arbitrary definition/distinction. | 15:14 |
| efried | but | 15:14 |
| cdent | which "that" | 15:14 |
| cdent | please explain deeper the why | 15:14 |
| efried | "a (root) node is included because it is an ancestor of something that does provide [resource]" | 15:15 |
| edleafe | IMO, the root *is* the resource provider | 15:16 |
| *** Sundar has joined #openstack-placement | 15:16 | |
| cdent | when you ask for allocation candidate the thing that you are asking for is a target | 15:16 |
| cdent | the root is the target | 15:16 |
| cdent | so it _has_ to matter | 15:16 |
| edleafe | jinxish | 15:16 |
| cdent | yes | 15:16 |
| efried | what about intervening ancestors that aren't the root? | 15:16 |
| cdent | the root is where the workload lands | 15:16 |
| cdent | they matter too | 15:16 |
| efried | why??? | 15:17 |
| cdent | because they are on the path | 15:17 |
| cdent | whether we use a graph db or not, a nested provider is _nested_ | 15:17 |
| cdent | it's a graph | 15:17 |
| cdent | from the root to the leaves, all those providers are what we are "getting" | 15:17 |
| efried | um | 15:17 |
| gibi | if a nested RP cannot exists without it ancestorts then I think it is fair to include them in the result | 15:17 |
| efried | look | 15:18 |
| efried | I accept that this will solve our (nova-centric) use cases in a tidy way. | 15:18 |
| efried | So rather than arguing until the definition makes sense in my head, which it may never do, let's just accept that I am able to comprehend it and move on. | 15:18 |
| efried | as long as we effect this change (and let's be clear: it is a change) in a new microversion | 15:18 |
| cdent | I _really_ want to understand what your issue is here, because as far as I can tell this is making sense to everyone but you, and since you're a critical piece of the pie, I'd like to reach a more complete understanding | 15:18 |
| cdent | because I still don't understand your objection, other than arbitrariness, and I'm pretty sure your position is arbitrary++ | 15:19 |
| cdent | I think if we can clarify it, we'll achieve something closer to a tao or zen of nested | 15:19 |
| cdent | it's right there in the name | 15:19 |
| cdent | _nested_ | 15:20 |
| efried | oh, careful there, lest we start conferring meaning to things based on the name we chose for them (cf. "traits") | 15:20 |
| cdent | if you're willing to just accept it, I guess that can be fine, but I don't like it. I nearly failed calculus out of stubborness against that kind of thing | 15:20 |
| efried | It may just be that I have a looser notion of the binding that tree-ness imbues. | 15:20 |
| cdent | we chose the name on purpose to mean hierarchical containership. if you're opposed to that hierarchy and that containment, that's the problem that needs to be fixed | 15:21 |
| gibi | so far we only have examples where a nested RP means a hard containment | 15:21 |
| cdent | sounds like it, and you need to disabuse yourself of that | 15:21 |
| efried | or the fact that I don't accept it as meaningful to say "give me an SRIOV VF that supports MULTI_ATTACH" | 15:21 |
| cdent | you're not askign for that | 15:21 |
| efried | "on a host that supports..." is a different query, to me. | 15:21 |
| cdent | you're asking for a target that support MUTLI_ATTACH that also have an SRIOV_VF | 15:22 |
| cdent | that is the _only_ query | 15:22 |
| cdent | that's what placement does | 15:22 |
| cdent | again it's in the name | 15:22 |
| cdent | and while it could be more than that | 15:22 |
| efried | Yes. And we don't have a syntax that indicates "a target" | 15:22 |
| cdent | we don't want it to be | 15:22 |
| cdent | we have a fast path to the target with root_provider_uuid | 15:22 |
| efried | cool, I can get behind making the root implicit. But that doesn't account for the intervening non-root ancestors (in my head) | 15:23 |
| cdent | that we have a weird syntax is actually outside the original model. Originally it was just "show some resource providers", allocation candidates evolved organically and has warts as a result, but it would be good not to have those warts change the meaning of the system | 15:24 |
| gibi | efried: the SRIOV_VF resides inside the target (the root) to find it you need a path of RPs | 15:24 |
| cdent | what gibi said | 15:24 |
| cdent | it's a topology | 15:24 |
| cdent | and it's members provide meaning in various ways | 15:25 |
| * edleafe is biting my tongue about graphs | 15:25 | |
| * cdent sews up edleafe's mouth for the time being | 15:25 | |
| efried | I'm not going to fail calculus, cdent. I understand the concept here. I don't agree with it, but I don't need to. That's what consensus is. | 15:25 |
| cdent | I wish you did agree, or we could get you there, because the more we talk about it the more I think you've got an entirely different model for how things _should_ work from many other people, and that's going to cause hiccups | 15:26 |
| efried | Maybe some day I will. But for now, let's make progress. | 15:26 |
| gibi | in my head we cannot consume an SRIOV_VF without knowing, and accepting the properties of the full topology leading to the SRIOV_VF | 15:26 |
| cdent | not only what gibi said, but also, at least to me thinking of it and using it as a toplogy makes it easier to grasp how the system works | 15:27 |
| cdent | okay, so we have an emerging consensus, can we state it? | 15:27 |
| efried | "A resource provider implicitly accumulates the traits and aggregates of its ancestors" | 15:29 |
| efried | ? | 15:29 |
| cdent | s/resource/nested resource/ | 15:30 |
| tetsuro | I'm not sure we can achieve it with microversion without performance degradation | 15:30 |
| cdent | s/ancestors/ancestors because nested implies a hierarchy of containership/ (or something more clear than that) | 15:30 |
| efried | "An 'allocation candidate' (a) explicitly includes providers providing resources to the request; and (b) implicitly includes all linear ancestors of those in (a)." | 15:31 |
| cdent | s/An/Finding an/ | 15:31 |
| edleafe | efried: that sounds upside down to me | 15:31 |
| efried | edleafe: how so? | 15:32 |
| tetsuro | If nova wants trait flow down feature, alternatively why not have inherit option in create rps API? | 15:32 |
| tetsuro | openstack resource provider create <rp_name> --inherit_traits | 15:32 |
| edleafe | A request is for a cloud resource - for Nova that would be a compute node | 15:32 |
| tetsuro | and recursive option in set trait API? | 15:32 |
| cdent | tetsuro: I think that's an option, but not a very elegant one, given what we've said about about hierarchy and containership | 15:32 |
| edleafe | How the various resources are contained within it is a detail of the allocation | 15:32 |
| cdent | edleafe: that's why I made the "Finding an" edit | 15:33 |
| efried | tetsuro: I think we should defer talking about how to implement until we've defined and shown how it addresses use cases | 15:33 |
| edleafe | cdent: yeah, another jinxish message | 15:33 |
| efried | I'm still unclear how we will define the behavior of suffixed resourceless with required or forbidden traits | 15:34 |
| cdent | tetsuro: another thing to look into is seeing if there is any real extant use case we break by making these adjustments. I don't think there's much _real_ "nested" out there in the world yet. And it _might_ be fair to make some adjustments outside the usual process | 15:34 |
| efried | I'm way opposed to ^ | 15:34 |
| cdent | but yeah, agree we should postpone inmplementation discussion | 15:34 |
| cdent | efried: yet nothing is broken, ye4t | 15:34 |
| cdent | we _think_ we have some legacy to support but that's simply not true | 15:35 |
| cdent | and we _think_ we are breaking a bunch of stuff but there's no evidence to support that assertion | 15:35 |
| cdent | so let's keep it in the box of options | 15:35 |
| efried | cdent: This is broken: https://review.opendev.org/#/c/657510/7/placement/tests/functional/gabbits/granular-resourceless.yaml@20 | 15:35 |
| efried | but yeah, let's defer that discussion too. | 15:36 |
| cdent | that test was _written_ broken | 15:36 |
| cdent | we're trying to fix it with this discussion | 15:36 |
| efried | the test succeeds with "flow down" but fails without it. | 15:36 |
| efried | let's defer please | 15:36 |
| cdent | [t dK28] | 15:37 |
| purplerbot | <efried> I'm still unclear how we will define the behavior of suffixed resourceless with required or forbidden traits [2019-06-12 15:34:08.065833] [n dK28] | 15:37 |
| efried | Yes: | 15:37 |
| efried | Can someone explain to me what the meaning of | 15:37 |
| efried | required_$UNIQUE=FOO | 15:37 |
| efried | would be, and how the definitions above incorporate that meaning (or are extended to do so) | 15:37 |
| efried | ? | 15:37 |
| efried | (spoiler, next will be !FOO) | 15:37 |
| efried | [Aside: I'm suffering from several injuries of varying degrees at the moment. Apologies if pain+meds are making me dumber and/or grumpier than usual. (Yeah, yeah, you hadn't noticed, blah blah)] | 15:38 |
| tetsuro | If traits flow down, that means there exists a provider that has FOO in the tree. If traits don't flow down, same. | 15:39 |
| efried | "in the tree"? | 15:39 |
| efried | So like, anywhere in the tree? | 15:39 |
| tetsuro | anywhere in the tree | 15:39 |
| efried | Not limited to the providers satisfying the rest of the request? | 15:39 |
| cdent | you're likely using "tree" differently | 15:39 |
| efried | ...or their ancestors? | 15:40 |
| cdent | within the code there is a concept of a "tree" which is not the entire tree from root | 15:40 |
| efried | there is? | 15:40 |
| cdent | in the implementation, yes | 15:40 |
| efried | wow | 15:40 |
| efried | I was totally unaware of this | 15:40 |
| cdent | it's why implement resource hacks was so "easy" | 15:40 |
| gibi | each returned candidate needs to have a provider in it that has the trait FOO (it is implicit that each candidate needs to consist of a single tree + sharing PRs) | 15:41 |
| cdent | the internal concept of tree is how we are able to get different sets of candidates from the same target | 15:42 |
| cdent | a tree is a description of the path through from root that provides a solution | 15:42 |
| efried | when we're talking about "within the code" and "in the implementation" we're talking about stuff in the actual master branch, not including things proposed-but-not-merged | 15:43 |
| cdent | yes | 15:43 |
| efried | okay, because my perception of how that works has nothing to do with tracing paths up trees | 15:43 |
| efried | it has to do with collecting all the providers in the (whole) tree and then filtering down to the ones that satisfy the request. | 15:43 |
| cdent | mathwise, that's really the same thing | 15:44 |
| cdent | which is perhaps where I'm adding confusion to this discussion | 15:44 |
| cdent | in any case, we're veering | 15:45 |
| efried | it may be possible to do a formal mathematical proof that demonstrates that the result is the same. But the process/formula is different. | 15:45 |
| edleafe | Mathwise, maybe, but certainly not concept-wise | 15:45 |
| efried | edleafe++ | 15:45 |
| edleafe | Another jinxish! | 15:45 |
| efried | but yes, we are veering. | 15:45 |
| cdent | the point I was trying to make was that it seemed like tetsuro and efried were potentially meaning different things with "anywhere in the tree", a critical difference | 15:45 |
| efried | yes, we definitely need to nail that down. | 15:46 |
| cdent | for efried "anywhere in the tree" includes bad cousins | 15:46 |
| efried | yes | 15:46 |
| cdent | for me (and maybe tetsuro, not sure?) it does not | 15:46 |
| efried | for the code, it would also include bad cousins | 15:46 |
| cdent | maybe for master | 15:46 |
| efried | the code as it stands today | 15:46 |
| efried | yes | 15:46 |
| cdent | but not for the hack I did yesterday | 15:46 |
| tetsuro | for me "anywhere in the tree" includes bad cousins :) | 15:46 |
| cdent | ah okay, good to know | 15:47 |
| edleafe | I think that the "tree" notion is misleading. Only some branches are involved in an allocation candidate, not the entire tree | 15:47 |
| edleafe | (which is why the graph approach works out more cleanly) | 15:47 |
| efried | yes, can we start using another term when we're talking about the subset of the tree (ascending to the root) that provides the solution? | 15:47 |
| Sundar | Sorry for jumping in the middle. I just caught up (I think). "traits flow down" - this makes no sense to me. If the compute node has a trait like AVX512, that doesn't mean the nested RPs (e.g. devices) have that instruction support. | 15:48 |
| cdent | can we call it "solution" or "solution tree" versus "provider tree"? | 15:48 |
| edleafe | I'd prefer "path" | 15:48 |
| cdent | path is fine too | 15:48 |
| efried | as long as we accept that it allows for branching | 15:48 |
| *** helenfm has quit IRC | 15:48 | |
| efried | but only in one direction | 15:48 |
| edleafe | of course | 15:48 |
| cdent | Sundar: when we talk about this stuff we're not talking about whether the provider has the thing, but whether it is in a solution that has it available | 15:49 |
| edleafe | efried: heh, now you're sounding like a graph proponent :) | 15:49 |
| cdent | so if I ask for an SRIOV_VF and AVX512 the SRIOV doesn't have AVX512 but the compute node does | 15:49 |
| cdent | "the compute node" is "the target" | 15:50 |
| edleafe | Sundar: another way to look at it is that every RP doesn't have to have that trait, but it does need to be present | 15:50 |
| cdent | using the new term it's whether AVX512 is in the "path" | 15:50 |
| cdent | so: what is the relationship between a "path" and bad cousins? | 15:52 |
| efried | right, so to me required_$UNIQUE=FOO "intuitively" means "include a provider in the solution path that has FOO" | 15:52 |
| efried | which tetsuro and I think means "regardless of anything else that's happening in the solution path" | 15:52 |
| efried | i.e. required_$UNIQUE=FOO is *augmenting* the solution path | 15:52 |
| edleafe | I believe you've defined "bad cousins" as having a common root, but not on the path | 15:52 |
| *** ttsiouts has quit IRC | 15:53 | |
| cdent | edleafe: yes, that's what I think, I'm not sure it is mutally agreed | 15:53 |
| *** ttsiouts has joined #openstack-placement | 15:53 | |
| efried | What we're trying to find a way to say is: | 15:53 |
| efried | required_$UNIQUE=FOO needs to apply as a filter affecting the solution path as determined by the *other* pieces of the request | 15:53 |
| edleafe | I think "bad" is not a good description. At most, they're irrelevant | 15:54 |
| gibi | in the containmentship view a forbidden trait means that your solution should never enter a container that has the forbidden property | 15:54 |
| gibi | like you never touch a NUMA node with bad smell | 15:55 |
| edleafe | I never touch NUMA nodes regardless of their odor | 15:55 |
| cdent | efried: I think that's kind of the nature of request groups already, yes: we do them in what amounts to a kind of order | 15:55 |
| efried | today we don't | 15:56 |
| efried | the only thing that's "ordered" is we do "isolate" as a late filter. | 15:56 |
| efried | other than "isolate", request groups don't interact with each other | 15:56 |
| efried | (except for having to land in the same tree) | 15:56 |
| efried | what we're trying to find a way to express now is a change to that concept | 15:57 |
| efried | "use the information from this request group to affect what's allowed to be returned from other request groups" | 15:57 |
| cdent | brb | 15:58 |
| *** ttsiouts has quit IRC | 15:58 | |
| edleafe | One last thing before we end... | 15:59 |
| edleafe | I just want to let everyone know that I've been "resource actioned" (IBM speak for "laid off"), with my last day in early September. So I most likely won't be around after that. | 15:59 |
| cdent | meh to that... | 16:00 |
| gibi | edleafe: that is sad :( | 16:00 |
| Sundar | edleafe: Tough | 16:00 |
| edleafe | Thanks everyone. Now if you hear of any openings... :) | 16:00 |
| efried | edleafe: Sorry to hear that | 16:01 |
| efried | Do we need to "end"? Seems like we have made progress, but there's a lot more to close on. Can folks stick around? | 16:02 |
| cdent | yeah, I can still be here. this seems to be where we are [t dxjE] | 16:02 |
| purplerbot | <efried> "use the information from this request group to affect what's allowed to be returned from other request groups" [2019-06-12 15:57:49.494855] [n dxjE] | 16:02 |
| edleafe | I was thinking of those in timezones where the clock is later | 16:03 |
| cdent | that's what [t 13xo] does | 16:03 |
| purplerbot | <efried> "A resource provider implicitly accumulates the traits and aggregates of its ancestors" [2019-06-12 15:29:22.501625] [n 13xo] | 16:03 |
| cdent | because it is not request groups influencing each other | 16:03 |
| cdent | it's each request group having more to look at/think about | 16:03 |
| efried | You're going to have to help me understand how that works (again). | 16:04 |
| cdent | (for traits and aggregates, but not inventory) | 16:04 |
| cdent | the set of resource providers is that satisfies (independent of other things) required_$UNIQUE=FOO is all those providers which have trait foo, or an ancestor with trait FOO (which will sometimes be a huge set) | 16:06 |
| cdent | that set is winnowed during the equivalent of _merge_candidates | 16:06 |
| efried | Right - ^ doesn't include in its definition "that satisfy other parts of the request" | 16:06 |
| efried | root R has two children, A(rc:X, trait:FOO) and B(rc:X, trait:BAR) | 16:07 |
| efried | If I ask for ?resources=X&required_1=FOO | 16:07 |
| efried | the required_1=FOO part is saying "all those providers which have trait FOO, or an ancestor with trait FOO" | 16:07 |
| cdent | there are a variety of ways to optimize that. one of them is to do a "late" trait check | 16:07 |
| cdent | so you get back R A as the result path | 16:08 |
| efried | ...which will get me solution paths | 16:08 |
| efried | - A(X, FOO) | 16:08 |
| efried | - A(FOO), B(X) | 16:08 |
| efried | the B(X) satisfies required_1=FOO | 16:08 |
| cdent | how? it ha not ancestor with FOO | 16:08 |
| efried | agh, sorry, disregard | 16:08 |
| efried | The A(FOO) satisfies required_1=FOO | 16:08 |
| efried | let me be more complete | 16:09 |
| * cdent waits for an EOF | 16:09 | |
| cdent | (while that's percolating, it would be great if gibi and tetsuro could write down somewhere their own take on this stuff, because it feels like this discussion and has been the chris and eric show and I think it's likely the case that tetsuro and gibi understand some of these things if not better, at least differently and we need to incorporate that) | 16:11 |
| gibi | (I'm slower than you guys, I will try to sum my view in the review) | 16:13 |
| tetsuro | Whether we go with and without trait flow down feature we will get A(FOO), B(X), in that example, I think? | 16:14 |
| cdent | tetsuro: can you explain why, because to me that makes no sense | 16:15 |
| efried | tetsuro: ++ | 16:15 |
| efried | without additional definitionizing, using "the set of resource providers is that satisfies (independent of other things) required_$UNIQUE=FOO is all those providers which have trait foo, or an ancestor with trait FOO" | 16:15 |
| efried | with provider tree root R() with two children, A(rc:X, trait:FOO) and B(rc:X, trait:BAR) | 16:15 |
| efried | with request ?resources=X&required_1=FOO | 16:15 |
| efried | will result in two solution paths: | 16:15 |
| efried | :1: R(), A(X, FOO) | 16:15 |
| efried | :2: R(), A(FOO), B(X) | 16:15 |
| efried | In :1:, A(X, FOO) satisfies both resources=X and required_1=FOO; and R() is included by virtue of being an ancestor of A | 16:15 |
| efried | In :2:, B(X) satisfies resources=X; A(FOO) satisfies required_1=FOO; and R() is included by virtue of being an ancestor of both A and B | 16:15 |
| efried | What (I think) we are trying to do is contrive a definition such that the request will result in *only* solution path :1:. I don't know how we're going to do that. | 16:15 |
| efried | EOM | 16:15 |
| Sundar | cdent: I am interested in the device colocation use case -- wherein a device has multiple components, each component is a RP with its own RCs and traits, and there could be multiple such devices on the same compute node. The use case is that all resources for a VM should come from the same device (co-located), not different devices in the same node | 16:15 |
| cdent | thanks efried | 16:15 |
| cdent | Sundar: can we come back to that a bit later? | 16:16 |
| * cdent digests efried | 16:16 | |
| * efried finds stronger pain meds while cdent digests him | 16:16 | |
| * Sundar wonders how efried will exit cdent after the digestion | 16:17 | |
| cdent | hmm. I still don't understand 2. There is a path R -> B. Nowhere in that path is FOO so that is not a solution path. If FOO were on R and traits flowed down, then both R->B and R->A would be solution paths. | 16:19 |
| cdent | In 2 B isn't even a "bad cousin", it's simply irrelevant | 16:19 |
| efried | I made it relevant when I asked for required_1=FOO | 16:20 |
| efried | iow | 16:20 |
| efried | in today's definition, required_1=FOO has nothing to do with resources=X | 16:20 |
| efried | we're trying to contrive a definition where we're saying that the required_1 and the resources=X have to affect each other | 16:21 |
| cdent | you keep saying that, and I still think that's backwards | 16:21 |
| edleafe | Traits are applied to RPs that have the necessary resources | 16:21 |
| cdent | the set of providers for which required_1=FOO is true is A | 16:21 |
| cdent | the set of provider for which resources=X is A, B | 16:22 |
| cdent | the intersection is A | 16:22 |
| efried | In this request | 16:22 |
| efried | ?resources=X&required_1=FOO | 16:22 |
| efried | I'm saying: | 16:22 |
| efried | Give me a solution path which includes two things: | 16:22 |
| efried | - A resource provider that can provide X | 16:22 |
| efried | - A resource provider that has FOO | 16:22 |
| cdent | A's ancestor is R, so R A | 16:22 |
| efried | which means there are two possibilities | 16:22 |
| efried | :1: a permutation where both bullets are satisfied by the same provider | 16:22 |
| efried | :2: a permutation where a separate provider satisfies each bullet | 16:22 |
| efried | this is, as tetsuro said, regardless of traits flowing anywhere. | 16:23 |
| * cdent chews again | 16:23 | |
| efried | looklook, maybe this helps, let's talk about master, where there are no resourceless request groups and there is no flowing | 16:25 |
| efried | ?resources1=X | 16:25 |
| efried | &resources2=A&required2=B | 16:25 |
| efried | The required2=B does not influence which solution paths involve X resources | 16:25 |
| cdent | in a nested tree R with children A and B, for any request the potential solution trees are R->A, R->B and R->A&B, yes? | 16:25 |
| efried | yes | 16:25 |
| * cdent keeps chewing | 16:26 | |
| tetsuro | R(resource:X) with children A(resource:Y) and B(resource:Y); If we ask ?resource1=Y&resource2=Y&group_policy=none It has 3 alloc_reqs [(A), (B), (A, B)] | 16:30 |
| tetsuro | FWIW | 16:31 |
| gibi | I feel one level of confusion in me is because traits are attached to RPs but we consume resources so I my brain shortcut it to traits-defining-properties-of-resources-we-consume | 16:31 |
| efried | good summary of why traits-flow-down doesn't make sense to me without additional definitions of "and we're implicitly including this host" ^ | 16:32 |
| efried | but let's not get off on that tangent again | 16:32 |
| efried | tetsuro: Yes, I think that example holds now (master) and in any conceivable future. I don't think any decisions we're talking about would change it. | 16:33 |
| cdent | I'm going to be called off to dinner very soon. | 16:33 |
| cdent | I'm trying to discern if we've confused everything, or reached some clarity on some points | 16:34 |
| Sundar | In efried's example, for the request ?resources1=X&required_2=FOO, if there is one RP that satisfies both, should we return that alone? Or should we return 2 different RPs? -- That is the question, right? | 16:34 |
| efried | Sundar: Yeah | 16:35 |
| efried | 2 different *candidates* (or solution paths) | 16:35 |
| Sundar | That would depend on the group_policy, one would think | 16:35 |
| efried | well, since you brought it up, | 16:36 |
| cdent | oh dear | 16:36 |
| efried | resources1=X&required2=FOO | 16:36 |
| efried | with group_policy=none would return the two candidates I listed above :1: and :2: | 16:36 |
| efried | with group_policy=isolate would return *only* :2: !! | 16:36 |
| efried | (which, reminder, is the one we actually want to get rid of for this use case) | 16:37 |
| cdent | if you asked for resources1=X&required2=FOO&group_policy=isolate, getting (only) two candidates would be the correct result, albeit not likely what you wanted | 16:39 |
| cdent | sorry I mean only the second candidate option | 16:39 |
| * cdent is brain hungry | 16:39 | |
| efried | To summarize this issue: | 16:40 |
| efried | Today (master) request groups don't influence each other. | 16:40 |
| efried | We're looking for a syntax that says "late-filter candidates derived by existing master-ish code paths such that they include only solution paths containing trait FOO" | 16:40 |
| efried | And thus far we've been trying to make resourceless+required satisfy that | 16:40 |
| efried | But I haven't figured out a unifying definition that makes that ^ make sense | 16:40 |
| efried | And perhaps we should consider a late_check_solution_path_required=FOO instead | 16:40 |
| cdent | which suggests: can we just say the original proposition is a bad request? That is, what is the request form that gets the results we want? | 16:41 |
| efried | yes, let's start looking from that angle | 16:41 |
| cdent | which is X and FOO in the same group, yes? | 16:41 |
| efried | "in the same solution path" | 16:42 |
| efried | uh | 16:42 |
| efried | let me try to state it differently: | 16:42 |
| * gibi needs to drop soon | 16:42 | |
| cdent | i mean in the same query: resources=X&required=FOO -> A | 16:42 |
| efried | FIRST: find me solution paths that provide resources=X | 16:43 |
| efried | THEN: filter those such that I'm only left with ones that have FOO | 16:43 |
| efried | resources=X&required=FOO => A is what we have today (master) fwiw | 16:43 |
| cdent | yes | 16:43 |
| efried | yes which? | 16:43 |
| cdent | yes to fwiw | 16:43 |
| efried | can we agree that FIRST/THEN is what we're trying to enable? | 16:44 |
| *** e0ne has quit IRC | 16:44 | |
| cdent | isn't that what we already do when in the same request group? | 16:44 |
| efried | Yeah, I can buy that. | 16:44 |
| cdent | so back a couple questions: | 16:45 |
| cdent | Is '?resources=X&required_1=FOO' a "rational" query? | 16:45 |
| efried | IMO as long as it means "the solution path includes a provider *anywhere in the tree* that has FOO" then I think it's meaningful. Whether it satisfies any "rational" use case is another question. | 16:46 |
| cdent | (I have 5 minutes or less) | 16:46 |
| efried | But IMO it could be used to "rationally" formulate requests where we know the trait is on the root provider. | 16:47 |
| cdent | I think that's likely fair | 16:47 |
| efried | because the root will always be part of the solution path anyway | 16:47 |
| efried | (as long as group_policy=none btw) | 16:47 |
| * cdent nods | 16:47 | |
| efried | (otherwise we run the risk of intersecting ourselves to the empty set) | 16:47 |
| cdent | okay, i gotta go | 16:49 |
| gibi | (I have to drop, I will definitly sleep on the problem and try to say somthing about it) | 16:49 |
| cdent | it feels like we made some smidge of progress but not certain | 16:49 |
| * gibi brain hurts | 16:50 | |
| cdent | me too | 16:50 |
| cdent | big headache | 16:50 |
| cdent | need deins | 16:50 |
| cdent | dins | 16:50 |
| cdent | by | 16:50 |
| cdent | bye | 16:50 |
| gibi | bye | 16:50 |
| efried | yeah, we still haven't solved "make sure FOO exists in the solution path otherwise established" | 16:50 |
| efried | bye | 16:50 |
| *** cdent has quit IRC | 16:50 | |
| *** tetsuro has quit IRC | 16:55 | |
| openstackgerrit | Balazs Gibizer proposed openstack/placement master: Add support for osprofiler in wsgi https://review.opendev.org/663945 | 17:39 |
| openstackgerrit | Balazs Gibizer proposed openstack/placement master: Add support for osprofiler in wsgi https://review.opendev.org/663945 | 17:42 |
| *** Sundar has quit IRC | 17:46 | |
| *** tssurya has quit IRC | 17:46 | |
| *** e0ne has joined #openstack-placement | 18:10 | |
| *** e0ne has quit IRC | 18:12 | |
| *** e0ne has joined #openstack-placement | 18:12 | |
| *** e0ne has quit IRC | 18:17 | |
| *** e0ne has joined #openstack-placement | 18:19 | |
| *** e0ne has quit IRC | 18:35 | |
| *** e0ne has joined #openstack-placement | 19:23 | |
| *** e0ne has quit IRC | 19:26 | |
| *** cdent has joined #openstack-placement | 20:32 | |
| cdent | [t e5RQ] | 20:33 |
| purplerbot | <efried> yeah, we still haven't solved "make sure FOO exists in the solution path otherwise established" [2019-06-12 16:50:17.567519] [n e5RQ] | 20:33 |
| cdent | two thoughts on that: a) remind me what's the (real world) use case for that, b) if we can rely on modeling; that can be required=FOO and FOO on the root, c) ? | 20:36 |
| * cdent leaves again | 20:36 | |
| *** cdent has quit IRC | 20:37 | |
| *** artom has quit IRC | 20:59 | |
| openstackgerrit | Chris Dent proposed openstack/placement master: Prepare objects for allocation request mappings https://review.opendev.org/662785 | 21:19 |
| openstackgerrit | Chris Dent proposed openstack/placement master: Implement allocation candidate mappings https://review.opendev.org/662245 | 21:19 |
| efried | "a) remind me what's the (real world) use case for that" [where "that" == "make sure FOO exists in the solution path otherwise established"] | 21:20 |
| efried | The only one that can't be solved with resourceless+same_subtree is "make sure my host can FOO" (or "not FOO"). | 21:20 |
| efried | The problem with "b) if we can rely on modeling; that can be required=FOO and FOO on the root" (plus "flow down") is that we | 21:20 |
| efried | (i) need to tie the trait to some potentially arbitrary/unrelated resource; and | 21:20 |
| efried | (ii) shouldn't need to construct such a complicated query for what should be a simple & common case. | 21:20 |
| efried | Unless you're suggesting that specifically resourceless+unsuffixed required=FOO has special meaning of "on the root". Which would work, but seems arbitrary and will certainly be a special case in the code. | 21:20 |
| efried | And finally, "c) ?" <== I was getting geared up to suggest some kind of new request-wide syntax. | 21:20 |
| efried | Today we have "request groups" which include {resources, required, member_of, in_tree} (in_tree is weird to me as being part of a request group, not sure why we landed there, but going with it for now). As previously discussed, one request group doesn't interact with another except to land in the same tree/aggregate. | 21:20 |
| efried | And then we have request-wide options: {limit, group_policy}. These effectively come into play to do late filters after we've already processed request groups ^ | 21:20 |
| efried | So it makes sense (to me) that "...in the solution path otherwise established" would indicate a new thing on the "request-wide" side, not in the "request group". | 21:20 |
| efried | To expand on the problem statement: "For each allocation candidate we've come up with by processing request groups, filter down to only those whose 'solution path' contains a provider with FOO" ("... contains *no* provider with FOO" for the forbidden case. Similar parallels for member_of etc). | 21:20 |
| efried | I don't have a great suggestion for what the query param key(s - need to support required/forbidden x trait/aggregate) would be. But it (they) would *not* be subject to granular-ness. | 21:20 |
| efried | Using the unsuffixed group would be semantically great - except that we already have meaning attached to that guy. | 21:20 |
| efried | But if we want to special-case as discussed above by saying that this ^ is the behavior when the unsuffixed group is resourceless... I could possibly be persuaded of that. | 21:20 |
| efried | cdent ^ | 21:21 |
| *** mriedem has quit IRC | 21:24 | |
| *** takashin has joined #openstack-placement | 21:46 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!