| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-02-23 | |||
| 06:35:59 | cfriesen | this does mean we don't use the libvirt cpusets though, so I'm not sure that can be used as a generic solution for upstream | |
| 06:36:57 | cfriesen | with statically-allocated divisions between "shared" and "dedicated" pCPUs we might want to report two separate "cpus" and "cpus_used" numbers in the hypervisor details, one for "shared" and one for "dedicated" | |
| 06:39:29 | tetsuro | itlinux: because KVM only works with QEMU hypervisor, but agree this is confusing. We will fix this at least in Rocky realease. | |
| 06:39:56 | itlinux | thanks tesuro: I am in OOO | |
| 06:41:22 | tetsuro | your welcome | |
| 06:44:48 | tetsuro | cfriesen: Ah, I see. I think I got you. So you are not re-configure xml files but re-pinning them in linux layer. | |
| 06:47:26 | cfriesen | itlinux: the complication arises because both kvm and qemu end up calling the "qemu" binary as the hypervisor, but in the kvm case libvirt passes something like "-machine pc-i440fx-rhel7.3.0,accel=kvm" to tell it to use the hardware acceleration | |
| 06:47:39 | cfriesen | tetsuro: yes, that's correct | |
| 06:48:19 | itlinux | cfriesen: how can I verify that? | |
| 06:49:15 | cfriesen | from the compute node you can just look at the "qemu" commandline using "ps -ef" or similar | |
| 06:49:47 | tetsuro | cfriesen: Okay, I’ll add some words in the alternative and discuss with cores how they think. BTW, are you coming to PTG? | |
| 06:50:00 | itlinux | is that in the /etc/libvirt/qemu has a file I will chk that.. | |
| 06:50:06 | cfriesen | yes, I'll be there starting monday afternoon | |
| 06:50:28 | cfriesen | itlinux: no, when you have a guest up and running, then look at the commandline for the running process | |
| 06:50:41 | itlinux | looking now | |
| 06:51:27 | itlinux | http://paste.openstack.org/show/682875/ | |
| 06:51:39 | itlinux | looks correct to me but could you confirm it cfriesen: | |
| 06:51:42 | itlinux | thanks | |
| 06:52:05 | cfriesen | tetsuro: my concern about not reporting usage for "dedicated" pCPUs is that it'll make it tricky to debug scheduler failures if we don't have any way to see how "full" the compute nodes are | |
| 06:52:27 | cfriesen | itlinux: looks good to me | |
| 06:52:33 | itlinux | thanks | |
| 06:53:42 | tetsuro | I’m coming to Dublin, too. looking forward to see ya. :) | |
| 06:53:54 | cfriesen | likewise. I should get to bed, it's 1am | |
| 06:54:06 | tetsuro | OMG | |
| 06:54:19 | cfriesen | :) | |
| 06:54:20 | tetsuro | I got your concern, too. | |
| 06:54:34 | cfriesen | cool. should be a fun discussion | |
| 06:54:42 | cfriesen | later | |
| 06:55:00 | tetsuro | have a good night! I gotta go now, too. | |
| 07:40:50 | openstackgerrit | Andreas Jaeger proposed openstack/osc-placement master: DNM: Testing py35 https://review.openstack.org/547313 | |
| 08:23:08 | sahid | jaypipes: i saw you interest on some libvirt related specs, can you have look at these specs too: https://review.openstack.org/#/c/511188/ | |
| 08:23:12 | sahid | https://review.openstack.org/#/c/539605/ | |
| 08:24:00 | sahid | they address important use cases related to NFV | |
| 08:57:07 | bauzas | good morning Nova | |
| 08:57:16 | Spazmotic | Morning bauzas | |
| 08:57:38 | Spazmotic | Any cores that could pu this on their radar for this week? https://review.openstack.org/#/c/538415/ Been sitting for about 3 weeks now. | |
| 08:59:16 | Spazmotic | I am back from Korea btw, good to see you all again. | |
| 08:59:55 | bauzas | Spazmotic: most of the folks are preparing to travel for the PTG | |
| 09:00:08 | bauzas | maybe you could ask for reviewing after the next week ? | |
| 09:00:12 | Spazmotic | Yeah I know it, just hoping to get some eyes on it I guess | |
| 09:00:17 | bauzas | today, I'll look at specs | |
| 09:03:44 | Spazmotic | But asking is about all that I can do for now, and would remiss if I didn't do it :) | |
| 09:07:51 | bauzas | sure, just explaining | |
| 09:08:54 | Spazmotic | Yeah I understand of course :D | |
| 09:39:09 | openstackgerrit | Lajos Katona proposed openstack/nova master: WIP: ServerMovingTests with custom resources https://review.openstack.org/497399 | |
| 09:44:56 | ttsiouts | johnthetubaguy: Goodmorning, are you around? | |
| 09:48:35 | johnthetubaguy | ttsiouts: I am | |
| 09:48:52 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Support traits in Glance https://review.openstack.org/541507 | |
| 09:51:12 | ttsiouts | johnthetubaguy: Hello! :) we were thinking about the second call to placement | |
| 09:51:38 | johnthetubaguy | ttsiouts: what was the plan before, just returning what you had previously fetched from placement? | |
| 09:52:40 | ttsiouts | johnthetubaguy: hmmm if the freeing of the resources is successful then we can call placement for a second time. | |
| 09:53:00 | ttsiouts | we chose to form the response in the service just to save time | |
| 09:53:15 | ttsiouts | and not having to trigger placement again.. | |
| 09:53:31 | johnthetubaguy | ttsiouts: I think that proxy is bad really, you don't know what microversion nova wants to ask for, etc | |
| 09:53:48 | johnthetubaguy | ttsiouts: simpler to tell Nova if you were successful or not | |
| 09:54:39 | ttsiouts | johnthetubaguy: Great. I'll do that. | |
| 09:55:14 | johnthetubaguy | ttsiouts: I think its worth doing a cheaky import of your client in there for now, or a link to the code at least, just so its possible to follow the breadcrumbs | |
| 09:56:04 | ttsiouts | johnthetubaguy: yes, seems better | |
| 09:56:44 | ttsiouts | johnthetubaguy: what do you think is better? an api call or importing the service? | |
| 09:56:53 | johnthetubaguy | ttsiouts: cool, getting back to the spec updates (oils delete key) | |
| 09:57:06 | johnthetubaguy | ttsiouts: I quite like the API call, copying vendor data | |
| 09:57:35 | openstackgerrit | Surya Seetharaman proposed openstack/nova-specs master: Support disabling a cell https://review.openstack.org/546684 | |
| 09:57:37 | ttsiouts | johnthetubaguy: Great!! thanks John, I'll follow that up | |
| 09:58:10 | johnthetubaguy | ttsiouts: traditionally any cross service communication in OpenStack is via a REST API, so good not to break that rule | |
| 09:58:33 | johnthetubaguy | ttsiouts: being an API on the other end will making caching easier anyways | |
| 10:00:53 | ttsiouts | johnthetubaguy: cool! thanks John! | |
| 10:01:02 | johnthetubaguy | no worries | |
| 10:04:20 | bauzas | oh man, FF | |
| 10:07:16 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Support traits in Glance https://review.openstack.org/541507 | |
| 10:47:11 | openstackgerrit | Hironori Shiina proposed openstack/nova-specs master: Ironic: Instance switchover https://review.openstack.org/449155 | |
| 11:00:42 | redondo-mk | Hi. Is there anyone there that would be willing to give me some info how nova compute pulls NUMA memory info...would save me some time just trying to figure it out from nova codebase... | |
| 11:02:31 | redondo-mk | I'm looking at info that I get in `at /proc/meminfo | grep Huge` and `grep Huge /sys/devices/system/node/node*/meminfo` and I see numbers adding up...what I don't get is the following....Total-Free should give you Used, right but then I see different numbers for used in compute_nodes db table (`select numa_topology from compute_nodes`)? | |
| 11:04:39 | openstackgerrit | Hironori Shiina proposed openstack/nova master: ironic: Support resize and cold migration https://review.openstack.org/500677 | |
| 11:41:20 | openstackgerrit | John Garbutt proposed openstack/nova-specs master: Spec on preemptible servers https://review.openstack.org/438640 | |
| 11:43:58 | johnthetubaguy | ttsiouts: got a first go at the updates to the spec done: ^ | |
| 12:01:35 | strigazi | johnthetubaguy: thanks for the update | |
| 12:16:32 | srf | Hello i want to ask when i install devstack i meet nova error | |
| 12:17:35 | Spazmotic | Feel free to let us know the error and i'm sure someone has seen it before, or you may also want to try in #openstack for deployment help if you don't get any help as many people are preparing to travel to Irelund | |
| 12:24:14 | srf | I want to send but i can't paste or copy or send the pic | |
| 12:25:54 | Spazmotic | Well devstack is a command line installer so many copy and paste the error from terminal into a github gist :) | |
| 12:27:02 | openstackgerrit | Elod Illes proposed openstack/nova master: Functional test: cold migrate to compute down https://review.openstack.org/496280 | |
| 12:29:52 | srf | Oke i'll try. | |
| 12:56:27 | jaypipes | bauwser: is sahid going to PTG? | |
| 13:00:53 | bauwser | leakypipes: no, mostly all our team but him :) | |
| 13:03:18 | leakypipes | bauwser: shame :( there's a bunch of specs I wanted to discuss with him. | |
| 13:05:27 | leakypipes | dansmith: still around? | |
| 13:05:39 | leakypipes | dansmith: question for you on that IO thread vs vCPU thread thing... | |
| 13:06:15 | sean-k-mooney | leakypipes: e.g. qemu emulator treads? | |
| 13:06:28 | sean-k-mooney | they are the ones that od io right? | |
| 13:07:05 | leakypipes | sean-k-mooney: are you making fun of me? :) | |
| 13:07:54 | sean-k-mooney | haha no it geunely works differently depend on kernel vs dpdk vhost or kvm vs qeum with tci backend so it never keep this strait in my head | |
| 13:08:12 | leakypipes | sean-k-mooney: no, AFAIK, the emulator threads are the QEMU control process threads -- they send communication events to the guest I think? | |
| 13:08:54 | leakypipes | sean-k-mooney: the I/O threads are for doing device read/write operations on behalf of the guest. And the vCPU threads are for the guest's userspace code to run. | |
| 13:09:45 | leakypipes | sean-k-mooney: but I had a question about whether libvirt allows each of those three types of threads to be pinned to a specific pCPU or whether only emulator and vCPU threads were possible to pin... | |
| 13:10:15 | johnthetubaguy | you know I assumed it pinned them all together, but that is a good question | |
| 13:10:33 | leakypipes | sean-k-mooney: and further to that, can you pin the emulator thread(s) to the same pCPU as the I/O threads... | |
| 13:12:34 | sahid | leakypipes: you can pin i/o threads with emulator threads on a same pCPUs but it can have bad effects, and increase I/O lantency | |
| 13:12:57 | leakypipes | sahid: ok, cool. thanks :) | |
| 13:13:15 | leakypipes | sahid: the emulator thread doesn't get a whole lot of control process "traffic" though, right? | |
| 13:13:26 | leakypipes | sahid: pretty minimal compared to IO or vCPU threads, yeah? | |