| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-07-27 | |||
| 18:58:20 | sean-k-mooney | that works on my home cloud which is using cinder BFV | |
| 18:58:56 | sean-k-mooney | so there is a bug in nova as this should work | |
| 18:59:40 | sean-k-mooney | if the test catches that then the test is ok but it shoudl be failing when using the correct server id | |
| 19:00:06 | sean-k-mooney | in the lvm job | |
| 19:00:28 | sean-k-mooney | so we shoudl retirage https://bugs.launchpad.net/nova/+bug/2028851 | |
| 19:00:40 | sean-k-mooney | its a valid bug for both nova and tempest | |
| 19:00:58 | sean-k-mooney | dansmith: melwitt: do you agree ^ | |
| 19:01:47 | sean-k-mooney | on the nova side we either need to say the console shoudl always be aviable for all dirver when the server is off | |
| 19:01:55 | sean-k-mooney | or that test is invalid for nova-lvm | |
| 19:02:07 | melwitt | I'm a little confused but if the tempest test is passing with the correct server id with a 404 being returned from nova then the tempest test has a bug as well | |
| 19:02:24 | sean-k-mooney | no i think that will fail | |
| 19:02:38 | sean-k-mooney | the only tempest bug is the one gmann found where its not using the correct id | |
| 19:02:51 | melwitt | oh gotcha. yeah. I agree there is a bug on nova too | |
| 19:04:01 | gmann | https://review.opendev.org/c/openstack/tempest/+/889895 | |
| 19:04:45 | dansmith | 404 should mean "that path you gave me does not exist | |
| 19:04:48 | gmann | melwitt: sean-k-mooney yeah i will fail, I tested locally and got the 404 from nova, tempest failed | |
| 19:05:03 | dansmith | 404 for a POST doing an action that doesn't return anything but for a guest that does exist is extremely wrong, IMHO | |
| 19:05:35 | dansmith | especially when the same POST url just worked for shutdown and will work a minute later for start up | |
| 19:05:40 | gmann | dansmith: yes it says 404 Guest does not have a console available | |
| 19:05:57 | sean-k-mooney | dansmith: its kind of abusing 404 right now | |
| 19:05:57 | dansmith | right, that is incorrect HTTP behavior, IMHO | |
| 19:06:06 | dansmith | yeah | |
| 19:06:10 | sean-k-mooney | but i can see why someone might have chosen it | |
| 19:06:16 | sean-k-mooney | i.e. the log was nto found | |
| 19:06:17 | gmann | maybe 400 we should return | |
| 19:06:29 | sean-k-mooney | no its a 500 or simiall | |
| 19:06:35 | sean-k-mooney | this is a server side issue | |
| 19:06:47 | dansmith | how is it a 500? | |
| 19:06:54 | dansmith | IMHO, it should be 200 | |
| 19:07:07 | sean-k-mooney | well it shoudl be a 200 with the content | |
| 19:07:23 | gmann | so until guest is shutoff, console not available is ok | |
| 19:07:36 | sean-k-mooney | which is what i get with a bfv vm with cinder lvm | |
| 19:08:07 | sean-k-mooney | so with nova and lvm today we can only get the console while the vm is running | |
| 19:08:16 | dansmith | sean-k-mooney: did I miss why lvm differs here? | |
| 19:08:26 | sean-k-mooney | with bfv we can get the console when the vm is stopped | |
| 19:08:54 | dansmith | because I would say that the console should always return 200, even if the console is empty, unless we know that it can't have a console or something.. and even still, 404 is not the right thing to return (nor 500) | |
| 19:08:59 | sean-k-mooney | dansmith: no im still not sure why that is the case although i cna try and compare to my home cloud | |
| 19:09:14 | dansmith | we have to figure that out, because I think that's wrong (as heck) | |
| 19:09:18 | sean-k-mooney | dansmith: ya i would be ok with always returnning 200 | |
| 19:09:34 | dansmith | but even still, 200 even if it's empty because the operation worked, this is what we have for console log, which may be nothing | |
| 19:09:42 | sean-k-mooney | i said 500 just ebcasue there is a bug in nova | |
| 19:09:48 | sean-k-mooney | but this is part of the interop tests right | |
| 19:09:48 | dansmith | if you have your kernel set to log to something other than tty0 it'll be blank too | |
| 19:09:56 | sean-k-mooney | so this cant have backend depent behavior | |
| 19:10:09 | gmann | yeah empty is still a response we got the console | |
| 19:10:20 | gmann | but console not available? | |
| 19:11:06 | gmann | 'console not available' should be error case right | |
| 19:11:41 | sean-k-mooney | it depends | |
| 19:12:06 | dansmith | it should never be 404, that's for sure | |
| 19:12:11 | gmann | because this fix will get the 404 on console not avaliable for the shutoff Guest https://review.opendev.org/c/openstack/tempest/+/889895 | |
| 19:12:16 | dansmith | because /action exists | |
| 19:12:30 | dansmith | it can be an error maybe if we've never started the guest yet, or *maybe* if it was lost from disk somehow | |
| 19:12:34 | dansmith | but that's different than blank | |
| 19:12:35 | sean-k-mooney | dansmith: i agree on the 404. the depends is more i belive its possibel to have a vm without any console | |
| 19:12:39 | gmann | I think 400 is more appropriate here | |
| 19:13:01 | dansmith | maybe 410 Gone | |
| 19:13:16 | dansmith | Honestly, 4xx means the client messed up and the client hasn't messed up here | |
| 19:13:23 | dansmith | there's also 425 Too Early | |
| 19:13:30 | dansmith | and 428 Precondition Required | |
| 19:13:39 | gmann | but when server is not yet active and console not availble 410 is not right. for shutoff case where console was available but now it is not | |
| 19:14:07 | dansmith | yeah, I really don't understand what use ever returning 4xx for this is | |
| 19:14:12 | gmann | dansmith: but if request is before server is in active or in shutoff state it is client error right? | |
| 19:14:14 | dansmith | maybe on a windows guest where there is no such console? | |
| 19:14:27 | sean-k-mooney | so its not a clinet error so 4XX is incorrect | |
| 19:14:37 | dansmith | gmann: I dunno, it's debatable I think | |
| 19:14:42 | dansmith | maybe if you call it before it's active, | |
| 19:14:57 | sean-k-mooney | the user should be able to expect the console to be ableiable i think if a console exits for the instnace | |
| 19:14:59 | dansmith | but since you shoudl be able to call it in SHUTOFF, that's kinda confusing to the user that doesn't care much | |
| 19:15:10 | gmann | but does nova says console can be available for before guest become active or in shutoff state? | |
| 19:15:29 | sean-k-mooney | yes the console can be avaiable in shutoff | |
| 19:15:43 | gmann | dansmith: humm that is good point | |
| 19:15:47 | sean-k-mooney | gmann: we have a bug in the livbirt drvier where it does not find it properly | |
| 19:15:53 | dansmith | gmann: so maybe if the instance isn't scheduled to a host yet, then 400 makes sense | |
| 19:16:04 | dansmith | but after it's on a host, I dunno, seems like 200 empty is the right move always | |
| 19:16:18 | gmann | yeah, it is difficult to make differentiation on those cases | |
| 19:16:43 | dansmith | so instance.host==None, 4xxsomething, but otherwise, I'd say 200 empty | |
| 19:16:57 | gmann | +1 | |
| 19:17:12 | sean-k-mooney | hehe ok fun | |
| 19:17:12 | dansmith | I don't think there's any useful distinction between "nothing has ever been written to the console" and "the console log is gone" | |
| 19:17:24 | sean-k-mooney | dansmith: so my boot form volume guest is not using a pty | |
| 19:17:25 | dansmith | like I said, *maybe* for a windows guest with no actual console, I dunno how that works really | |
| 19:17:38 | dansmith | even macos on uefi has a text console.. it's set to silent by default, but it's there | |
| 19:17:43 | gmann | I think I got your point of action is passed so it should be 200 irrespective of what output it give | |
| 19:17:57 | dansmith | gmann: yeah | |
| 19:18:10 | sean-k-mooney | dansmith: https://paste.opendev.org/show/bvGBKyn5fHQthz8TO13C/ | |
| 19:18:25 | dansmith | sean-k-mooney: interesting | |
| 19:18:36 | sean-k-mooney | dansmith: so its using tcp for the console | |
| 19:18:47 | sean-k-mooney | and the source is still there when its stoped | |
| 19:19:06 | dansmith | yeah, I dunno why that is set that way, but I can't imagine it has much to do with being lvm | |
| 19:19:26 | sean-k-mooney | that becasue its kolla-ansible i think | |
| 19:19:36 | dansmith | yeah *that* I'd believe :) | |
| 19:19:46 | sean-k-mooney | again this is related to how libvirt is configured | |
| 19:20:05 | sean-k-mooney | since its generating that so its connecting to virtlogd over tcp in this case | |
| 19:20:37 | sean-k-mooney | well to qemu i guess not virtlogd | |
| 19:21:10 | sean-k-mooney | this deployment is using molitic libvirt | |
| 19:22:03 | sean-k-mooney | dansmith: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4464 | |
| 19:22:16 | sean-k-mooney | so if we are usign tcp we get the path form log | |
| 19:22:20 | sean-k-mooney | not source | |
| 19:22:32 | sean-k-mooney | so thats why that is working | |
| 19:22:52 | dansmith | okay but virtlogd should hide this all from us and let us use the log file yeah? | |