Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-10-12
14:15:14 bauzas ok, changing the kernel gave me some kernel tain at boot
14:15:17 bauzas taint*
14:15:25 dansmith at boot?
14:15:31 bauzas yeah
14:15:40 bauzas I'll just upload a fucking plain ubuntu image
14:15:51 dansmith lol
14:16:07 dansmith can you pastebin the taint message? really curious
14:16:16 dansmith unless your provider is inserting something of their own, I can't imagine...
14:21:44 bauzas argh, sorry, again already rebuilt
14:22:06 bauzas IIRC, it was about getting the disk
14:25:08 bauzas ok I need to go parenting my kid
14:25:10 bauzas bbiab
14:50:04 dansmith bauzas: fwiw, I can reproduce your issue if I install the kvm variant, so I'll see if I can figure out why that's not working
14:50:16 bauzas ack
14:50:45 bauzas that's crazy, I don't know yet why but the variant is automatically installed in my cloud env :facepalm
14:51:00 dansmith yeah
14:52:50 dansmith oh neither of the headers packages for that kernel contain the module symbols it seems
14:54:17 dansmith yeah totally different, weird
14:54:46 bauzas dansmith: yup and apparently I can't avoid this kernel variant to be installed in my cloud
14:55:11 bauzas I can try to use a bare kernel like the last time but my guess is that it won't boot
14:55:18 dansmith bauzas: can't avoid installing it or can't avoid booting to it?
14:55:25 bauzas both
14:55:31 dansmith how does it fail?
14:55:43 bauzas it's internal thing, so slack
15:19:48 dansmith bauzas: sean-k-mooney: ah, I got it.. the -kvm kernel has none of the vfio or mdev stuff enabled in config (because it's for virtual only) and so we have module symbols, but not symbols for the vfio or mdev base infrastructure
15:19:51 dansmith which makes sense of course
15:20:16 dansmith so we can't compile those mdev drivers because the infra they depend on is missing
15:26:12 bauzas dansmith: I eventually was able to create a new instance w/o that variant thanks to another image
15:26:41 dansmith cool, I think that's the way
15:26:42 bauzas but fwiw https://cloud-images.ubuntu.com/jammy/20231012/ provides a specific QEMU image with the kvm variant
15:27:01 dansmith yep, but we're simulating hardware here so we need a kernel with hardware stuff in it
15:27:04 bauzas so that's something so we can't support
15:27:15 bauzas agreed
15:58:10 opendevreview Dan Smith proposed openstack/nova master: Compile mdev samples for nova-next https://review.opendev.org/c/openstack/nova/+/897708
16:01:58 dansmith bauzas: this ^ hard fails on the kvm variant to make sure it's obvious
16:02:03 dansmith and also addresses some of sean-k-mooney's feedback
16:02:10 bauzas cool
16:08:05 bauzas my devstack node is still deploying the stack but I have good hopes
16:08:55 bauzas actually, my hope was wrong : E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 30066 (apt)
16:09:00 bauzas shit, need to respin
16:09:16 dansmith is auto upgrades running in the background?
16:09:29 dansmith that's a common thing
16:17:49 sean-k-mooney thats why i always do sudo apt update; sudo apt dist-upgrade -y; sudo reboot
16:17:57 sean-k-mooney before i run devstack for the first time
16:19:29 sean-k-mooney ok i also do "sudo apt install python3-dev libffi-dev libssl-dev gcc make git" too
16:19:51 sean-k-mooney devstack does pull those in as needed but it causes less issues if you do it upfront
16:21:00 sean-k-mooney thats just making sure that we can compile python c modules for pip deps
16:43:21 bauzas fwiw, was able to build the kernel modules with the plain ubuntu kernel
16:43:32 bauzas so I'll +2 dansmith's patch
16:43:52 bauzas still fighting with a last devstack issue, but unrelated to dan's
16:43:57 dansmith cool
17:21:14 bauzas dansmith: for some reason, I'm hitting hard https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1523 but it's just the first devstack start
17:21:24 bauzas so I wonder how to fix it
17:21:58 dansmith uh, leftover database?
17:22:25 bauzas probably
17:22:42 bauzas so, do you prefer that I directly write the file or removing the node ?
17:24:14 dansmith up to you, either way it's detecting the right thing
17:24:31 bauzas actually yeah, I recloned the host but this isn't a AIO
17:24:40 bauzas so the DB still exists
17:24:44 bauzas DB record*
17:24:49 bauzas okay, will write the file
17:27:12 dansmith right which is exactly what that check is for :P
17:54:29 bauzas dansmith: actually, I have to doublecheck but since state_path is /opt/stack/data/nova, this probably goes away when you unstack
17:54:48 dansmith only when you clean I think
17:54:55 dansmith but you said it's not an AIO right?
17:55:07 bauzas yeah, just a single compute connecting to another instance
17:55:10 dansmith oh you mean nova's state path gets deleted
17:55:22 bauzas yeah, my theory is when unstacking
17:55:45 dansmith right, but that's the thing it's checking for.. that you basically rebuilt a node with the same name in place
17:56:00 dansmith if you don't want that, copy the uuid file to /etc/nova and it will re-use the same thing over and over
17:56:01 bauzas right, on purpose :)
17:56:13 dansmith (assuming you don't delete /etc/nova I guess unstack might)
17:56:33 dansmith maybe we need to let devstack force a uuid so we can keep it for subsequent stack runs
17:56:39 dansmith I always do AIO so I never hit that
17:56:56 bauzas anyway, not sure we need to change anything, but that's a bit complicating a story of a 2-node devstack install with the n-cpu failing once
17:57:48 bauzas maybe, for the moment, my brain is doing concurrency between a devstack install and a customer bug
17:58:08 bauzas so I don't have the energy to think about any potential solution
18:01:31 dansmith it's doing the thing it's supposed to which is catching that you've recreated a compute node with the same name without deleting it from the database
18:01:48 dansmith so either delete it from the DB, or slap the uuid file into place
18:02:06 dansmith I'll add something to devstack to basically disable that behavior by letting you force the uuid to be the same on each stack
18:10:13 dansmith bauzas: https://review.opendev.org/c/openstack/devstack/+/898134
18:10:28 dansmith put a uuid in NOVA_CPU_UUID= in your localrc and you should be good
18:11:02 bauzas yup
18:11:06 bauzas excellent thing
18:11:08 bauzas +1 from me
19:20:55 opendevreview Dan Smith proposed openstack/nova master: Do not manage CPU0's state https://review.opendev.org/c/openstack/nova/+/898137
19:21:08 dansmith bauzas: yw ^
19:22:34 opendevreview Sylvain Bauza proposed openstack/nova master: WIP: add mtty support for vgpus https://review.opendev.org/c/openstack/nova/+/898100
20:26:54 sean-k-mooney dansmith: before i finish for tonight do we want to merge the mdev plugin or wait for bauzas to modify nova to work with it first
20:27:34 sean-k-mooney im leanign towords merge since we can trivially revert it if we dont end up using it for any reason but i said i would ask first
20:27:44 bauzas I still need to test devstack witth precreated mdevs
20:28:14 sean-k-mooney ok we can wait then i was assuming your +2 ment you were ok to merge it but was not sure
20:28:50 sean-k-mooney im just clsoing broser tabs so said i would ask before i do
20:28:56 sean-k-mooney i can loop back to this on monday
#openstack-nova - 2023-10-13
06:22:25 gokhani Good Morning Folks, I want to ask when we create snapshots with nova, can it also save memory state of instance? And an other one, when we use instance backed ceph volume, can it also save memory state when snapshotting? Thanks.
07:55:55 tobias-urdin gokhani: no to both questions, snapshotting memory is usually considered an enterprise feature that doesn't belong in cloud
08:19:32 gokhani tobias-urdin, you mean OPenstack snapshot is image/disk snapshot
08:20:29 gokhani I saw a spec but it is not implemented https://blueprints.launchpad.net/nova/+spec/instance-memory-snapshot
08:20:47 gokhani sorry it is not approved
08:24:36 tobias-urdin yes, it's disk

Earlier   Later