| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-08-22 | |||
| 14:08:54 | Sundar | merging these patches. | |
| 14:08:57 | stephenfin | belmoreira: I really don't know, I'm afraid :( melwitt is your person | |
| 14:09:12 | belmoreira | dansmith stephenfin thanks, will try to talk with melwitt | |
| 14:09:13 | stephenfin | I know you'll need a service per cell, yes, but how that will look I'm not sure | |
| 14:09:36 | stephenfin | https://github.com/openstack/devstack/blob/master/lib/nova#L947-L973 | |
| 14:17:02 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Revert "vif: Resolve a TODO and update another" https://review.opendev.org/675776 | |
| 14:30:46 | mriedem | dtantsur: TheJulia: did you find out if https://review.opendev.org/#/q/topic:bug/1839560+branch:stable/stein fixed your grenade issue with rebalancing? | |
| 14:32:14 | TheJulia | mriedem: upon issuing a change on master branch, zuul immediately comes back and says there is a branch merge failure with dependencies of a dependent patch on stable/stein | |
| 14:32:28 | TheJulia | It used to work, but... I guess not anymore. | |
| 14:33:43 | aspiers | sean-k-mooney: recheck is apparently not working for https://review.opendev.org/#/c/666915/ | |
| 14:34:48 | stephenfin | yonglihe, sean-k-mooney: Think there's a bug with that NUMA API change | |
| 14:34:52 | stephenfin | comments left | |
| 14:35:00 | sean-k-mooney | it hit a post failure again or there was a zuul restart and it got droped im guess | |
| 14:35:16 | stephenfin | tl;dr: I'd kill the summary view entirely. I don't think it's possible for it to be reliable | |
| 14:35:19 | sean-k-mooney | stephenfin: ya just read good cache on the mutable data in kwargs | |
| 14:35:28 | sean-k-mooney | stephenfin: i though we had a hacking check for that | |
| 14:35:39 | yonglihe | stephenfin: post me a comment, i gonna fix it soon. and you got new update next day. thanks. | |
| 14:35:57 | stephenfin | yonglihe: Cool. Thanks :) | |
| 14:39:12 | yonglihe | stephenfin: for most important of -1, it's we should drop instance.vcpu_model, right? | |
| 14:39:32 | stephenfin | yonglihe: In a meeting. Give me 10 | |
| 14:39:45 | yonglihe | sure. | |
| 14:46:28 | stephenfin | yonglihe: to be honest, I'd personally like to drop the 'cpu_topology' element [1] from the response [1] https://review.opendev.org/#/c/621476/57/doc/api_samples/os-server-topology/v2.77/servers-topology-resp-user.json@2 | |
| 14:46:44 | stephenfin | so we'd just include the 'nodes' element | |
| 14:47:20 | stephenfin | yonglihe: The reason being asymmetric topologies, which we support | |
| 14:47:47 | stephenfin | I can do this: | |
| 14:48:03 | yonglihe | Ok, got your concern. That's seems very right thing to do. | |
| 14:48:14 | stephenfin | openstack flavor create --vcpus 3 --ram 768 --disk 20 test.asymmetric | |
| 14:49:28 | stephenfin | openstack flavor set test.asymmetric --property 'hw:numa_nodes=2' --property 'hw:numa_cpus.0=0' --property 'hw:numa_cpus.0=1,2' --property 'hw:numa_mem.0=256' --property 'hw:numa_mem.1=512' | |
| 14:49:28 | yonglihe | I know that stuff, but it slipped away while wrote spec -:). | |
| 14:49:34 | stephenfin | Okay, sweet :) | |
| 14:50:11 | stephenfin | Also, I wonder if we should rename 'vcpu_set' to 'cpus' ? | |
| 14:50:18 | yonglihe | I bet alex_xu also buy in this solution. | |
| 14:50:32 | stephenfin | The reason being that we're overloading the term vcpu now with the cpu-resources work | |
| 14:50:37 | stephenfin | and it's also not a set | |
| 14:50:38 | yonglihe | cpus seems enough, | |
| 14:50:55 | stephenfin | Cool cool | |
| 14:51:00 | yonglihe | it's list? | |
| 14:51:11 | stephenfin | In your response, yeah | |
| 14:51:32 | stephenfin | I don't know if JSON supports sets or similar | |
| 14:51:32 | yonglihe | i wonder the does json had a set? | |
| 14:51:37 | stephenfin | jinx | |
| 14:51:47 | stephenfin | I don't think we need it | |
| 14:51:56 | stephenfin | Even if it did | |
| 14:51:59 | stephenfin | Since this is read-only | |
| 14:52:13 | stephenfin | sean-k-mooney: You happy with all that ^ RE: https://review.opendev.org/#/c/621476/ | |
| 14:52:24 | yonglihe | jinx? what's that, i'm lost here. | |
| 14:52:47 | stephenfin | yonglihe: people say "jinx" when two people say the same thing at the same time | |
| 14:53:01 | sean-k-mooney | reading back | |
| 14:53:05 | yonglihe | -:0) new to me . thanks. | |
| 14:53:30 | sean-k-mooney | you have a typo | |
| 14:53:31 | stephenfin | Urban Dictionary is a rarely a good resource but here you go, heh https://www.urbandictionary.com/define.php?term=Jinx | |
| 14:53:48 | sean-k-mooney | openstack flavor set test.asymmetric --property 'hw:numa_nodes=2' --property 'hw:numa_cpus.0=0' --property 'hw:numa_cpus.1=1,2' --property 'hw:numa_mem.0=256' --property 'hw:numa_mem.1=512' | |
| 14:54:03 | mdbooth | stephenfin: I'd assumed that was a British thing? | |
| 14:54:16 | mdbooth | stephenfin: Although you are part Essex boy, of course | |
| 14:55:18 | stephenfin | sean-k-mooney: Oops, yeah. Generally though, do those comments make sense | |
| 14:55:20 | sean-k-mooney | mdbooth: jinx is a thing in ireland too | |
| 14:55:29 | mdbooth | mriedem dansmith: https://review.opendev.org/#/c/677736/ Do those unit tests look better? Dropped the libvirt dep. | |
| 14:55:32 | stephenfin | mdbooth: Definitely an Irish thing too, I assure you | |
| 14:55:36 | sean-k-mooney | stephenfin: i have not read all the comments in the review but i will | |
| 14:55:49 | mdbooth | stephenfin: Perhaps it's a general anglophone thing, too | |
| 14:56:00 | stephenfin | though the variant I knew growing up involved not speaking 'til you were freed from the jinx :-\ | |
| 14:56:10 | mdbooth | stephenfin: Yep, that's the one I remember | |
| 14:56:23 | sean-k-mooney | stephenfin: and being punched in the sholder if you did | |
| 14:56:30 | stephenfin | yuuuup | |
| 14:56:48 | mdbooth | yonglihe: It's a cultural rabbit hole :) | |
| 14:56:54 | dansmith | mdbooth: just using fakelibvirt but otherwise the same? yes :) | |
| 14:57:11 | mdbooth | dansmith: Yarp. I had to add some additional fakeness to fakelibvirt | |
| 14:57:19 | mdbooth | But not a lot | |
| 14:57:32 | dansmith | aye | |
| 14:58:32 | mdbooth | dansmith: I've given the customer a test build, so hopefully we'll get some feedback on whether it addresses the real issue. | |
| 14:58:44 | alex_xu | stephenfin: yonglihe still checking that whether we will have empty sockets https://github.com/openstack/nova/blob/f9ba1192c4/nova/virt/libvirt/driver.py#L5219 | |
| 14:58:48 | dansmith | mdbooth: cool | |
| 14:59:46 | stephenfin | alex_xu: Yeah, that branch could be invalid (it wouldn't be the first time). Just as importantly though, what does that do for the asymmetric topology case? | |
| 15:00:20 | alex_xu | stephenfin: whether drop the cpu_topology field probably a decision for yonglihe, I remember lasttime talk with sean-k-mooney, we said if he want the cpu_topology, then it must be a field out of nova cell | |
| 15:01:13 | yonglihe | alex_xu, stephenfin, sean-k-mooney: drop it seems safe enough. | |
| 15:01:16 | alex_xu | stephenfin: I think instance.vcpu_model is for the whole machine, doesn't related to numa | |
| 15:01:24 | alex_xu | okay | |
| 15:01:44 | sean-k-mooney | yes it is for the whole vm | |
| 15:02:02 | sean-k-mooney | it not related to numa | |
| 15:02:38 | sean-k-mooney | you can have cpu_sockets=1 and numa_nodes=2 or cpu_sockets=2 and numa_nodes=1 | |
| 15:03:18 | sean-k-mooney | if you use the numa_cpu.X=y syntax you can even make it more disjoint | |
| 15:03:35 | yonglihe | if it for whole VM , does it related to asyc cpu number? how it going to behavior under such configurations? | |
| 15:03:52 | yonglihe | openstack flavor set test.asymmetric --property 'hw:numa_nodes=2' --property 'hw:numa_cpus.0=0' --property 'hw:numa_cpus.1=1,2' --property 'hw:numa_mem.0=256' --property 'hw:numa_mem.1=512' | |
| 15:04:08 | sean-k-mooney | none of those option affect eh cpu toployg at all | |
| 15:04:20 | sean-k-mooney | it change what memory contolr the cpu is mapped too | |
| 15:04:41 | alex_xu | sean-k-mooney: and the numa can across a socket, right? | |
| 15:04:45 | sean-k-mooney | the coup toplogy is contoled by hw:cpu_sockets, hw:cpu_threads and hw:cpu_cores | |
| 15:04:50 | sean-k-mooney | yep | |
| 15:05:01 | sean-k-mooney | or you can have multple numa node ins the same socket | |
| 15:05:17 | sean-k-mooney | they are treated entirely seperatly | |
| 15:05:28 | alex_xu | yea, so numa is totally a logic partition for the cpu | |
| 15:05:35 | alex_xu | and memory | |
| 15:05:54 | sean-k-mooney | you can technical configure a 2 core vm where differente hyperthreas are in different numa nodes if you want too | |
| 15:07:05 | alex_xu | nice | |
| 15:07:15 | yonglihe | sure, so expose cpu_topology is not related to asyc cpu. | |
| 15:08:12 | alex_xu | sean-k-mooney: but stephenfin point out https://github.com/openstack/nova/blob/f9ba1192c4/nova/virt/libvirt/driver.py#L5219, the vcpu_topology may empty | |
| 15:08:22 | alex_xu | I just doesn't figure out what case we will have yet | |
| 15:08:50 | sean-k-mooney | sure it will be empty unless you use teh hw:cpu_* extrapecs | |
| 15:09:22 | sean-k-mooney | so we need to not just check the vcpu_model but allso all of the sub fields to see if they are set | |
| 15:09:38 | alex_xu | oh, I thought we will have a default one | |