| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-17 | |||
| 12:33:26 | sean-k-mooney | sure | |
| 12:33:59 | kashyap | sean-k-mooney: It's the Secure Boot-related scaffolding code - I have some sketch here (and the next patch): https://review.opendev.org/682627 | |
| 12:34:02 | kashyap | (No tests yet, mind you) | |
| 12:34:14 | kashyap | sean-k-mooney: Just want a different pair of eyes; as I'm feeling weary | |
| 12:35:24 | kashyap | sean-k-mooney: The design refresher for detecting firmware auto-selection and SB-enabled OVMF is in the above commit message | |
| 12:35:30 | sean-k-mooney | no test oh easy -1 the :) | |
| 12:35:31 | kashyap | sean-k-mooney: Might want to read it, when you have a block of time | |
| 12:35:34 | kashyap | :D | |
| 12:35:44 | kashyap | sean-k-mooney: It's Workflow -1 already | |
| 12:36:42 | kashyap | Actually, I used that commit message as "documentation" (as some of that should - I will - be added in documentation) | |
| 12:36:49 | sean-k-mooney | so we need to eventually talk about the inter for use get_domain_caps | |
| 12:36:57 | sean-k-mooney | domain_caps = self.get_domain_capabilities() | |
| 12:36:59 | sean-k-mooney | for arch in domain_caps: | |
| 12:37:01 | sean-k-mooney | for machine_type in domain_caps[arch]: | |
| 12:37:07 | sean-k-mooney | i have see that way to much | |
| 12:37:09 | kashyap | sean-k-mooney: Also, see the "Firmware auto-detection in action" part in the message | |
| 12:37:18 | kashyap | Hmm | |
| 12:37:25 | sean-k-mooney | every use of it i has see so far does the nested looping | |
| 12:37:39 | kashyap | I might get actually get rid of one level of it at least | |
| 12:38:02 | sean-k-mooney | and i mentioned to aspires that i want too change the to take parmaters for arch and machine type optionally | |
| 12:38:42 | kashyap | sean-k-mooney: Yeah, that's something I want consider | |
| 12:38:51 | kashyap | I already began by taking 'arch' as the param | |
| 12:39:06 | sean-k-mooney | yes so i want to change how the fuction works | |
| 12:39:16 | sean-k-mooney | if you pass nothinbg it will work as it currently does | |
| 12:39:42 | sean-k-mooney | if you pass parmater it woul check if it in the cache and if not call libivrt with those paramater set and look it up | |
| 12:39:47 | sean-k-mooney | then cache it | |
| 12:40:12 | sean-k-mooney | the current way we use it does not actully work in all cases | |
| 12:41:43 | sean-k-mooney | kashyap: by the way im not sure the fireware changes per machinetype | |
| 12:41:45 | kashyap | Yeah, I was considering the caching approach; will keep fiddling | |
| 12:41:58 | kashyap | sean-k-mooney: Sorry, what do you mean? | |
| 12:42:22 | sean-k-mooney | well at least on x86 you use the same uefi firmware image for both pc and q35 | |
| 12:42:38 | kashyap | sean-k-mooney: You mean the firmware values returned ("uefi" / "bios") won't change per machine type? | |
| 12:42:44 | sean-k-mooney | yes | |
| 12:42:58 | sean-k-mooney | they might | |
| 12:43:18 | sean-k-mooney | but then dont on x86 anyway as far as i know | |
| 12:43:19 | kashyap | For UEFI boot, q35 is mandatory; see the next patch, please, where we handle it | |
| 12:43:32 | sean-k-mooney | no its not | |
| 12:43:42 | sean-k-mooney | at least libvirt does not require that | |
| 12:44:05 | kashyap | Hmm, /me tries :-) | |
| 12:50:30 | kashyap | Modifying existing SB-enabled VMs to 'pc' is not a good idea; as the entire PCIe topo needs to change, etc. Will test on a diff. box later today | |
| 12:51:00 | sean-k-mooney | secure boot wont work for pc | |
| 12:51:06 | sean-k-mooney | but uefi should | |
| 12:51:11 | sean-k-mooney | imy trying it locally too | |
| 12:51:27 | sean-k-mooney | but im pretty sure i have done this in the past | |
| 12:51:31 | kashyap | Right, please try it. (Yeah, that's for sure: SB won't of course work for 'pc') | |
| 12:51:56 | kashyap | But I'm also 99.9999981% sure, UEFI with OVMF won't work with 'pc' | |
| 12:53:28 | sean-k-mooney | it boots with a black scree and 100% cpu usage so it does not look like its that happy | |
| 12:53:55 | sean-k-mooney | that said i am pretty sure i did use uefi with pc machine type in the past | |
| 12:53:56 | kashyap | Yep. OVMF is 'q35' only | |
| 12:54:05 | sean-k-mooney | maybe it was a different firmware image | |
| 12:54:06 | kashyap | I bet euros-to-croissants | |
| 12:56:00 | kashyap | sean-k-mooney: Thanks for the eyes so far. | |
| 13:01:32 | openstackgerrit | Sundar Nadathur proposed openstack/nova-specs master: Nova Cyborg interaction specification. https://review.opendev.org/682637 | |
| 13:05:26 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Test heal port allocations in nova-next https://review.opendev.org/669879 | |
| 13:17:47 | gibi | mriedem: fixed your nits in ^^ | |
| 13:18:06 | gibi | mriedem: and also in https://review.opendev.org/#/c/666857 | |
| 13:18:45 | gibi | ahh you already hit the heal port patch, thanks for that | |
| 13:20:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Only allow one scheduler service in tests https://review.opendev.org/682486 | |
| 13:21:46 | mriedem | oh no a full rebase on 666857 | |
| 13:21:50 | mriedem | means i can't diff to PS7 | |
| 13:21:53 | mriedem | why gibi why | |
| 13:22:25 | gibi | mriedem: there is a separate ps for the rebase but yeah I screewed up the order of those actions :/ | |
| 13:22:28 | gibi | sorry | |
| 13:22:39 | gibi | I should have pushed the fix then the rebase | |
| 13:23:54 | bauzas | I leave it here on purpose :) https://sbauza.wordpress.com/2014/11/14/how-to-compare-2-patchsets-in-gerrit/ | |
| 13:24:27 | bauzas | (pretty old but still accurate :) ) | |
| 13:24:36 | sean-k-mooney | bauzas gitreview -m does not always work | |
| 13:25:08 | sean-k-mooney | you need to do a 4 way diff | |
| 13:25:24 | sean-k-mooney | which i think is what you came up with later | |
| 13:25:48 | bauzas | sean-k-mooney: this post was made in 2014 | |
| 13:26:15 | bauzas | (and then I stopped writing stupid things) | |
| 13:27:01 | sean-k-mooney | vimdiff <(git diff ${MY_PS1_BRANCH}^ ${MY_PS1_BRANCH}) <(git diff ${MY_PS2_BRANCH}^ ${MY_PS2_BRANCH}) | |
| 13:27:12 | sean-k-mooney | is bassicaly a 4 way diff | |
| 13:27:24 | sean-k-mooney | so that will do what you want and eliminate rebase changes | |
| 13:29:33 | sean-k-mooney | i kind of want to add that to git review at some point | |
| 13:30:21 | sean-k-mooney | that said i more want it to be in gerrit which is thould be if/when we upgrade the openstack gerrirt to the polomer ui | |
| 13:30:59 | bauzas | sean-k-mooney: yeah, true and false, it's a diff of diffs | |
| 13:31:08 | sean-k-mooney | yes | |
| 13:31:25 | bauzas | I just use vimdiff because the UI makes the diff most easier to read and catch the differences | |
| 13:31:47 | sean-k-mooney | i dont use vimdiff but i like meld | |
| 13:31:58 | bauzas | but you could technically stick with diff (with -y, side-to-side) and just grep a few things | |
| 13:31:59 | stephenfin | sean-k-mooney: They won't accept it | |
| 13:32:00 | sean-k-mooney | i rarely use it but when i do it works well | |
| 13:32:02 | stephenfin | They being infra | |
| 13:32:10 | sean-k-mooney | stephenfin: why not | |
| 13:32:26 | stephenfin | Something about git-review being a dead simple tool that shouldn't grow any additional functionality | |
| 13:32:32 | stephenfin | which I kind of get | |
| 13:32:36 | bauzas | meld works too, I mean litterally any decent editor that supports merge diffs | |
| 13:32:39 | sean-k-mooney | it already has -m | |
| 13:32:46 | stephenfin | it probably shouldn't have that | |
| 13:32:48 | bauzas | -m has a very different behaviour | |
| 13:33:02 | sean-k-mooney | if you dont do the rebase in -m its the same | |
| 13:33:17 | bauzas | the 'if' makes the difference | |
| 13:33:32 | sean-k-mooney | as you said -m rebase both to master to elimitate the need to diff diffs | |
| 13:33:50 | sean-k-mooney | but both are trying to do the same thing | |
| 13:34:04 | bauzas | correct but then you have to handle merge conflicts if they occur | |
| 13:34:04 | sean-k-mooney | elimiate chagne that are not part of your actual patch | |
| 13:34:18 | bauzas | that's unnecessary work on my opinion | |
| 13:34:28 | sean-k-mooney | yes whcih is why i dont like how -m works | |
| 13:34:31 | sean-k-mooney | yep | |