| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 20:07:22 | dansmith | efried: normally nova creates ports for you based on what you asked for in terms of --nic arguments, presumably influenced by the flavor if this sort of bw quota was encoded there | |
| 20:07:28 | dansmith | nova uses that to decide what to ask placement for, | |
| 20:07:37 | dansmith | and then uses it to talk to neutron to create the ports for you | |
| 20:07:52 | dansmith | placement is not the Windows Registry of information about instances for other services to mine :) | |
| 20:07:58 | dansmith | jaypipes: quote of the day for you ^ | |
| 20:08:23 | efried | dansmith: Okay, so for this case we get it from here, for that case we get it from there, for this other case maybe we have to invent something convoluted to pass it through... Whereas if we split up the allocations in placement, it could all come from the same place in a consistent way. | |
| 20:08:30 | efried | and no, I'm not *trying* to be difficult. | |
| 20:08:45 | dansmith | efried: the answer to the above leading question is not "mine it from placement" | |
| 20:08:45 | efried | I'm predicting that we will suffer a death of a thousand cuts by solving this problem differently every time we encounter it. | |
| 20:08:57 | sean-k-mooney[m] | efried: neutron has acess to neither the flavor or image | |
| 20:08:58 | dansmith | efried: haaaaave you met us? | |
| 20:09:04 | dansmith | either way, | |
| 20:09:24 | dansmith | placement is not the database of things for neutron to imply random things about your quota or policy from | |
| 20:09:48 | jaypipes | WHAT dansmith SAID. | |
| 20:10:04 | sean-k-mooney[m] | the enutron port case i was thinking of is i create two sriov ports in enutron tell nova to use both and want to express anti afinity for those at the pf level so in the granualr request to placment we need some what to tell placement they cannont come form the same RP even though they have not other differences | |
| 20:10:08 | jaypipes | this is precisely the conversation I had with gibi and mlavalle earlier today. | |
| 20:10:16 | dansmith | nova could, for example, be configured to ask placement for bandwidth resource, but never tell neutron about it, if we want general recordkeeping and kinda soft quotas for distribution, but we don't need actual administrative limiting of bandwidth, for example | |
| 20:10:26 | dansmith | if you mine it out of placement, you have no idea the semantics of the data you're examining | |
| 20:10:27 | efried | if this was a neutron-specific or nova-specific thing, okay. I don't see it that way, though. | |
| 20:10:33 | jaypipes | sean-k-mooney[m]: that is what granular request groups are for. | |
| 20:10:55 | efried | jaypipes: granular request groups don't solve it. | |
| 20:10:56 | dansmith | efried: the port case is a nova/neutron conversation and placement should C its way out | |
| 20:11:04 | dansmith | efried: for disks, it's nova/nova or nova/cinder or whatever | |
| 20:11:46 | jaypipes | efried: how is granular request groups not for solving the case of "gimme 2 of these resources from different providers"? | |
| 20:11:54 | sean-k-mooney[m] | placement is the thing to model all quantitive resouces with and qualitive tratis however so i may want to express affities between resouce in the future. for now i gues a filter could be used but i would be somewhat concered that we would get no valid host becaue of the limit we pass into placement | |
| 20:11:58 | efried | jaypipes: We have no way to say "from different providers". | |
| 20:12:09 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: tox.ini: remove the stale 'minversion = 1.4' https://review.openstack.org/530776 | |
| 20:12:10 | efried | jaypipes: Unless there happen to be traits we can exploit. | |
| 20:12:11 | dansmith | efried: that's what I was saying, | |
| 20:12:15 | jaypipes | that's the whole dang point behind granular request groups. | |
| 20:12:24 | dansmith | efried: I think it's implied that if you ask for two DISK_GB allocations you expect them to be from different RPs | |
| 20:12:28 | sean-k-mooney[m] | jaypipes: the thing that granualr resouce groups is missing is i cant say Resouce1 and resouce2 can be from the same RP or the inverse the must be form the same RP | |
| 20:12:33 | efried | dansmith: Oh, definitely not that. | |
| 20:12:38 | jaypipes | dansmith: zactly my thought. | |
| 20:12:45 | dansmith | efried: and thus we should decide whether that is the case and reject, or if we should expect those to come back merged | |
| 20:12:52 | dansmith | efried: well, I would have thought exactly that, fwiw | |
| 20:12:53 | efried | What if you only have one disk provider? and still want two disks? | |
| 20:13:00 | dansmith | efried: that's not a placement thing dude | |
| 20:13:03 | dansmith | efried: that's a nova thing | |
| 20:13:10 | dansmith | efried: it will ask for how much resource from a specific provider it needs, | |
| 20:13:13 | dansmith | and it may cut it up or not | |
| 20:13:19 | dansmith | placement has no bidness knowing or caring about that | |
| 20:13:27 | jaypipes | sean-k-mooney[m]: that was the whole point of granular request groups. to allow the caller to say "give me a total of 2 of these things, but make sure I get 1 each from different providers". | |
| 20:13:44 | efried | jaypipes: No, not that. | |
| 20:13:51 | jaypipes | yes, yes that | |
| 20:13:53 | dansmith | efried: yes that | |
| 20:13:58 | dansmith | exactly that | |
| 20:14:00 | efried | jaypipes: "Give me two of these things, but each one has different traits" I'll grant you. | |
| 20:14:14 | efried | ...which has the effect of dividing them across two providers. | |
| 20:14:19 | dansmith | efried: if you ask for two things with no trait difference, I think the assumption is you want them from different places | |
| 20:14:31 | efried | But if they *don't* have different traits, putting them in different groups does *not* give you different RPs. | |
| 20:14:45 | dansmith | you're saying that, | |
| 20:14:47 | dansmith | but I disagree that that is how it should be | |
| 20:15:00 | dansmith | so if you're talking about your patches as of now, then okay.. but then we should find and -2 those :) | |
| 20:15:23 | efried | dansmith: http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/granular-resource-requests.html#semantics third bullet. | |
| 20:15:39 | jaypipes | agree wholeheartedly with dansmith. I don't see any logic in granular request groups *ever* meaning "give me two of these exact same resources, but allow them both to be from the same provider" | |
| 20:16:06 | dansmith | efried: okay so that's what I was saying above.. we either decide if they should be different (what I've been assuming) or they're not and they're effectively merged | |
| 20:16:11 | dansmith | efried: your bullet says the latter | |
| 20:16:22 | dansmith | which, if we've decided, then cool, but I think that was/is a mistake | |
| 20:16:30 | efried | jaypipes: You would never want two VFs from the same PF? | |
| 20:16:33 | jaypipes | agreed it was a mistake. | |
| 20:16:45 | dansmith | efried: two VFs from one PF is VF=2 | |
| 20:16:51 | jaypipes | efried: if you did, you would say resources:SRIOV_NET_VF=2 | |
| 20:16:53 | dansmith | efried: not VF=1,VF=1 | |
| 20:16:54 | sean-k-mooney[m] | jaypipes: it does simply one case which is merging resouce request form the image/flavor/port/volume | |
| 20:17:02 | sean-k-mooney[m] | jaypipes: it also has implcation for you cpu spec | |
| 20:17:18 | dansmith | what jaypipes said | |
| 20:17:39 | efried | How do you say, "Give me 8 VCPUs, but I don't care how you split them across NUMA nodes"? | |
| 20:17:43 | sean-k-mooney[m] | today if i have a guest with no numa toplogy and it cant fit on one numa node it will be spread. | |
| 20:17:51 | jaypipes | IMO, that third bullet should absolutely be amended to say "requesting granular request groups of the same resource means that the resulting candidates will be from different providers" | |
| 20:17:54 | dansmith | efried: if I just want multiple VFs and ensure they're on different PFs, but I don't care about any other reason, then VF=1,VF=1 means that, different from VF=2 | |
| 20:18:06 | dansmith | efried: VCPUS=8 | |
| 20:18:10 | sean-k-mooney[m] | if we say the non numbered resouce request must also be form one RP we cannot support that now | |
| 20:18:38 | efried | dansmith: VCPUS=8 will get you all 8 from the same RP. That's not even related to this discussion. | |
| 20:19:04 | jaypipes | sean-k-mooney[m]: the non-numbered request group specifically says "use_same_provider=False" | |
| 20:19:22 | dansmith | efried: how does VPUS=4,VCPUS=4 make it more flexible? | |
| 20:19:26 | dansmith | efried: that's not saying "do as you with" | |
| 20:19:28 | dansmith | *wish | |
| 20:19:51 | efried | dansmith: It doesn't. But VCPUS=1,VCPUS=1,VCPUS=1,VCPUS=1,VCPUS=1,VCPUS=1,VCPUS=1,VCPUS=1 does. | |
| 20:19:58 | sean-k-mooney[m] | dansmith: what about the case of all you severs have 2 numa node with 10 cores each and i want 16 cores but dont care about numa in my guest | |
| 20:20:00 | efried | dansmith: Now we can spread 'em any which way they fit. | |
| 20:20:04 | dansmith | efried: you can't be serious | |
| 20:20:32 | dansmith | efried: and if I want 32G of memory allocated anywhere? 32*24 query params? :) | |
| 20:20:44 | jaypipes | sean-k-mooney[m]: then you would request VCPU=16 | |
| 20:20:44 | sean-k-mooney[m] | jaypipes: so non granular can be form multiple RPs and granular resuest each request is guarteeed to be form differnt RPs | |
| 20:20:57 | efried | dansmith: I imagine step sizes come into play there | |
| 20:21:07 | jaypipes | sean-k-mooney[m]: yes. | |
| 20:21:12 | dansmith | efried: okay but that's still a damn lot of params for silly reasons | |
| 20:21:28 | dansmith | tbh, I'm kinda frustrated by this conversation at this stage in the game and I'm late leaving for something else | |
| 20:21:30 | efried | dansmith: How else do you ensure generic spreadability? Is that a silly reason? | |
| 20:21:44 | efried | Okay. Y'all have made your position clear. | |
| 20:21:50 | dansmith | so I shall bow out, but jaypipes I agree about that third bullet change, or at least putting a stake in the ground about needing to revisit it | |
| 20:22:02 | dansmith | back later | |
| 20:22:16 | jaypipes | efried: what is generic spreadability? is that like I can't believe it's not butter? | |
| 20:22:40 | efried | Oh, you better believe it. | |
| 20:22:43 | jaypipes | heh | |
| 20:24:49 | efried | jaypipes: It means, "I know I want 4 VCPUs. I don't care about NUMA affinity. I just want my instance." Some hosts have no NUMA (all VCPU on the compute RP). Some have two NUMA nodes, some have four. It's a fullish cloud. I sure would like it if I could land my instance, whether there's a host with 4 VCPUs in one NUMA node, or one with 3,1, or one with 2,1,1,0, etc. | |
| 20:25:35 | sean-k-mooney[m] | jaypipes: so just to confim. non granuarl resouce resutes can from from multiple RP. each Granular resouce request of the same resouce class is guarenteed to come form different RPs and Granular Resouce request can or cannot spread across multiple RP im assuming Cannot? | |
| 20:25:37 | jaypipes | efried: resources:VCPU=4 | |
| 20:25:40 | jaypipes | simply as that. | |