| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-10-12 | |||
| 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 | |
| 08:31:50 | sean-k-mooney[m] | we do not curently plan to add that feature | |
| 11:59:08 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Don not unnecessary convert images in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 11:59:34 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Do not unnecessary convert images in finish_migration https://review.opendev.org/c/openstack/nova/+/897842 | |
| 13:12:31 | opendevreview | Pavlo Shchelokovskyy proposed openstack/nova master: Forbid use_cow_images together with flat images_type https://review.opendev.org/c/openstack/nova/+/898229 | |
| 13:35:06 | dansmith | sean-k-mooney: sorry I missed the notification for your question yesterday | |
| 13:35:23 | dansmith | sean-k-mooney: seems to me like it's working for you, me, bauzas and CI so it's worth merging IMHO | |
| 13:35:50 | dansmith | whether or not we can use those things or not is a different question and we can turn off the compilation if we want to with the flags | |
| 13:36:06 | bauzas | yeah the main problem is that I don't know whether we could use mtty | |
| 13:36:19 | bauzas | because of the libvirt non-support | |
| 13:36:28 | bauzas | but let's merge it | |
| 13:36:41 | dansmith | have we asked the libvirt guys to be sure? | |
| 13:36:42 | bauzas | and we could just revert it if we find eventually that it's not able | |
| 13:36:47 | bauzas | dansmith: not yet | |
| 13:36:56 | bauzas | I had a lot of discussions with them | |
| 13:37:02 | bauzas | but not for this :) | |
| 13:37:02 | dansmith | either way, to me it really seems like doing what we need to do to be able to use these as our test fixture is worthwhile | |
| 13:45:37 | sean-k-mooney | bauzas: to me the libvirt gap is somethign we cna entrily work around in nova | |
| 13:46:12 | sean-k-mooney | dansmith: i dont disagree but i have provposed adding this exact supprot before and supproting the netdev sim for vdpa and bauzas has object during spec review | |
| 13:46:37 | sean-k-mooney | i have previously been tool we are not ment to add suprpot for emulated device just for testing | |
| 13:46:54 | sean-k-mooney | but i would like to do that personally | |
| 13:47:08 | bauzas | sean-k-mooney: if we want to persist mdevs, you know that we will need to no longer call sysfs and directly call libvirt | |
| 13:47:31 | bauzas | so if we need to go to the other way due to mtty, it would be bizarre | |
| 13:48:01 | sean-k-mooney | bauzas: yes im aware we woudl need to call libvirt to create mdevs | |
| 13:48:02 | bauzas | even if that's not for the same call | |
| 13:48:17 | sean-k-mooney | but right now your calling sysfs to create tehm | |
| 13:48:21 | bauzas | one is for getting mdev capable devices, the other one is for calling to create a mdev | |
| 13:48:24 | sean-k-mooney | but libvirt to ask about capasity | |
| 13:48:29 | sean-k-mooney | so its already split brained | |
| 13:48:30 | bauzas | yes | |
| 13:48:45 | bauzas | so, we would need to change both... | |
| 13:49:30 | sean-k-mooney | so what i would do is if we provide a real pci adress in the config | |
| 13:49:39 | sean-k-mooney | then we would just get the capstiy form libvirt | |
| 13:49:56 | sean-k-mooney | if not we shoudl get it form sysfs since its a virtual device | |
| 13:50:11 | sean-k-mooney | adn use libvirt to alwasy create mdevs instead of sysfs | |
| 13:51:21 | sean-k-mooney | we can specify that the value for the pci adress for virtual devices is the subpath under /sys/devices/virtual if you want too | |
| 13:51:50 | sean-k-mooney | so it woudl be pci_adddress=mtty/mtty or mdpy/mdpy if you want or just have a seperte config | |
| 13:51:59 | sean-k-mooney | there are lots of way to make that cleaner | |