| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-06 | |||
| 21:04:46 | cdent | mriedem: for latest example see my note to self on https://review.openstack.org/#/c/541435/ | |
| 21:04:51 | mriedem | sean-k-mooney: you act like i said no one could push patches | |
| 21:05:24 | cdent | would a spec or blueprint be of any value? | |
| 21:05:40 | sean-k-mooney | mriedem: hehe sorry i know that is not what you ment. i just hate seeing __init__.py files with anything but constants in them | |
| 21:05:47 | mriedem | cdent: idk | |
| 21:06:11 | sean-k-mooney | mriedem: its a pet pev of mine. | |
| 21:06:20 | mriedem | cdent: if it's a non-trivial amount of work, and is a depednency for the eventual placement split, then i could see a specless bp | |
| 21:07:04 | cdent | yeah, sadly it would probably be non-trivial as it often ends with wiggle here causing ripples way over there | |
| 21:07:56 | cdent | I'll put it my queue, thanks. | |
| 21:08:22 | cdent | and I think that can be the end of my work day | |
| 21:08:38 | sean-k-mooney | cdent: that part of why i dont like that patten in python. for example import anyting in nova.cmd results in your process being monkey patched https://github.com/openstack/nova/blob/master/nova/cmd/__init__.py | |
| 21:09:18 | cdent | yup | |
| 21:09:51 | cdent | 'night all | |
| 21:16:04 | openstackgerrit | Merged openstack/nova master: Add PowerVM to feature-classification https://review.openstack.org/533237 | |
| 21:16:13 | efried | edleafe: yt? | |
| 21:21:58 | kashyap | dansmith: Okay, after watching the Falcon launch, I came back to IRC | |
| 21:22:17 | kashyap | dansmith: Saw your comment in the review. Much clearer. | |
| 21:22:35 | kashyap | So, I asked a libvirt dev who does migration to look into it -- Will the 'bandwidth' parameter of migrateToURI2() will be ignored if it was previously set by the API migrateSetMaxSpeed()? | |
| 21:23:09 | mriedem | dansmith: i'm going to announce this here publicly, but melwitt has never been asked to give a sizing | |
| 21:23:19 | mriedem | sdague: ^ is that an ibm only thing? | |
| 21:23:56 | edleafe | efried: ? | |
| 21:24:05 | mriedem | melwitt: this was much more fun before you said LOEs | |
| 21:24:08 | efried | edleafe: Wanted to do a quick brainstorm if you have a mo. | |
| 21:24:12 | melwitt | mriedem: haha, sorry | |
| 21:24:24 | sean-k-mooney | mriedem: a sizing of a task? if so how, i get ask that all the time for stuff i dont even work on | |
| 21:24:32 | kashyap | dansmith: Will respond on that review once I dig into the Python bindings and upstream relevant APIs to confirm what you asked. (Also double-confirm with a libvirt upstream dev.) | |
| 21:24:40 | edleafe | efried: sure | |
| 21:24:42 | mriedem | sean-k-mooney: of course you do, because you work at a corporation | |
| 21:25:12 | sean-k-mooney | mriedem: :) ah so thats where i went wrong. | |
| 21:25:20 | efried | edleafe: Trying to think through an easy way to get NUMA affinity in placement modeling. First off, do you understand the stuff Jay has been talking about, something about aggregate "distance"? | |
| 21:25:37 | edleafe | efried: vaguely | |
| 21:26:03 | efried | edleafe: Can you help me understand it? | |
| 21:26:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/540256 | |
| 21:26:34 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 21:26:50 | sean-k-mooney | mriedem: also because of that we are ment to track everything we do upstream and in jira and in downstream tools with vendors ... corporate processes :) | |
| 21:26:53 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Transform live_migration_post_dest notification https://review.openstack.org/469784 | |
| 21:27:20 | edleafe | efried: my weak understanding is that it would favor RAM that is associated with a given NUMA node, but that if there wasn't enough, it would use RAM that was "further away" | |
| 21:27:37 | efried | edleafe: Okay, but how does this "distance" thing get defined? | |
| 21:27:52 | edleafe | efried: that's the part that I don't have any clue about | |
| 21:28:03 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [cellv2] Improve getting BDMs in multiple cells https://review.openstack.org/521400 | |
| 21:28:10 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [cellv2] Improve getting BDMs in multiple cells https://review.openstack.org/521400 | |
| 21:28:21 | mriedem | sean-k-mooney: do you track how much time you aren't spending working on grant requests when you should be? | |
| 21:28:29 | efried | edleafe: Okay, me neither. So starting from first principles, I was thinking about how one could model NUMA affinity. And here's what I came up with: | |
| 21:28:34 | edleafe | efried: you'd have to have Jay give a lesson on this (to all of us) | |
| 21:29:21 | efried | edleafe: GET /allocation_candidates?<...the usual resource requests...>&affine_resources=<resource_class>,<resource_class>,... | |
| 21:29:36 | mriedem | efried: L142 https://etherpad.openstack.org/p/nova-ptg-queens-placement | |
| 21:29:46 | sean-k-mooney | mriedem: hehe if it did i would cry | |
| 21:30:23 | efried | mriedem: Thanks. Will dig. | |
| 21:30:38 | efried | edleafe: So first of all, it would only apply to the unnumbered request group. Because you're already getting same-provider "affinity" in the numbered groups. | |
| 21:31:29 | efried | edleafe: So within the unnumbered request group, the API would force the resources from classes you list to come from either the same provider, or the same aggregate. | |
| 21:32:19 | efried | edleafe: I'm not sure an anti_affine_resources makes any sense, but could be added if it does. | |
| 21:32:46 | edleafe | efried: "affine"? | |
| 21:33:12 | edleafe | efried: How would that specify RAM, PCI deveice, etc., associated with a given NUMA? | |
| 21:33:33 | efried | edleafe: Okay, let me give a more complete example, make more sense. | |
| 21:34:29 | sean-k-mooney | edleafe: anti_affine_resources for nic bonding e.g. antiafintiy of the pf for the VF request | |
| 21:34:40 | sean-k-mooney | efried: ^ | |
| 21:34:44 | efried | sean-k-mooney: ack | |
| 21:35:20 | efried | edleafe: To start with, model NUMA nodes as subtrees under the root compute host RP (which may not in fact provide any resources). So maybe the first tier children provide CPU & memory, and the second tier (grandchildren) are the network devices providing VFs. | |
| 21:35:53 | efried | edleafe: Associate each child/grandchildren in a given NUMA node with the same aggregate UUID. | |
| 21:36:49 | efried | edleafe: Then your request would be like GET /allocation_candidates?resources=VCPU:2,MEMORY_MB:2048,SRIOV_NET_VF:1,DISK_GB=2048&affine_resources=VCPU,MEMORY_MB,SRIOV_NET_VF | |
| 21:37:03 | edleafe | why can't the network devices be children of the NUMA node? | |
| 21:37:11 | efried | They are | |
| 21:37:14 | efried | swhat I said | |
| 21:37:33 | efried | Sorry, to rephrase: | |
| 21:37:36 | sean-k-mooney | efried: but the cpu and memory shoudl also be childeren of the numa node too | |
| 21:37:51 | edleafe | "and the second tier (grandchildren) are the network devices providing VFs." | |
| 21:37:53 | efried | sean-k-mooney: The CPU/mem are resources provided by the numa node which is the RP. | |
| 21:38:47 | sean-k-mooney | efried: ah they are inventories of the numa node rather then sub resouce providres but that means you can have traints on the cpu and ram | |
| 21:39:12 | sean-k-mooney | *can't have traits | |
| 21:39:17 | efried | So root RP is the compute node. It provides no resources. It has two child RPs, representing NUMA nodes. They provide VCPU and memory inventory. Then those guys have child RPs representing network devices, providing VF inventory. | |
| 21:39:34 | edleafe | efried: one thing we learned back in Atlanta was that this stuff was much better discussed with a drawing surface so that all could see the relationships | |
| 21:40:04 | edleafe | Those of us who think visually need that for anything other than the trivial stuff | |
| 21:40:22 | mriedem | https://awwapp.com/# ? | |
| 21:40:25 | efried | sean-k-mooney: Yeah, that would be another way to do it: model the NUMA provider as an empty child of the empty root compute host and give the NUMA provider three grandchild tiers which provide CPU, memory, and VFs. | |
| 21:40:48 | edleafe | mriedem: sure. efried, have at it! | |
| 21:40:48 | efried | But not to get hung up on those details. | |
| 21:41:07 | mriedem | or https://webwhiteboard.com/ | |
| 21:41:15 | edleafe | And I'm still not clear how "distance" figures into any of this | |
| 21:41:16 | mriedem | i won't be joining, but just being super helpful | |
| 21:41:51 | efried | edleafe: It doesn't. This is purely one-dimensional affinity. Either they're in the same agg or they're not. | |
| 21:42:17 | edleafe | efried: ok, that's where I was not clear | |
| 21:43:18 | edleafe | efried: won't the current NRP stuff handle this without additional work? IOW, the CPU,RAM,VF all have to | |
| 21:43:31 | edleafe | be from the same provider | |
| 21:43:41 | efried | Only if we can model them as belonging to the same provider. | |
| 21:43:59 | sean-k-mooney | edleafe: distance was discused in 2 forms. 1 a distance in nodes along the provider tree and 2 a distence to a shared resouce provider and an aggreate member to model things like network latency for share storage | |
| 21:44:00 | efried | Which we can do for just CPU/memory, but not for VFs. | |
| 21:44:31 | efried | And also splitting things up more allows us to tie traits more specifically to their resources, if that matters. | |
| 21:44:31 | edleafe | efried: yeah, I guess it could think of the compute node as the root provider, and then stuff from different NUMA nodes would match | |
| 21:45:50 | edleafe | sean-k-mooney: I remember the shared distance thing. I thought that was discarded as not needed, because you could just create tighter aggregates so that only "near" storage would ever be used | |
| 21:46:11 | efried | sean-k-mooney: I tried thinking about distance along a tree, but kept painting myself into a corner where that would severely restrict how things would have to be modeled. | |
| 21:46:38 | sean-k-mooney | edleafe: yes proably its been a while since denver | |
| 21:46:39 | efried | sean-k-mooney: Do you understand the concept of distance as relates to aggregates? Cause I don't. | |
| 21:47:53 | efried | https://awwapp.com/b/umrhofjje/ | |
| 21:49:41 | edleafe | efried: so we would use aggs to denote a NUMA node? | |
| 21:50:04 | efried | aggzactly. | |
| 21:50:13 | edleafe | ugh | |
| 21:51:50 | efried | I don't know how we get anti-affinity with this, though. Anything down the anti_affine_resources thought path is bringing my head crashing against a brick wall. | |
| 21:51:50 | edleafe | you'd probably have to extend the aggs to include the compute node, no? | |
| 21:52:03 | efried | The least of the problems being the lack of symmetry. | |
| 21:52:07 | sean-k-mooney | efried: not very well. the distance along the tree i understand. all inventoies of the same resouce provider have a distance of 0, parent/direct chile is distance or 1 and so on | |