| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-16 | |||
| 12:48:30 | sean-k-mooney | i still have it open in emacs | |
| 12:49:08 | gibi | yes I stil think we should merge it on master with 79 lines | |
| 12:51:05 | sean-k-mooney | oh thats where i put the default chagne stuff | |
| 12:51:25 | sean-k-mooney | i started that in vscode since i was using that to debug the repoducer | |
| 12:51:46 | sean-k-mooney | i spent like 30 mins looking for it in differnt emacs and terminal windows | |
| 12:52:06 | gibi | :D | |
| 12:53:30 | sean-k-mooney | it also does not help that i have 4 copies of nova and i started workign on it in the one i reseve for quickly pulling down patches and testing them locally | |
| 12:53:48 | sean-k-mooney | aka ~/repos/openstack/nova-3 | |
| 12:53:51 | gibi | I started using git worktree so I can track where I my nova checkouts :D | |
| 12:54:01 | gibi | s/I/are/ | |
| 12:54:20 | sean-k-mooney | what is git worktree | |
| 12:54:33 | gibi | you can have multiple working direktory for a single git repo | |
| 12:54:42 | gibi | each directory can have a different version checked out | |
| 12:54:50 | gibi | but all tight to the same local git repo | |
| 12:54:58 | jkulik | loving git worktree for working on multiple things in parallel :) | |
| 12:55:02 | sean-k-mooney | i normally do must of my dev on vms or my server so the local checkouts on my laptop are usually only for pep8/unit tests fixing | |
| 12:55:33 | sean-k-mooney | gibi: oh ok i shoudl look into that | |
| 12:55:43 | sean-k-mooney | similar concept but differnt approch to git-nit | |
| 12:56:49 | sean-k-mooney | commit-ish | |
| 12:56:53 | sean-k-mooney | hehe i like that | |
| 12:57:52 | sean-k-mooney | so i coudl tie my nova-1 nova-2 and nova-3 repos togenter into one nova repo and use those folders as work dirs instead of full repos | |
| 12:58:46 | sean-k-mooney | if im in a git work tree folder and i do git checkout or rebase ectra does it work like a normal repo? | |
| 12:58:55 | sean-k-mooney | but only affecting that workign tree | |
| 12:59:11 | gibi | yes | |
| 12:59:24 | gibi | and you can aways say git worktree list to see where are your workdirs :D | |
| 12:59:26 | sean-k-mooney | ok so i coudl have 2 rebases going on in differnt workign trees | |
| 12:59:33 | gibi | I think so yes | |
| 12:59:39 | sean-k-mooney | cool | |
| 13:00:01 | sean-k-mooney | i dont do that often but sometimes if im pinged to respine X while working on y i will | |
| 13:33:05 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 13:33:05 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 13:33:06 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 13:33:06 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (drivers) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 13:40:58 | opendevreview | sean mooney proposed openstack/nova master: update default numa allocation strategy https://review.opendev.org/c/openstack/nova/+/846169 | |
| 14:28:25 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: fake: Ensure need_legacy_block_device_info returns False https://review.opendev.org/c/openstack/nova/+/843678 | |
| 14:28:26 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: Add a regression test for bug 1939545 https://review.opendev.org/c/openstack/nova/+/843702 | |
| 14:28:27 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: compute: Ensure updates to bdms during pre_live_migration are saved https://review.opendev.org/c/openstack/nova/+/843680 | |
| 14:28:28 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: fup: Make connection_info returned by CinderFixture unique per attachment https://review.opendev.org/c/openstack/nova/+/844594 | |
| 14:28:29 | opendevreview | Artom Lifshitz proposed openstack/nova stable/wallaby: fup: Assert state of connection_info during LM rollback in func tests https://review.opendev.org/c/openstack/nova/+/844595 | |
| 14:53:39 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | |
| 14:53:39 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 14:53:40 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 14:53:40 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (drivers) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 15:27:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: Report PCI inventory to placement basics https://review.opendev.org/c/openstack/nova/+/846187 | |
| 15:30:54 | opendevreview | Balazs Gibizer proposed openstack/nova master: Report PCI inventory to placement basics https://review.opendev.org/c/openstack/nova/+/846187 | |
| 15:51:31 | dansmith | does anyone know of a recentish change to nova that might have inflated n-cpu memory footprint? | |
| 16:00:50 | sean-k-mooney | not that im aware of that has merged | |
| 16:01:43 | sean-k-mooney | dansmith: gibi has a change that adds a trivial cache for speeding up numa toplogy computation | |
| 16:01:48 | sean-k-mooney | but i dont think that has merged | |
| 16:02:08 | sean-k-mooney | dansmith: are you trying to track down a memory increase | |
| 16:02:36 | dansmith | maybe yeah | |
| 16:03:29 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/845896 but its not merged so its not that | |
| 16:04:55 | dansmith | okay, so it's not a regression, or at least, not a recent one | |
| 16:05:13 | dansmith | n-cpu memory usage after a single-node run is ~500m, but after a multinode one, it's 1.5G to 2.5G | |
| 16:05:23 | dansmith | so I wonder if we're buffering something in memory due to live migration or something | |
| 16:05:34 | sean-k-mooney | do you have swap awailable | |
| 16:05:55 | dansmith | what does it matter? it' | |
| 16:06:06 | dansmith | it's not OOMing, we're just noticing it's much larger | |
| 16:07:02 | sean-k-mooney | just tha ti saw high memory usage in the past when swap was disabled | |
| 16:07:11 | sean-k-mooney | that did not happen when it was available | |
| 16:07:23 | sean-k-mooney | but i guess you have the saem config in singel vs multinode | |
| 16:07:35 | dansmith | yeah, these are CI workers | |
| 16:07:56 | sean-k-mooney | so is it that somehow adding a second compute node increase memory usage on the first | |
| 16:08:17 | sean-k-mooney | like if you enable a multi node install but idsable nova-cpu on the subnode | |
| 16:08:20 | sean-k-mooney | does it still happen | |
| 16:08:25 | dansmith | I was thinking more like in live migration we read in the configdrive to memory or something | |
| 16:08:36 | dansmith | you know how python increases the water mark but basically never decreases it | |
| 16:09:05 | sean-k-mooney | hum ok maybe | |
| 16:09:20 | sean-k-mooney | you could confirm that by disabling move operations tests | |
| 16:09:47 | sean-k-mooney | the config drive is pretty small but maybe | |
| 16:09:56 | dansmith | just an example | |
| 16:10:16 | sean-k-mooney | ya im jsut trying to think what else is like that | |
| 16:10:41 | sean-k-mooney | is the memory usage the same on both hosts? | |
| 16:10:49 | dansmith | I don't collect the other so dunno | |
| 16:13:35 | sean-k-mooney | would it be hard to add that | |
| 16:14:02 | sean-k-mooney | do you have the link to the ci job by the way | |
| 16:16:17 | dansmith | it's all the jobs, there's no need to look at one specifically | |
| 16:16:36 | dansmith | I thought it was recent, but I compared to some old snaps I had and they were high then too, but only for multinode | |
| 16:36:22 | gibi | sean-k-mooney, bauzas, artom: on master we still reject the evacuate request if the instance is in transient state (i.e. powering-off) https://paste.opendev.org/show/bQphEfOf8eLBnM6XmleQ/ | |
| 16:37:23 | gibi | so for me this seem like a valid request to evacuate the instance in this state | |
| 16:38:47 | sean-k-mooney | its not safe nessisarly to do by default | |
| 16:39:02 | gibi | even if the compute is forced down? | |
| 16:39:18 | sean-k-mooney | if its force down its oke | |
| 16:39:21 | sean-k-mooney | but only because | |
| 16:39:27 | sean-k-mooney | the operator is | |
| 16:39:33 | sean-k-mooney | promising they have fenced it | |
| 16:39:36 | gibi | yepp | |
| 16:39:44 | gibi | btw, reset-state --active helps https://paste.opendev.org/show/bVI7D8H5g9Oqjjo4rKfk/ | |
| 16:39:44 | sean-k-mooney | but normlaly evacuate without force down would not be safe | |
| 16:39:57 | sean-k-mooney | we cant tell that the vm is not running | |
| 16:40:00 | gibi | yepp in generate evacuate without fencing is unsafe in non transient states too | |
| 16:40:10 | gibi | s/generate/general/ | |
| 16:40:22 | sean-k-mooney | so ya if we check both then we can ignore the task state | |
| 16:40:35 | sean-k-mooney | *both-> force-down | |
| 16:40:44 | sean-k-mooney | so question | |
| 16:40:53 | sean-k-mooney | does the decorator support ignoring task state | |
| 16:42:29 | gibi | so on master I'm OK to ignore the task state | |
| 16:42:51 | gibi | downstream I would suggest the customer to use the reset-state, so no code changes is needed there | |
| 16:43:16 | sean-k-mooney | reset_state only resets vm state not task state right | |
| 16:43:27 | sean-k-mooney | or dose it force task_state=None | |