| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-30 | |||
| 07:56:18 | PrinzElvis | gibi> Thks | |
| 09:46:32 | openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-audit: Use cliff instead of homegrown argparse bleh https://review.opendev.org/724332 | |
| 10:35:06 | kashyap | sean-k-mooney: Hope my response clarifies on some of our disagreements here: https://review.opendev.org/#/c/631154/7 | |
| 10:35:40 | kashyap | sean-k-mooney: I wasn't assuming anything particular on your part, but asking to explicitly clarify with me what I meant | |
| 10:35:56 | kashyap | sean-k-mooney: As noted there, at one point in the past, QEMU *did* allow 'i440fx' + plain UEFI boot | |
| 10:36:13 | kashyap | (As noted in the spec comment, Nova doesn't allow that; we know that. Not debating that at all.) | |
| 10:36:28 | kashyap | Anyway, we can sort it out on the change. No rush to respond | |
| 11:43:10 | artom | nightmare_unreal, yeah, I'll look | |
| 11:43:26 | nightmare_unreal | Thanks :) | |
| 11:43:27 | artom | nightmare_unreal, nova-live-migration checks... live migration :) | |
| 11:43:49 | artom | It's unlikely to be related to your patch, most likely random failure | |
| 11:44:14 | nightmare_unreal | yes that's what I meant. WHy it was failing because I didn't touched anything with migration | |
| 11:49:29 | openstackgerrit | Jiri Suchomel proposed openstack/nova master: Add ability to download Glance images into the libvirt image cache via RBD https://review.opendev.org/574301 | |
| 12:08:52 | artom | nightmare_unreal, somethings things fail :) | |
| 12:10:06 | artom | In this case looks like a server evacuation timed out: https://zuul.opendev.org/t/openstack/build/8ac593dc86074d128b16ae0796e9e458/log/job-output.txt#8481 | |
| 12:11:51 | lyarwood | artom: it failed | |
| 12:12:13 | lyarwood | artom: the timeout is just because we are waiting for the instance to go to ACTIVE but it's always in ERROR | |
| 12:12:26 | artom | lyarwood, oh, right | |
| 12:12:49 | artom | In any case, it cannot possibly because of the changes to nova-manage heal_allocations :) | |
| 12:13:04 | lyarwood | '[' ERROR '!=' ERROR ']' | |
| 12:13:06 | lyarwood | erhm | |
| 12:13:31 | lyarwood | oh ignore that | |
| 12:14:03 | lyarwood | artom: but yeah sorry | |
| 12:14:06 | lyarwood | unrelated | |
| 12:22:32 | lyarwood | this looks like another VIF timeout issue, I wonder if we also need to remove the OVS ports etc before restarting the agents and attempting the rescue. | |
| 12:22:38 | lyarwood | evacuation even | |
| 12:25:29 | sean-k-mooney | lyarwood: you should not need too | |
| 12:26:04 | sean-k-mooney | we cenrtenly cant assume that will happen in a evacuate case | |
| 12:27:40 | lyarwood | well the host should be fenced in an evacuation | |
| 12:28:25 | lyarwood | https://review.opendev.org/#/c/723853/ - I was going to add that as a precondition FWIW | |
| 12:28:48 | lyarwood | but yeah I don't think that would actually help here | |
| 12:40:55 | artom | Who handles http://status.openstack.org/reviews/#nova ? | |
| 12:41:06 | artom | "Page refreshed at 2020-03-20 06:38:57 UTC" | |
| 12:41:09 | artom | Kinda stale ;) | |
| 12:41:24 | gibi | artom: I suggest to ask infra | |
| 12:41:54 | gibi | I've noticed the staleness of it but never get the time to dig around | |
| 12:42:01 | sean-k-mooney | i tink it updates automaticaly nightly | |
| 12:42:14 | gibi | it is just a looooong night :) | |
| 12:42:29 | sean-k-mooney | oh its 03 not 04 | |
| 12:42:47 | artom | Yeah, this ain't Game of Thrones | |
| 12:42:49 | sean-k-mooney | adn the 20th not 30th | |
| 12:43:03 | sean-k-mooney | ya just misreda the date | |
| 12:43:55 | sean-k-mooney | i mix up numbers much less often then letters but it somethimes happens | |
| 12:54:07 | kashyap | Urgh | |
| 12:54:19 | kashyap | Rabit-Holes-- | |
| 12:54:53 | kashyap | sean-k-mooney: I'm just reading your comment: right now 'i440fx' with UEFI *does not* work. I wrote to the OVMF maintainer to ask about what's the deal there | |
| 12:55:19 | sean-k-mooney | kashyap: i think it was just not implemented | |
| 12:55:22 | kashyap | sean-k-mooney: So, don't assume that: "it works with both" _today_. As I mentioned in my comment it was working at _one_ point_ in time... | |
| 12:55:29 | kashyap | sean-k-mooney: So, the core problem is this: | |
| 12:55:38 | sean-k-mooney | given its like 20 years old im not suprised it was not a priortiy | |
| 12:56:34 | kashyap | The 'i440fx' chipset does not have SMM emulation: hence Secure Boot is not possible with it. If someone adds SMM to 'i440fx', SB should work 'fine' for it. | |
| 12:56:43 | kashyap | (But indeed it's not a priority to do that) | |
| 12:57:05 | sean-k-mooney | kashyap: by the way im not assumeing ti works with both | |
| 12:57:08 | kashyap | I'll comment the rest on the change. | |
| 12:57:32 | kashyap | sean-k-mooney: You say on the change in the past OVMF_CODE.secboot.fd didn't work with 'i440fx' | |
| 12:57:38 | kashyap | That's of course correct -- it never wored | |
| 12:57:41 | kashyap | s/wored/worked/ | |
| 12:57:59 | sean-k-mooney | yes the .secboot one did not | |
| 12:58:16 | sean-k-mooney | and the release note you quoted state that the OVMF_CODE.fd file did | |
| 12:58:20 | kashyap | The non-secboot.fd used to work in the past. Right now, it drops me directly to the UEFI shell. | |
| 12:58:36 | kashyap | sean-k-mooney: Yes, it did in December-2016. Today, it didn't. Still checking what's the state of it | |
| 12:58:57 | kashyap | There's only one responsive OVMF maintainer/developer that I know; and he's terribly overworked | |
| 12:59:05 | sean-k-mooney | well OVMF_CODE.fd is just uefi firmware | |
| 12:59:18 | sean-k-mooney | secure boot is an optional feature | |
| 12:59:33 | sean-k-mooney | it might be that the droped support form loadign the firmware form rom | |
| 12:59:49 | sean-k-mooney | i think pflash was not supported on i440fx | |
| 13:00:15 | sean-k-mooney | i tried to get uefi without secure boot wokking with the pc type a few times in teh past | |
| 13:00:22 | sean-k-mooney | but i have only had success using q35 | |
| 13:00:42 | sean-k-mooney | using the ovmf binarys in ubuntu 16.04 and 18 | |
| 13:00:45 | sean-k-mooney | .04 | |
| 13:01:35 | sean-k-mooney | i have not really gone out of my way to get upstream copies or anything like that but i have had to check uefi stuff on 1-2 ocations in the past and just always ended up going to q35 | |
| 13:02:44 | sean-k-mooney | anyway i think we can ignore that part of the spec as it really not relevent to chanign the default in nova | |
| 13:03:08 | sean-k-mooney | it is relevent for your secure boot spec but not this one | |
| 13:09:18 | kashyap | 1 sec; bbiab | |
| 13:10:19 | kashyap | sean-k-mooney: I've checked how UEFI / OVMF is built for Ubuntu and Debian and SUSE as part of some earlier work: | |
| 13:10:23 | kashyap | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 | |
| 13:10:23 | openstack | Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Fixed] | |
| 13:10:27 | kashyap | (And other bzs) | |
| 13:11:01 | sean-k-mooney | kashyap: sure but its really not relevent to this spec at all | |
| 13:11:06 | kashyap | It's all well-known mess. Anyway, I'm going into a rabbit hole | |
| 13:11:26 | sean-k-mooney | can we jsut drop this topic and remove it form the spec or put it in the refrences section | |
| 13:12:42 | kashyap | sean-k-mooney: I won't just drop it, I want to highlight the advantage it brings. Having given talks at various conferences, admins often ask me: 'tell me more about what 'q35' brings' | |
| 13:12:47 | sean-k-mooney | its not material to the topic of changing the default | |
| 13:12:50 | kashyap | But anyway, for now I'll take a break... | |
| 13:12:57 | kashyap | sean-k-mooney: Yes, it's not. Whoever said that? | |
| 13:13:17 | sean-k-mooney | that what the problem desictiopn section of the spec is ment to cover | |
| 13:13:52 | kashyap | Yeah, I'll move it to a separate section - it's just a matter for formatting. I wasn't intentioanlly making it "part of problem description" | |
| 13:18:38 | sean-k-mooney | ok that is what https://github.com/openstack/nova-specs/blob/master/specs/victoria-template.rst#references is for. | |
| 13:19:22 | artom | If this was an internal call I'd cut you off and move on to the next topic ;) | |
| 13:19:55 | sean-k-mooney | hehe that is why i said can we drop this topic. i ment talking about it not the content | |
| 13:22:17 | kashyap | sean-k-mooney: Aside: 'pflash' is very much supported on 'i440fx' on QEMU ("-drive if=pflash") | |
| 13:23:03 | sean-k-mooney | good to know is it the other way around then. i tought one of the two machine types only supported one option | |
| 13:23:22 | sean-k-mooney | e.g. one supported pflash and the other supproted pflash and rom | |
| 13:23:54 | sean-k-mooney | so maybe q35 only support rom or i jsut had an error in my libvirt xml when i tried it in the past | |
| 13:26:13 | kashyap | Perhaps; for later reading, if you want to learn more, look up: "Configuring pflash devices for OVMF firmware" (an outstanding 'qemu-devel' thread) -- it has all the truths from a maintainer | |
| 14:00:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.opendev.org/530487 | |
| 14:00:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add an online migration for PciDevice.uuid https://review.opendev.org/530905 | |
| 14:38:22 | sean-k-mooney | stephenfin: my javascript is terible but you know the code injector thing you got use to use for bugzilla. http://paste.openstack.org/show/792950/ fixes gerrit so you can copy text form gerrit comments again | |
| 14:39:00 | sean-k-mooney | just create a new rule for code injector with review\.opendev\.org as the host and that as the content | |
| 14:39:20 | stephenfin | Oh, sweet. Thanks! | |