Earlier  
Posted Nick Remark
#openstack-nova - 2022-06-16
12:48:09 sean-k-mooney i was just cleaning up some terminals and closed the one i was working on that in
12:48:25 sean-k-mooney well one of them
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

Earlier   Later