| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-13 | |||
| 16:23:02 | Spaz-Home | For example just using Cells and not HA pools | |
| 16:23:09 | dansmith | um | |
| 16:23:32 | dansmith | cells has nothing to do with this, but maybe you mean "just assume you can live migrate anywhere" ? | |
| 16:23:38 | openstackgerrit | Stephen Finucane proposed openstack/osc-placement master: Resolve nits from I552688b9ee32b719a576a7a9ed5e4d5aa31d7b3f https://review.openstack.org/537971 | |
| 16:23:56 | Spaz-Home | I mean that don't assume that it needs to be aggregated to live migrate. Cells does have to do with it when it can use Cells to know what to migrate to. | |
| 16:24:07 | Spaz-Home | or pooled as well really | |
| 16:24:29 | dansmith | this change has an "assume on the same network" flag, which I would assume is that? | |
| 16:24:37 | dansmith | but still, I don't see how "it can use cells to know" | |
| 16:25:00 | mriedem | so in other words, this is routed networks for xenapi live migration? | |
| 16:25:41 | dansmith | the xen driver has always had a mechanism to determine if two hosts can live migrate between each other (aggregates), | |
| 16:25:48 | dansmith | this is using a different mechanism for that now, | |
| 16:25:55 | Spaz-Home | It's also been pretty inconsistent. block-migration skips it completely | |
| 16:26:11 | dansmith | right | |
| 16:26:53 | Spaz-Home | But yeah I can agree.. so long as it's consistent | |
| 16:27:14 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/552363 | |
| 16:29:19 | dansmith | Spaz-Home: are you going to comment on that patch or what? I can't tell if you have feedback or concerns | |
| 16:29:22 | Spaz-Home | It may be worth saving that for a separate patch though to bring block-migration into proper parity as it is not the only issue that it is missing. | |
| 16:29:40 | Spaz-Home | Still just reading it and thinking, sir. | |
| 16:29:48 | melwitt | jichen: we're tracking them on the priorities etherpad at L95. I've added your patches there https://etherpad.openstack.org/p/rocky-nova-priorities-tracking | |
| 16:30:49 | Spaz-Home | Just figured i'd talk it out with people as I assume the nova development IRC room was for that.. | |
| 16:30:51 | Spaz-Home | But if not forgive me. | |
| 16:31:25 | mriedem | this room is only for kitten jokes | |
| 16:31:31 | dansmith | Spaz-Home: okay I'm just trying to make sure you comment on there if you have opinions one way or the other | |
| 16:32:04 | Spaz-Home | Right now I don't, just thinking about it.. but the more I think it's the same behavior it exhibits now just in a different way, and I cannot oppose that on concept alone | |
| 16:32:11 | mriedem | Spaz-Home: in other words, xenapi users / operators are actually pretty far and few between, so people that actually know how it works and can provide feedback on the review is very helpful | |
| 16:32:18 | Spaz-Home | I think maybe a follow-up commit to bring -block-migration into parity is a better method. | |
| 16:32:20 | mriedem | Spaz-Home: b/c i have no authority on xenapi virt driver knowledge | |
| 16:32:58 | Spaz-Home | And the cells thing is more my jenky environment running that i'm looking to preserve, so I will drop that argument for it :D | |
| 16:33:05 | jaypipes | sean-k-mooney: "deleting all the functional tests is not a solution to getting them running". <-- classic. | |
| 16:33:34 | melwitt | edmondsw: I think that should be sufficient. I'm going to be sending periodic reminders to the dev ML and mention in nova meetings to help people remember to look at the priorities etherpad | |
| 16:34:12 | Spaz-Home | I'll talk with the citrix folks on it tonight though and comment on it a bit later after some rest. | |
| 16:34:39 | dansmith | Spaz-Home: can you make sure someone shows up to the nova meeting to make sure the bp gets approved? | |
| 16:34:45 | dansmith | I'll add it to the agenda now before I forget | |
| 16:35:10 | Spaz-Home | Yeah i'll ping them all tonight to remind them. | |
| 16:35:19 | Spaz-Home | I work their hours so we see each other more than you guys do I Think | |
| 16:40:36 | Spaz-Home | melwitt, if you got my message while you were on vacation, I finished that script to pull metrics. If the numbers are something you're interested in let me know and i'll send them your way. | |
| 16:40:58 | Spaz-Home | Need to pull them for the previous 10 releases or so tonight, Will send you over a CSV. | |
| 16:42:33 | melwitt | Spaz-Home: not yet, sorry. I haven't yet gone through all the pings yet | |
| 16:44:23 | Spaz-Home | No worries at all, just figured i'd send a follow up for ya :) | |
| 16:44:33 | Spaz-Home | Absolutely bottom priority | |
| 16:45:30 | edmondsw | melwitt thanks | |
| 16:46:34 | melwitt | efried: on the runways thing, it will be at least linked to from the priorities etherpad. this week I'm writing up an etherpad on how I think it will work and I'll send it to the dev ML for people to add their input, then we'll finalize how it will work and whether it gets its own etherpad | |
| 16:47:18 | efried | melwitt: Cool beans, thanks. I just didn't know if it was already "launched" and I just didn't know where. | |
| 16:49:10 | melwitt | efried: ah, okay. sorry bout that, I was on PTO last week so this week I'm doing the things like writing up PTG summaries for the non-placement stuff and writing up something for runways, etc | |
| 16:49:47 | efried | No worries. I also have been on PTO. Enjoy catching up :P | |
| 16:50:02 | melwitt | :) | |
| 16:50:28 | Spaz-Home | Good to see the nova channel back in full gear though :) | |
| 17:03:01 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add 'member_of' param to GET /allocation_candidates https://review.openstack.org/552098 | |
| 17:03:41 | edleafe | jaypipes: dansmith: cdent: ^^ Tests should be working now | |
| 17:03:45 | openstackgerrit | Merged openstack/nova-specs master: Support disabling a cell https://review.openstack.org/546684 | |
| 17:03:49 | edleafe | Still need to add a reno | |
| 17:03:51 | dansmith | sweet | |
| 17:04:46 | mdbooth | kashyap: stephenfin The tests that I care about passed: https://review.openstack.org/#/c/551302/ | |
| 17:05:01 | mdbooth | Mind taking another look? Now with libvirt driver changes :/ | |
| 17:09:17 | bauzas | man, that NUMA spec makes me mad | |
| 17:10:47 | cdent | edleafe: yeah that double join makes far more sense | |
| 17:11:10 | cdent | otherwise there's no attachment to the rp table | |
| 17:18:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-cells-v1 run with neutron https://review.openstack.org/549789 | |
| 17:24:59 | bauzas | stephenfin: sahid: others: do you know if Nova supports ccNUMA ? | |
| 17:26:04 | stephenfin | bauzas: ccNUMA? | |
| 17:26:11 | dansmith | edleafe: do we need a reno for a placement api change? | |
| 17:26:12 | bauzas | I mean, my question is: do we have NUMA nodes having different cache numbers for CPUs ? | |
| 17:26:23 | stephenfin | bauzas: Also, which spec is upsetting you? :) | |
| 17:26:47 | stephenfin | bauzas: I hadn't heard of it before so I would assume not | |
| 17:26:56 | bauzas | stephenfin: https://en.wikipedia.org/wiki/Non-uniform_memory_access#/media/File:Hwloc.png | |
| 17:27:08 | openstackgerrit | Merged openstack/nova-specs master: Allow for merging traits and aggregates https://review.openstack.org/552122 | |
| 17:27:23 | bauzas | stephenfin: ccNUMA means that you can have multiple cache levels | |
| 17:27:50 | bauzas | I mean, for the same NUMA node | |
| 17:27:53 | stephenfin | bauzas: Oh, that sounds a bit like the cluster-on-die thing sean-k-mooney has been on about for years | |
| 17:28:22 | bauzas | no worries | |
| 17:28:27 | stephenfin | We just use whatever libvirt is reporting to us. Based on that hwloc output, we'd see four NUMA nodes/sockets for that system | |
| 17:28:42 | bauzas | so, the only resouces per NUMA node are just memory and devices, right? | |
| 17:28:55 | stephenfin | Hugepages and PCI devices, yup | |
| 17:28:58 | bauzas | I mean, the ones we know | |
| 17:29:06 | stephenfin | Be they PCI passthrough or SR-IOV | |
| 17:29:07 | bauzas | k | |
| 17:29:43 | stephenfin | I'm trying to add PCI devices used by vSwitches and I guess vGPU will use that at some point too | |
| 17:30:02 | bauzas | stephenfin: yeah, hence why I'm writing a spec | |
| 17:30:11 | bauzas | for NUMA affinity for vGPUs | |
| 17:30:24 | bauzas | at least, that spec is just about providing a RP tree for NUMA nodes | |
| 17:30:40 | stephenfin | Gotcha. Stick me on that once you've something drafted. Would be interested in seeing what it looks like | |
| 17:30:55 | bauzas | if we have PCI devices attached to a specific NUMA node, we could imagine those being nested RPs | |
| 17:31:05 | stephenfin | Yup, that's the plan | |
| 17:31:12 | stephenfin | a cycle or two from now though | |
| 17:31:16 | stephenfin | at least, afaik | |
| 17:31:16 | cdent | jaypipes: if you can put your +2 back on here https://review.openstack.org/#/c/540049/ then 3 things can merge and there will much rejoicing | |
| 17:31:17 | bauzas | but the memory would just be a resource class | |
| 17:31:31 | bauzas | even for hugepages | |
| 17:31:41 | stephenfin | Not nested under NUMA nodes? | |
| 17:31:42 | bauzas | that was my question about L2 caches | |
| 17:31:48 | bauzas | yeah | |
| 17:31:54 | stephenfin | Hmm, that seems...odd | |
| 17:32:04 | bauzas | each NUMA node has some memory, right? | |
| 17:32:13 | stephenfin | Then again, so does two views into what are essentially the same thing | |
| 17:32:19 | stephenfin | They should | |
| 17:32:31 | bauzas | okay, lemme draft the spec then | |
| 17:32:41 | stephenfin | Though I can't remember what happens if you leave some sockets on the motherboard empty | |
| 17:33:00 | bauzas | because IMHO, unless some cache memory isn't shared across the NUMA node, I see that as just a resource class for the NUMA node RP | |
| 17:33:10 | stephenfin | Yup | |
| 17:33:23 | bauzas | like CPUs | |