| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-30 | |||
| 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 | openstack | Debian bug 932269 in ovmf "Ship the firmware "descriptor files" as part of the 'ovmf' package" [Normal,Fixed] | |
| 13:10:23 | kashyap | https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932269 | |
| 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: Add an online migration for PciDevice.uuid https://review.opendev.org/530905 | |
| 14:00:52 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Modify PciDevice.uuid generation code https://review.opendev.org/530487 | |
| 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! | |
| 14:40:56 | sean-k-mooney | acutlly i think i can make it simpler | |
| 14:43:23 | sean-k-mooney | stephenfin: ya so this work and is less dumb http://paste.openstack.org/show/792952/ | |
| 14:44:09 | sean-k-mooney | i proably could just make it modify the one element that was chagne but it works so its fine | |
| 14:57:30 | openstackgerrit | Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684 | |
| 14:58:52 | gmann | dansmith: replied on this comment if that make sense ? -https://review.opendev.org/#/c/723645/8/nova/cmd/status.py@391 | |
| 14:59:24 | gmann | i think checking single base rule is enough to catch the auto generated file with new default. | |
| 15:00:13 | gmann | dansmith: or we can check for these set of base rule which are default of every other rules - https://github.com/openstack/nova/blob/730eeb5fe002c093a5b477e095c3374457820007/nova/policies/base.py#L48-L54 | |
| 15:00:33 | dansmith | gmann: okay, it was genuinely a question, not an assertion that we should do something different.. do we have any policy rules that were added in U that wouldn't be in the policy file unless they were added by the generator? | |
| 15:01:57 | gmann | dansmith: yeah we have few which were made granular. but if old name rule present in file which will be with old default keep working | |
| 15:02:46 | gmann | example - https://github.com/openstack/nova/blob/master/nova/policies/agents.py | |
| 15:03:15 | gmann | 'os_compute_api:os-agents' was old and 'os_compute_api:os-agents:*' are new rule | |
| 15:04:40 | dansmith | gmann: yeah, so if we have a totally new rule name, and that's in the file with the new default value, then that's a really good indication that they just generated the file right? | |
| 15:05:10 | dansmith | gmann: I guess the other way to look at it is: if we check *all* the rules, and warn if any are scope-checing, but the config doesn't have scope turned on, then that's a warning, regardless right? | |
| 15:05:19 | gmann | dansmith: yeah and SYSTEM_ADMIN_API which are checking is also new rule. | |
| 15:05:27 | dansmith | meaning, regardless of whether they generated the file, or if they think they've written the policy file correctly | |
| 15:08:00 | gmann | enforce_scope value check i can add. so checking all the base rule which are defaults for all other rules with enforce_scope check can cover that case also - https://github.com/openstack/nova/blob/730eeb5fe002c093a5b477e095c3374457820007/nova/policies/base.py#L48-L54 | |
| 15:08:37 | dansmith | okay | |
| 15:08:41 | gmann | otherwise verifying the whole file with correct or not is very difficult as they can have their own new override value with scope or without | |
| 15:09:07 | dansmith | I know, but if they do so with scope, but have scope disabled, that won't work right? | |
| 15:09:23 | dansmith | or do you just mean that parsing all the potential options is difficult? | |
| 15:09:34 | gmann | yeah parsing. | |
| 15:09:47 | dansmith | either way, it's fine.. if system_admin_api is new, and you check the config variable, then that's good enough I think | |
| 15:09:51 | dansmith | okay, gotcha | |
| 15:10:05 | gmann | ok, modifying. | |
| 15:10:19 | dansmith | thanks for doing this | |
| 15:11:07 | gmann | dansmith: np!, thanks for all those review, learnt a lot of thing on upgrade stuff :) | |
| 15:11:44 | dansmith | :) | |