| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-30 | |||
| 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 | :) | |
| 15:23:28 | openstackgerrit | Merged openstack/nova stable/stein: Add retry to cinder API calls related to volume detach https://review.opendev.org/722783 | |
| 15:41:28 | kashyap | sean-k-mooney: FYI, one last on this: i440fx + regular UEFI boot (with OVMF) is a valid upstream configuration -- OVMF maintainer just confirmed | |
| 15:41:52 | kashyap | sean-k-mooney: I just did a fresh test, and it works. (Previously, my test was broken: I didn't have an EFI partition) | |
| 15:41:55 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: objects: Add migrate-on-load behavior for legacy NUMA objects https://review.opendev.org/724381 | |
| 15:42:08 | kashyap | sean-k-mooney: Evidence: https://kashyapc.fedorapeople.org/libvirt_plain_UEFI_i440fx_f31_a.xml and https://kashyapc.fedorapeople.org/QEMU_plain_UEFI_i440fx_f31_a.txt | |
| 15:47:01 | openstackgerrit | Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684 | |
| 15:50:50 | gibi | nova meeting starts in less then 10 minutes on #openstack-meeting-3 | |
| 15:51:26 | openstackgerrit | Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684 | |
| 16:04:36 | melwitt | elod, lyarwood: could I pls get review on https://review.opendev.org/723050 when you have a chance later? | |
| 16:05:09 | lyarwood | melwitt: ack looking | |
| 16:06:29 | elod | melwitt: will do that in ~1-2 hrs | |
| 16:07:01 | melwitt | thanks | |
| 16:10:27 | openstackgerrit | Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684 | |
| 16:15:49 | sean-k-mooney | kashyap: ok i guess i just has an invalid config i was try to convert an existing instance but now that i think about it i proably also did not have a biosboot partion or a gpt partion table for that matter in the vm since it was originally booted wit a legacy bios | |
| 16:16:01 | sean-k-mooney | so ya that is proably the same issue i hit | |
| 16:16:08 | kashyap | Yes, having an EFI partition is critical :) | |
| 16:25:48 | stephenfin | lyarwood, melwitt: Two noddy patches for a stable core here https://review.opendev.org/#/c/722961/ https://review.opendev.org/#/c/722962/ | |
| 16:26:39 | lyarwood | stephenfin: ack looking | |
| 16:27:20 | lyarwood | oh openstack/placement | |
| 16:27:26 | lyarwood | stephenfin: I'm not a stable core theree | |
| 16:27:29 | lyarwood | there* | |
| 16:27:45 | stephenfin | then who is? | |
| 16:27:52 | stephenfin | I honestly expected to be in that group :/ | |
| 16:27:57 | melwitt | ah, me neither. and no I did not know the word "noddy" :) | |
| 16:28:57 | lyarwood | I now have the song stuck in my head, thanks stephenfin | |
| 16:29:30 | lyarwood | stephenfin: https://review.opendev.org/#/admin/groups/1938,members - we might want to fix this | |
| 16:29:49 | lyarwood | stephenfin: something for the ptg, the project just came up in the meeting anyway FWIW | |
| 16:30:27 | lyarwood | stephenfin: https://review.opendev.org/#/admin/groups/1936,members - tbh you and others who are already cores should be copied across | |
| 16:32:18 | stephenfin | efried: any chance of adding nova-stable-maint to placement-stable-maint, assuming you think that makes sense? | |
| 16:32:26 | lyarwood | or that | |
| 16:32:52 | stephenfin | why wait ¯\_(ツ)_/¯ | |
| 16:33:17 | stephenfin | efried: https://review.opendev.org/#/admin/groups/540,members and https://review.opendev.org/#/admin/groups/1938,members fwiw | |
| 16:36:59 | efried | stephenfin: I don't think I haven any control over stable anything. | |
| 16:37:23 | stephenfin | you're in placement-stable-maint so this might be the sole exception :) | |
| 16:37:34 | efried | o rite | |
| 16:40:12 | efried | stephenfin: I don't think it makes sense to include by group. I could cherry pick names that make sense, like dansmith and melwitt. But if someone is in nova-stable-maint but not in stable-maint-core it's because they know nova, which doesn't necessarily mean they know placement. | |
| 16:41:32 | efried | Added dansmith and melwitt. | |
| 16:41:39 | stephenfin | I've found these things to be self-selecting, personally. I'm stable core in all oslo stuff but there are backports I won't touch with a stick because I don't grok them (anything oslo.concurrency, for one) | |
| 16:41:43 | stephenfin | but that's fair | |
| 16:44:00 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645 | |
| 16:44:31 | efried | Having had two no-longer-working-in-openstack names on the list before was understandably brittle, esp considering stable-maint-core really only has one member who's active. But Dan and Mel should be able to bootstrap it from here as appropriate. | |
| 16:46:47 | gibi | efried: thanks for fixing that up | |
| 16:48:21 | dansmith | bauzas: are these proposed yet? I don't see them if you're the owner | |
| 16:48:30 | bauzas | dansmith: artom | |
| 16:49:35 | bauzas | dansmith: https://review.opendev.org/#/q/topic:placement-audit-backport+(status:open+OR+status:merged) | |
| 16:49:54 | bauzas | he proposed the patches, I just expressed the opportunity to un-DNM them | |
| 16:50:17 | dansmith | that's quite a stack of dependencies too | |
| 16:50:38 | artom | dansmith, the stein one is the last self-contained one, and even then it's kinda fugly | |
| 16:50:45 | artom | rocky's a horror (picture show) | |
| 16:50:47 | artom | :D | |
| 16:53:22 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/723645 | |
| 17:04:22 | dansmith | artom: so looking at it, the train one isn't terrible, and if it's really likely that people will need this then I guess it's okay, although I feel like having outstanding issues would be a stronger case | |
| 17:04:41 | dansmith | especially since they can fix one-off issues with osc-placement quite easy, and there are community tools to do it | |