| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-14 | |||
| 04:07:49 | opendevreview | Merged openstack/nova stable/yoga: Fix segment-aware scheduling permissions error https://review.opendev.org/c/openstack/nova/+/840732 | |
| 04:07:55 | opendevreview | Merged openstack/nova stable/yoga: Isolate PCI tracker unit tests https://review.opendev.org/c/openstack/nova/+/840830 | |
| 04:22:43 | opendevreview | Merged openstack/nova stable/yoga: Remove unavailable but not reported PCI devices at startup https://review.opendev.org/c/openstack/nova/+/840831 | |
| 04:24:54 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to require mulitpathd for volume attachment https://review.opendev.org/c/openstack/nova/+/845660 | |
| 04:26:24 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to require mulitpathd for volume attachment https://review.opendev.org/c/openstack/nova/+/845660 | |
| 04:35:13 | opendevreview | Merged openstack/nova stable/wallaby: Fix inactive session error in compute node creation https://review.opendev.org/c/openstack/nova/+/811809 | |
| 06:45:30 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Add new option to require mulitpathd for volume attachment https://review.opendev.org/c/openstack/nova/+/845660 | |
| 07:32:55 | gibi | good morning | |
| 07:47:35 | bauzas | good morning | |
| 07:54:18 | gibi | sean-k-mooney, artom: I have concerns in https://review.opendev.org/c/openstack/nova/+/824048 | |
| 08:34:36 | bauzas | gibi: following the discussion we had last week about VGPU allocations https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8203-L8206 | |
| 08:37:18 | bauzas | https://images.squarespace-cdn.com/content/518f5d62e4b075248d6a3f90/1385326046909-827X09Z2RML6LYHWQBVI/git-blame2.jpg?format=1500w&content-type=image%2Fjpeg | |
| 08:42:50 | gibi | bauzas: ahh, it was wishfull thingkin | |
| 08:42:55 | gibi | thinking | |
| 08:43:13 | bauzas | gibi: I just wrote a quick functest and this is weird | |
| 08:43:23 | bauzas | I asked for VGPU=2 and I got only one allocation | |
| 08:43:31 | bauzas | so I need to dig into the code | |
| 08:43:50 | gibi | one allocation of two vgpus from the same pgpu? | |
| 08:44:13 | bauzas | just a plain simple flavor with resources:VGPU=µ2 | |
| 08:44:13 | bauzas | just a plain simple flavor with resources:VGPU=µ2 | |
| 08:44:45 | bauzas | which should have created a single allocation of VGPU=2 | |
| 08:44:56 | bauzas | when arriving before the above code | |
| 08:45:04 | bauzas | against one single RP | |
| 08:45:09 | gibi | yepp placement does not split allocation against a single RC between RPs | |
| 08:45:26 | bauzas | but I don't know why when I introspect, I see : | |
| 08:45:34 | bauzas | (Pdb) vgpu_allocations | |
| 08:45:34 | bauzas | {'1df35fc7-41f4-4ef4-b995-7fd561c6a391': {'resources': {'VGPU': 1}}} | |
| 08:45:39 | gibi | ohh, that is strange | |
| 08:45:46 | gibi | you should have 2 in the allocation | |
| 08:45:46 | bauzas | yeah | |
| 08:45:49 | bauzas | correct | |
| 08:46:01 | gibi | but then you have a nice problem to debug :) | |
| 08:46:14 | bauzas | I'm checking the max limit of the inventory | |
| 08:46:27 | bauzas | that could be the reason | |
| 08:46:47 | bauzas | if we cap to 1, then there are no ways to create an allocation of 2 | |
| 08:46:58 | bauzas | but... the scheduler should have failed, right? | |
| 08:47:01 | gibi | but then you should get no allocation candidates | |
| 08:47:05 | bauzas | yeah that | |
| 08:47:40 | bauzas | something got messed somewhere and I still need to investigate whether this is just a fixture issue | |
| 08:48:00 | gibi | do you have the placement log from the a_c query? | |
| 08:48:26 | gibi | does nova requested 1 VGPU in the a_c query? | |
| 08:49:31 | bauzas | I'll set the DEBUG level | |
| 08:50:55 | bauzas | shit OS_DEBUG=1 doesn't seem to work with functional tests | |
| 08:51:37 | gibi | bauzas: yep it does not, I was not able to track that down last time | |
| 08:52:00 | bauzas | pdb'ing a bit further down then | |
| 08:52:16 | bauzas | anyway, looks like a nice bone to snag | |
| 08:53:01 | bauzas | oh f*** | |
| 08:53:03 | bauzas | forget | |
| 08:53:08 | bauzas | it's PEBKAC | |
| 08:53:44 | bauzas | I wrote stupid code | |
| 08:54:07 | bauzas | https://paste.opendev.org/show/bgjrdJhdinSqXXIY6EWm/ | |
| 08:55:20 | bauzas | way better now this is fixed | |
| 08:55:47 | bauzas | let's pretend this whole conversation never existed | |
| 08:56:12 | bauzas | but my original point remains | |
| 08:56:37 | bauzas | we could let operators to isolate the allocations between different named groups | |
| 08:56:43 | bauzas | in their flavors | |
| 08:57:01 | bauzas | the point is, we will just swallow all of them but one | |
| 08:57:09 | gibi | ahh different falvor :) | |
| 08:58:04 | bauzas | I'm just about modifying the flavor to ask for one VGPU per group | |
| 08:58:18 | bauzas | and I'm pretty sure we'll end up with only one mdev | |
| 09:14:06 | ygk_12345 | hi all can anyone help me with this https://bugs.launchpad.net/nova/+bug/1978065 | |
| 09:18:09 | gibi | ygk_12345: please check the request-id in the conductor and scheduler logs as well | |
| 09:21:15 | ygk_12345 | gibi: All I can find are those messages from all nova logs. They are still stuck in scheduling and building state. Even now out of 10 vms, only 8 are created fine. rest two are in building state | |
| 09:22:15 | ygk_12345 | gibi: i have added those logs now to the case., pls check them | |
| 09:22:47 | gibi | I saw. that is awful small amount of log for an instance boot. do you see more logs for those VMs that booted successfully? | |
| 09:23:15 | ygk_12345 | gibi: let me check that | |
| 09:25:30 | opendevreview | Rajat Dhasmana proposed openstack/python-novaclient master: Add support to rebuild boot volume https://review.opendev.org/c/openstack/python-novaclient/+/827163 | |
| 09:28:58 | ygk_12345 | gibi: i have added the log | |
| 09:30:37 | gibi | I don't think you are actually having / finding all the logs. for a successfull boot you should see many log lines in the conductor / scheduler and compute service | |
| 09:32:18 | bauzas | gibi: sorry to interupt you but my a_c language is a bit rusty | |
| 09:32:30 | gibi | bauzas: no worries | |
| 09:32:38 | bauzas | gibi: /placement/allocation_candidates?group_policy=isolate&in_tree=adbdb144-d84b-4b80-b03b-a0bc520d91ba&limit=1000&resources=DISK_GB%3A20%2CMEMORY_MB%3A2048%2CVCPU%3A2&resources1=VGPU%3A1&resources2=VGPU%3A1&root_required=%21COMPUTE_STATUS_DISABLED gives me no valid candidates and I wonder why | |
| 09:33:06 | bauzas | the two RPs are supporting different types but I don't ask them | |
| 09:33:21 | bauzas | I just ask for one VGPU per RP | |
| 09:35:44 | gibi | do you have the PGPU RP in the tree of in_tree=adbdb144-d84b-4b80-b03b-a0bc520d91ba ? | |
| 09:36:29 | gibi | so you requests two vgpus from two different pGPUs (isolate) | |
| 09:36:42 | gibi | I mean one vgpu from each pgpu | |
| 09:37:53 | gibi | that should work if you have to pGPU RPs | |
| 09:39:04 | gibi | could you paste the output of https://github.com/gibizer/osc-placement-tree ? (or publish the test you are running so I can reproduce it?) | |
| 09:41:33 | bauzas | sorry was doing other thing | |
| 09:42:10 | bauzas | gibi: I can install it in the func venv | |
| 09:42:37 | bauzas | oh, you said it in the README :) | |
| 09:42:45 | bauzas | lemme pip it | |
| 09:48:11 | bauzas | gibi: I need to disappear for gym reasons but I'll work on it this afternoon | |
| 09:48:29 | bauzas | I just installed, I just need to add the placement api module in my test class | |
| 09:48:39 | gibi | bauzas: have a nice workout. feel free to ping me later | |
| 09:51:18 | bauzas | gibi: <3 | |
| 09:51:21 | bauzas | gibi: found my problem | |
| 09:51:30 | bauzas | I was only having one child RP | |
| 09:51:50 | gibi | ack, good to hear that | |
| 09:55:14 | gibi | bauzas, sean-k-mooney: an interesting performance bug https://bugs.launchpad.net/nova/+bug/1978372 | |
| 09:59:49 | sean-k-mooney | first tought is they dont know how to use the hw:numa_* extra specs | |
| 10:00:38 | sean-k-mooney | its very bad pratcit to use hw:numa_cpus or hw:numa_mem with symetric numa toplogies | |
| 10:00:46 | sean-k-mooney | its explictly an anti pattern | |
| 10:00:59 | sean-k-mooney | and should not be doen | |
| 10:01:38 | sean-k-mooney | it wont affect the perfrmace but the also mis understand the relation ship betweeh hw:cpu_threads and hw:cpu_max_threads | |
| 10:01:52 | sean-k-mooney | if hw:cpu_treads is specifed then max is ignored | |
| 10:02:03 | sean-k-mooney | sam for sockets | |
| 10:02:32 | sean-k-mooney | so that flavor defintion annoys me on a fundimental level :) | |
| 10:03:45 | sean-k-mooney | gibi: hoststly im not that suprised we know that this is a very slow algorthim | |