| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-16 | |||
| 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 (db) https://review.opendev.org/c/openstack/nova/+/831193 | |
| 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:06 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (drivers) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 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: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 (objects) https://review.opendev.org/c/openstack/nova/+/839401 | |
| 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:40 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (drivers) https://review.opendev.org/c/openstack/nova/+/833090 | |
| 14:53:40 | opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | |
| 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 | sean-k-mooney | but normlaly evacuate without force down would not be safe | |
| 16:39:44 | gibi | btw, reset-state --active helps https://paste.opendev.org/show/bVI7D8H5g9Oqjjo4rKfk/ | |
| 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 | |
| 16:43:32 | artom | IIRC it can do both | |
| 16:43:44 | sean-k-mooney | well you cant reset taskstate with it | |
| 16:43:57 | sean-k-mooney | configurably | |
| 16:44:25 | sean-k-mooney | i.e. reset-state vm-sate=active task-state=none | |
| 16:44:33 | sean-k-mooney | but i dont know if task-state=none | |
| 16:44:38 | sean-k-mooney | is hardcoded internally | |
| 16:45:27 | gibi | sean-k-mooney: reset-state resets the task state too | |
| 16:45:46 | sean-k-mooney | then ya it should be good | |
| 16:46:07 | sean-k-mooney | it would be nice if we could add task-state to the api in the futrue | |
| 16:46:09 | sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/api/openstack/compute/schemas/reset_server_state.py#L15 | |
| 16:46:21 | sean-k-mooney | but for this case we shoudl be good | |
| 16:47:25 | sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/api/openstack/compute/admin_actions.py#L77-L78= | |
| 16:48:09 | gibi | all good | |
| 16:48:10 | gibi | :)\ | |
| 16:48:28 | sean-k-mooney | gibi: are you going to file an upstream bug for the transient state | |
| 16:49:00 | gibi | sure I can I have the repro ready. But I won't assign it to myself to fix it :) | |
| 16:49:15 | gibi | at least not right now | |
| 16:58:54 | gibi | sean-k-mooney, artom, bauzas https://bugs.launchpad.net/nova/+bug/1978983 | |