Earlier  
Posted Nick Remark
#openstack-nova - 2019-04-18
18:11:28 aspiers sean-k-mooney: that's an interesting idea. Maybe could be done with anti-affinity scheduler somehow?
18:11:35 efried aspiers: Well now, this could be an argument for use of the trait :)
18:11:39 efried in the future
18:12:01 aspiers ... based on the premise that you can do anti-affinity for traits but not resources?
18:12:07 sean-k-mooney aspiers: well if we report both the inventory of the sev resouce class + add the sev trait to the RP
18:12:32 sean-k-mooney then operators can do it by just adding a forbidon trait to there non sev flavor
18:12:33 cdent Having provided a tiny bit of useful information, I think I'm going to bow out. Since those of you who will be in denver, in denver.
18:12:42 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640207
18:12:45 cdent s/Since/See/
18:12:46 aspiers sean-k-mooney: I'm fine with that (the trait provision code is already written)
18:12:49 cdent sigh
18:12:50 aspiers cdent: looking forward to it!
18:12:58 sean-k-mooney cdent: o/
18:12:59 efried I care that my memory encryption is done specifically with SEV2: resources:MEM_ENCRYPT_CONTEXT=1,trait:HW_CPU_AMD_SEV2=required
18:13:23 aspiers efried: right, so we're back to traits then ;-)
18:13:44 aspiers Playing devil's advocate, are there any downsides to sort of duplicating info between a resource class and a trait?
18:13:45 sean-k-mooney please dont call it MEM_ENCRYPT_CONTEXT
18:13:51 efried For now, since there's only one way to do it, we don't need to use the trait
18:14:16 aspiers efried: OK, so we could just declare the trait as reserved for potential future use?
18:14:23 efried just so.
18:14:23 sean-k-mooney actully i was going to say that was confusing with intels SGX
18:14:33 sean-k-mooney but SGX does not encrypt
18:14:52 efried aspiers: As for the duplication question: IMO it would be nice to strive to not duplicate anything ever.
18:15:01 aspiers sean-k-mooney: right, Intel has MKTME instead
18:15:20 sean-k-mooney ya
18:15:25 aspiers efried: +1 ;-)
18:16:00 sean-k-mooney ok im going to have dinner ill try and review the sepc again before i sign off for the long weekend
18:16:19 sean-k-mooney aspiers: efried i take it taht we are close however on the spec?
18:16:19 aspiers sean-k-mooney: thanks!
18:16:32 aspiers it feels close to me but I'm usually over-optimistic
18:16:39 efried aspiers: The inventory (resource class) is telling you how many of a thing your provider can give. The trait is telling you characteristics of the provider. I don't really see a difference between VCPU:1&HW_CPU_X86_AVX512F:required and MEM_ENC_CTX:1&HW_CPU_AMD_SEV:required
18:17:03 efried aspiers: I feel we're close on the bits I understand, yes :)
18:17:08 aspiers hehe
18:17:21 sean-k-mooney efried: yes that is a fair comparison
18:17:51 aspiers I see a big difference actually
18:17:54 sean-k-mooney so we could have MEM_ENC_CTX:1&HW_CPU_INTEL_MKTME:required also
18:17:56 sean-k-mooney maybe
18:18:09 efried sean-k-mooney: exactly
18:18:26 efried if you don't care which technology you use, omit the traits
18:18:53 efried If you want to restrict to one (or more - I think we implemented traits=in:[list], didn't we?) use traits.
18:19:05 sean-k-mooney aspiers: i forget does the guest need to do anything to use sev
18:19:18 sean-k-mooney e.g. would an app in the guest care
18:19:29 aspiers The difference is that the presence of HW_CPU_AMD_SEV implies MCM_ENC_CTX, whereas HW_CPU_X86_AVX512F doesn't imply VCPU:1 (because AFAIK you can't have a guest without a vcpu)
18:19:33 sean-k-mooney or is it jsut something that the host/qemu need to care about
18:20:02 aspiers sean-k-mooney: just the host I think, apart from UEFI boot
18:20:07 efried aspiers: say wha? What sense would HW_*CPU*_X86_AVX512F make if you weren't using any CPUs?
18:20:44 aspiers efried: I didn't explain it very well, but my point was that VCPU:1 is essentially a no-op
18:21:01 aspiers s/1/2/ and my point is much clearer
18:21:20 efried nope, sorry, not following you.
18:21:23 sean-k-mooney i see you point but form a placement point of view a VCPU and SEV context are both jsut resouces
18:21:32 sean-k-mooney it doesnt care
18:21:38 sean-k-mooney and traits are jsut strings
18:21:49 aspiers sure, but efried was saying we should avoid duplication
18:22:08 aspiers HW_CPU_AMD_SEV implies MEM_ENC_CTX:1 therefore there is duplication
18:22:18 aspiers whereas with VCPU:2&HW_CPU_X86_AVX512F there is none
18:22:25 aspiers both constraints are needed in the latter, but not in the former
18:22:45 efried I've said I want two VCPUs. They have to support x86 AVX 512F. If I just say "I want x86 AVX 512F", you still don't know how many VCPUs I want. I could theoretically have made HW_CPU_X86_AVX512F a resource class so I could just say HW_CPU_X86_AVX512F=2
18:22:55 efried but then I would need a separate flavor for every possible flag
18:22:55 sean-k-mooney we are ratholeing i think :)
18:23:03 mriedem melwitt: heh you said the same as i did before i could post it https://review.openstack.org/#/c/653145/
18:23:19 efried and couldn't ever say "I'll accept any one of these variants"
18:23:21 efried etc etc.
18:23:34 efried That's why we have quantitative and qualitative separated.
18:23:45 aspiers I think we're on the same page, but I was responding specifically to the example you were describing as equivalent
18:23:48 melwitt mriedem: hah, nice
18:24:00 aspiers I don't think that specific example exhibits equivalence
18:24:03 efried There I go again using a poor specific example.
18:24:16 aspiers but yeah if you made HW_CPU_X86_AVX512F a resource class that would be a totally different thing
18:24:22 aspiers ;)
18:24:28 efried I actually haven't a clue what AVX512F means.
18:24:33 aspiers haha, nor me
18:24:33 efried Or, for that matter, SEV
18:24:44 aspiers I know it's a CPU flag though ;-)
18:24:46 efried just that both are qualitative characteristics of a thing.
18:25:20 aspiers anyway I have enough to go on for another patch set
18:25:25 efried cool
18:25:34 aspiers are you around much longer today?
18:25:47 aspiers just wondering if it's worth trying to get it done shortly
18:25:54 efried aspiers: was going to say, in further response to your "almost ready" question, that if we got an ack from danpb at this point, I would +2 with the discussed changes.
18:26:02 efried I'm around for at least another 3.5h
18:26:23 aspiers OK I'll try to ditch the trait removal then
18:26:35 aspiers which timezone is danpb?
18:26:55 efried ...noting of course that I still definitely want someone like jaypipes to weigh in on the using-rc-vs-trait shift.
18:26:59 efried no idea.
18:27:06 aspiers oh yeah, me too :)
18:27:13 aspiers don't know if he's around though
18:27:18 mriedem UK
18:27:21 mriedem london i think specifically
18:27:35 aspiers no way!
18:27:41 aspiers that's where I am
18:27:43 aspiers had no idea
18:27:45 mriedem he's your neighbor you weird hermit
18:27:48 aspiers haha
18:27:59 mriedem he's probably in your garden right now
18:28:09 mriedem by garden i mean "back yard"
18:28:16 aspiers I have a garden
18:28:22 aspiers communal, but I'm counting it
18:28:26 efried anyway, aspiers, I'm not sure we're shooting to get this merged today, but couldn't hurt to have a ps without a blocking issue (os-traits reduction) in it for whenever those guys do get to looking.
18:28:27 aspiers hrm, need to google a pic of him first
18:28:35 aspiers efried: agreed

Earlier   Later