Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-17
12:24:14 kashyap +NEXT_MIN_LIBVIRT_VERSION = (4, 0, 0)
12:24:14 kashyap We gave heads-up to bump Train to these:
12:24:28 kashyap ... in Sep 2018 (commit: 489b5f762e2c828354362667cd647086dc4eed60)
12:25:01 stephenfin kashyap: Sounds like something you might want to bring up at the team meeting
12:25:04 kashyap stephenfin: Think we're too late to do _that_, I suppose -- as people don't like the bump at the end of the release
12:25:31 kashyap stephenfin: Yeah, I take full accountability of not doing it in time earlier in the release :-( Just dropped through the cracks
12:26:03 shilpasd Eric: mriedem: thanks for setUp cleanup https://review.opendev.org/#/c/682475/
12:26:30 kashyap stephenfin: Ah, the meeting is today
12:26:52 sean-k-mooney kashyap: i pesonally dont like that how we do the bumps in general.
12:26:56 kashyap stephenfin: My guess: Matt(R) will (correctly) dislike it...
12:27:16 sean-k-mooney but as i said we can bump early in U
12:27:29 kashyap sean-k-mooney: Like how we announce up ahead what we'll bump in the next release, and actually bump in the said release?
12:27:37 kashyap Any alternatives welcome :-)
12:27:49 kashyap sean-k-mooney: Yes, early U is fine. We've done such a thing before
12:27:54 efried shilpasd: yw, that would have been a tough one to spot
12:32:44 sean-k-mooney anyway there have been several realses in the past were we did not bump
12:32:52 kashyap sean-k-mooney: While I have you here, can I borrow you brain for a bit more on an unrelated thing...
12:32:56 sean-k-mooney in fact i woudl say it more common not too looking at the table
12:33:16 kashyap sean-k-mooney: Yep, indeed...
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

Earlier   Later