Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-29
15:29:06 aspiers mriedem: nevertheless some of the SEV work is enabling stuff that kashyap and sean-k-mooney are working on, so at least it's not *entirely* selfish ...
15:29:10 sean-k-mooney im not sure which revew set ye were refering to by the way
15:29:12 mriedem anyway, i shouldn't have said anything, i'm just cranky. woken up too early, had to fix the runways etherpad, etc etc
15:29:27 mriedem aspiers: i'm not complaining about SEV stuff at all
15:29:35 sean-k-mooney aspiers: well the only depency i have on the sev work is the harding patch
15:29:41 aspiers mriedem: I know, but I was trying to boost your morale a bit ;-)
15:29:52 mriedem SEV does not boost my morale but ok
15:29:52 sean-k-mooney which is not really part of the series more a depency for my blueprint and yours
15:30:01 aspiers sean-k-mooney: sshhh, I'm trying to cheer up mriedem ;-)
15:30:13 sean-k-mooney hehe ok
15:30:17 artom Time for the Riderman song?
15:30:23 aspiers sean-k-mooney: also you got the getDomainCapabilities code from me for free
15:30:29 cdent oh, I misunderstood. I was trying to mriedem more sad.
15:30:33 aspiers haha
15:30:36 sean-k-mooney aspiers: yes but i technically never needed it
15:30:43 aspiers bah :)
15:30:58 aspiers sean-k-mooney: what about https://review.opendev.org/#/c/673151/, maybe that is useful for you too
15:31:01 sean-k-mooney aspiers: im just using it since its there
15:31:17 kashyap aspiers: Selectively reading the scroll
15:31:36 sean-k-mooney i havenet seen that patch before. so i dont know
15:31:37 kashyap aspiers: Hehe, so long as you're in the console, good. My assistance is over ;-)
15:31:40 aspiers mriedem: I mean, I was trying to cheer you up by saying that I'm hoping to contribute more than just SEV and its peripheries
15:31:53 aspiers sean-k-mooney: I wrote it on Sat
15:32:14 aspiers sean-k-mooney: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-07-27.log.html#t2019-07-27T18:15:17
15:32:21 sean-k-mooney aspiers: but i would prefer to merge teh code i have and then see if we can refactor later
15:32:45 aspiers sean-k-mooney: it's not a refactor and I don't think it overlaps with your changes
15:32:56 aspiers well there is a bit of refactoring in there
15:33:01 aspiers but that's not the main point
15:33:05 aspiers anyway gotta go again
15:33:07 aspiers biab
15:37:02 kashyap mriedem: Yes, to be fair -- parts from SEV work in Nova _do_ help the Secure Boot stuff and some of what Sean's doing.
15:37:51 aspiers I wasn't trying to portray SEV as the saviour of nova ;-) or even anything significantly helpful. Just stating my wish to contribute more to nova *beyond* SEV in the future
15:38:11 aspiers I've already done bits and pieces here and there
15:38:16 aspiers but would like to do more
15:38:30 kashyap aspiers: Heh, you don't need to defend yourself _that_ much by feeling like you're walking on some eggshells.
15:39:26 kashyap It's good work, and enables a useful and imporant usecase.
15:39:32 aspiers sure, I don't feel under attack either ;)
15:40:13 kashyap Okido; then let's keep maintaining our inner tranquility..
15:41:14 kashyap s/.././
15:42:41 eandersson sean-k-mooney, I tried to backport the prelude patch needed for
15:42:42 eandersson https://review.opendev.org/#/c/672855/
15:42:52 eandersson but I think I'll have to leave that for someone else
15:42:59 eandersson So many changes between Stein and Rocky on that front
15:56:20 sean-k-mooney eandersson: sure once its merged on master then people on teh stable/core teams will be able to backport it if needed or i can try to take a look
16:10:15 aspiers kashyap: does this look capable? http://paste.openstack.org/show/755079/
16:10:18 aspiers I don't see any shims
16:21:20 aspiers kashyap: so grub actually shows secure boot enabled!
16:21:22 efried phew, glad alex_xu and stephenfin were able to approve that get_domain_capabilities() patch. I was having nightmares.
16:21:32 aspiers hehe
16:21:47 eandersson Sounds good sean-k-mooney
16:22:00 sean-k-mooney i commented on the review by the way
16:22:02 aspiers efried: if that gave you nightmares, I dread to think what https://review.opendev.org/#/c/673151/ will do
16:22:22 sean-k-mooney just pointing out that it may change the message if we dont actully through the exception
16:22:23 efried ahcrap, is that *also* blocking the SEV work?
16:22:30 sean-k-mooney but i have not confimed that
16:22:39 aspiers efried: it's the first in the series
16:22:47 aspiers so, yeah :)
16:23:18 eandersson Yea - I wasn't sure if that was the case.
16:24:06 efried okay, so look, I'm probably not going to be able to +2 the super-libvirty things in that series, but as long as you've got folks like alex_xu and stephenfin to look, I guess you should be okay.
16:24:06 sean-k-mooney eandersson: worst case it just wont have a stack trace pointing to where it was thrown
16:24:16 sean-k-mooney because it was not raised
16:24:35 sean-k-mooney best case it will have a stack trace that point to where it was constucted
16:24:49 sean-k-mooney which is basically where we would have raised it before
16:25:08 openstackgerrit Vladyslav Drok proposed openstack/nova master: [libvirt] Check if domain is persistent on cleanup https://review.opendev.org/673332
16:25:43 aspiers efried: I've added them. Next one is https://review.opendev.org/#/c/638680/ which you were previously +2 on. I think pretty much only changes since then have been to fix your nits and rebase
16:26:21 aspiers PS27 was +2 W+1
16:27:16 efried ack. I've been procrastinating due to the prereqs. Was hoping to dive in again this week.
16:27:28 aspiers efried: oh, and also fixing tests which never got run before: https://review.opendev.org/#/c/638680/30..31/nova/tests/functional/libvirt/test_report_cpu_traits.py
16:28:05 aspiers so if you're happy with that ^^ and trust my rebasing skills then I guess it should be easy to recycle your previous +2 W+1
16:29:42 sean-k-mooney eandersson: efried based on a simple test in the repel it will have no traceback
16:29:45 sean-k-mooney >>> val_error = ValueError()
16:29:46 sean-k-mooney >>> val_error.__traceback__
16:29:48 sean-k-mooney >>>
16:30:13 sean-k-mooney >>> raise val_error
16:30:15 sean-k-mooney Traceback (most recent call last):
16:30:17 sean-k-mooney File "<stdin>", line 1, in <module>
16:30:19 sean-k-mooney ValueError
16:30:39 sean-k-mooney >>> val_error.__traceback__
16:30:41 sean-k-mooney <traceback object at 0x7fc44ac5db48>
16:30:46 efried aspiers: yup. But urgency again reduced by the fact that there's a big not-reviewable-by-me thingy in front of it again/still.
16:30:51 sean-k-mooney so it looks like the tracback is only compute when its raised
16:30:57 efried sean-k-mooney: ack, but that only matters if the traceback is being used somewhere up the chain
16:31:00 efried which afaict it isn't.
16:31:06 efried all we're doing is printing the exception
16:31:11 efried which is the same whether it's raised or not.
16:31:14 sean-k-mooney its not its just being logged
16:31:19 efried right
16:31:26 sean-k-mooney so i dont know if we care
16:31:29 efried I didn't -1 before
16:31:32 efried right, I don't know either.
16:31:37 sean-k-mooney i think we dont
16:31:42 efried I would have accepted either explanation, really.
16:31:55 sean-k-mooney just you were asking if they were the same and they technically arnt
16:32:01 efried Even if we want to say "this is future proofing in case someone wants to print this stack trace somewhere"
16:32:03 sean-k-mooney but not in a way that matters for our usecase
16:32:12 efried ++ thanks for the clarification.
16:32:53 sean-k-mooney ill copy that example into a comment and change my +0 to a +1
16:53:38 mriedem eandersson: re https://review.opendev.org/#/c/672855/ i might write a functional regression test for the issue (separate patch) and stack your change on top
16:53:48 mriedem that code is too shitty for just unit tests
16:54:00 eandersson Yea that would be great

Earlier   Later