| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-18 | |||
| 09:43:59 | gibi | sean-k-mooney: thanks | |
| 09:44:23 | gibi | I pinged the release channel as well | |
| 09:45:16 | sean-k-mooney | looking back at my orgial comment i linked to the code https://review.opendev.org/c/openstack/python-openstackclient/+/929236/comment/d39df785_1f261b9e/ to check the parmater was correct | |
| 09:45:33 | sean-k-mooney | and i misread admin_password as admin_pass | |
| 09:51:05 | bauzas | sorry, I was again off (I have a tech folk in my house for my optic fiber issue) | |
| 09:51:51 | bauzas | sean-k-mooney: stephenfin: I'm really sorry about breaking the OSC7 version, but we can't wait for a new release for like 2 days | |
| 09:52:20 | bauzas | and given https://bugs.launchpad.net/nova/+bug/2081023 I'd prefer to have time for testing it | |
| 10:16:23 | opendevreview | sean mooney proposed openstack/nova master: [DNM] testing unreleased osc https://review.opendev.org/c/openstack/nova/+/929757 | |
| 10:17:45 | sean-k-mooney | that shoudl pull osc master | |
| 10:18:07 | sean-k-mooney | im going to push another dnm to instead use the pinned version of osc | |
| 10:19:34 | opendevreview | sean mooney proposed openstack/nova master: [DNM] testing pinning osc to 6.6.0 https://review.opendev.org/c/openstack/nova/+/929758 | |
| 11:30:03 | gibi | proposed osc 7.1.2 so that if the decision is to roll forward then we can have a place to roll to https://review.opendev.org/c/openstack/releases/+/929765 | |
| 11:41:29 | bauzas | sean-k-mooney: have you seen gibi's https://bugs.launchpad.net/nova/+bug/2081023 when testing evacuate with my patch ? | |
| 11:42:11 | sean-k-mooney | i saw it but didnt look at it in detail | |
| 11:42:13 | bauzas | gibi: I'm not super happy with the move forward now, when trying to understand how OSC was calling the SDK, I wasn't sure my patch was the right thing to do | |
| 11:42:39 | sean-k-mooney | the issue is the sdk renames all the api field internally | |
| 11:42:48 | sean-k-mooney | and that mapping is really easy to get wrong | |
| 11:43:17 | gibi | bauzas: I'm not advocationg to roll forward any more. I just preparing for the chance that the decision is to roll forward | |
| 11:43:30 | gibi | also 7.1.2 needed anyhow to get a working osc out to the users | |
| 11:44:01 | gibi | bauzas: also https://bugs.launchpad.net/nova/+bug/2081023 is not osc but nova | |
| 11:44:08 | bauzas | I think we need time to test OSC7 | |
| 11:44:10 | bauzas | that's the point | |
| 11:44:11 | gibi | and only cosmetic as far as I see | |
| 11:44:12 | sean-k-mooney | i have two sets of zuul jobs usin gnova gate with master osc and rolling back to 6.6.0 | |
| 11:44:16 | bauzas | while RC1 is now super urgent | |
| 11:44:42 | sean-k-mooney | and we have the patches to requireemtn repo to go either direction | |
| 11:44:44 | gibi | bauzas: 7.1.1 is out there as we released it, so having a fixed 7.1.2 out there helps | |
| 11:44:47 | gibi | the users | |
| 11:44:49 | sean-k-mooney | so we can use that to inform the decsion | |
| 11:45:52 | bauzas | gibi: well, I wouldn't say that #2081023 is cosmetic | |
| 11:46:29 | bauzas | as an admin, you either need to set older microversion or upgrade your computes in order to not get that failure, right? | |
| 11:48:27 | sean-k-mooney | are we sure this is a bug | |
| 11:48:29 | gibi | bauzas: it happens because all of the nodes are forced down in the deployment | |
| 11:48:41 | gibi | and that results in min service version to be 0 | |
| 11:48:52 | sean-k-mooney | this is directly caused by osc using the latest microversion is it not? | |
| 11:48:53 | bauzas | right | |
| 11:48:55 | gibi | but if all nodes are down then evacuation would fail anyhow | |
| 11:49:06 | gibi | sean-k-mooney: it is independent from osc changes | |
| 11:49:09 | bauzas | correct but we get that super weird exception | |
| 11:49:18 | gibi | it is in nova since 2.95 | |
| 11:49:32 | gibi | jepp the exception test needs the cosmetic surgery | |
| 11:49:34 | gibi | that is all | |
| 11:49:40 | gibi | *text | |
| 11:50:07 | gibi | I just noticed it during testing the 7.1.2 fix in a single node devstack | |
| 11:50:44 | gibi | so I had to user <2.95 in the test hence mentioning why I needed that | |
| 11:50:47 | gibi | *use | |
| 11:51:01 | sean-k-mooney | ok so this is not a blocker to rollforward to 7.1.2 then as its not related | |
| 11:51:17 | gibi | it is not a blocker at all in RC1 and it is not related to osc at all | |
| 11:51:29 | sean-k-mooney | its just a bad error message | |
| 11:51:33 | gibi | yes | |
| 11:51:41 | gibi | as far as I see it is only a bad error message | |
| 11:51:59 | sean-k-mooney | bauzas: for context people kept asking osc to make nova ues the latest microverion | |
| 11:52:00 | gibi | and a bit hard to understand behavior around forced down nodes and service version | |
| 11:52:20 | sean-k-mooney | this is what happens when you do that with an older cloud it will use a microversoin that may not be supported | |
| 11:52:25 | bauzas | sean-k-mooney: yup, and I'm on the same path | |
| 11:52:33 | bauzas | I prefer our users to call the latest | |
| 11:52:47 | sean-k-mooney | well i really dont think that was the right path | |
| 11:52:57 | bauzas | only CLI and scripts should pin | |
| 11:53:02 | sean-k-mooney | osc shoudl use the oldest microverison supproted by the current command | |
| 11:53:06 | bauzas | for stability reasons | |
| 11:53:17 | gibi | (I saw another force down issue, with a force down / up I can force a not running compute to be reported as up but I had not time to file it. Probably not an RC regression either) | |
| 11:53:29 | bauzas | (when I say CLI, I mean programmatical usage of the CLI) | |
| 11:53:53 | sean-k-mooney | whihc is officaly not a supproted usecase of osc now | |
| 11:54:08 | sean-k-mooney | osc does not commit to providign a programable srcipting interface | |
| 11:54:20 | sean-k-mooney | whcih is explcitly why the puppet modules shoudl not use it oging forward | |
| 11:54:23 | bauzas | then, I'm definitely in favor of calling latest | |
| 11:54:48 | bauzas | as a user, I shouldn't opt into new features | |
| 11:55:32 | bauzas | man, the RC1 issue prevents me to put full attention on something | |
| 14:09:24 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: Show finish_time field in instance action show https://review.opendev.org/c/openstack/nova-specs/+/929780 | |
| 14:25:43 | opendevreview | Rajesh Tailor proposed openstack/nova-specs master: Show finish_time field in instance action show https://review.opendev.org/c/openstack/nova-specs/+/929780 | |
| 17:38:11 | auniyal | dansmith, Format inspector failed, aborting: Signature KDMV not found: b'QFI\xfb' it should be fixed by https://review.opendev.org/c/openstack/glance/+/927291 right | |
| 17:38:47 | dansmith | no? | |
| 17:39:03 | auniyal | I am getting this from nova while creating a guest from new ubuntu image, from here https://docs.openstack.org/image-guide/obtain-images.html#ubuntu | |
| 17:39:03 | auniyal | and I | |
| 17:39:24 | dansmith | that error means something is trying to validate a vmdk but likely found a qcow file or something | |
| 17:40:21 | auniyal | I downloaded .img and created glance image in qcow2 format with cmd: openstack image create --disk-format qcow2 --file file.img ubuntu | |
| 17:41:09 | auniyal | should I need to do something first, before image create ? | |
| 17:41:25 | dansmith | no | |
| 17:41:42 | dansmith | is the file actually a qcow? | |
| 17:42:29 | auniyal | I tried this, it says qcoe | |
| 17:42:31 | auniyal | file noble-server-cloudimg-amd64.img | |
| 17:42:31 | auniyal | noble-server-cloudimg-amd64.img: QEMU QCOW2 Image (v3), 3758096384 bytes | |
| 17:43:08 | auniyal | s/says qcow/qcoe | |
| 17:43:35 | auniyal | is there any other way I should check ? | |
| 17:45:11 | dansmith | no, that means it's really a qcow | |
| 17:45:31 | dansmith | you'll need to show me more of the logs around the error I guess | |
| 17:46:06 | auniyal | ack, also find this https://paste.openstack.org/show/bviBEfowzTg5mqyNfjip/ (sharing because I found and what to share this) | |
| 17:46:14 | auniyal | ack paste logs in sec | |
| 17:46:21 | auniyal | *pasting | |
| 17:47:40 | auniyal | cpu logs https://paste.openstack.org/show/bTs7U4qYjjCJX0Jcm6s8/ | |
| 17:49:04 | auniyal | these are from spawn - terminate and only w.r.t req-id | |
| 17:49:06 | dansmith | this is your problem: | |
| 17:49:06 | dansmith | Sep 18 17:33:02 amit-devstack nova-compute[1489235]: ERROR nova.compute.manager [None req-005d6727-7e99-45d9-b3b8-7046189878fc admin admin] [instance: 99886373-617e-4a99-9421-97bb23bab855] Instance failed to spawn: nova.exception.FlavorDiskSmallerThanImage: Flavor's disk is too small for requested image. Flavor disk | |
| 17:49:06 | dansmith | is 1073741824 bytes, image is 3758096384 bytes. | |
| 17:49:19 | dansmith | the error from format inspector is just it testing to see if the file is a VMDK | |
| 17:49:34 | dansmith | I mean, it's not an error, it's a debug, but the thing you *think* is an errro | |
| 17:50:43 | auniyal | oh I missed it, it was just it, I started from down, and thought of you , my bad | |
| 17:50:46 | auniyal | thanks for looking | |
| 18:01:45 | auniyal | yes, I am able to create VM with bigger size | |
| 21:06:38 | opendevreview | Tobias Urdin proposed openstack/nova master: Remove libvirt tunnelled migration https://review.opendev.org/c/openstack/nova/+/879021 | |