| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 18:06:52 | aspiers | Now that sounds like it could be a good reason | |
| 18:06:55 | cdent | nothing is present is in placement to do a reverse sync | |
| 18:07:02 | aspiers | Gotcha | |
| 18:07:25 | aspiers | In any case, it's trivial to ditch the removal from the spec, and I'm happy to do that | |
| 18:07:40 | cdent | that wasn't the reason why we can't remove, but once we decided we -weren't- going to remove, then it became safe for the sync mechanism to be that | |
| 18:07:40 | aspiers | I just wanted to understand the rationale out of curiosity ;-) | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | |
| 18:07:52 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 18:07:53 | aspiers | Yep that makes sense | |
| 18:07:53 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 18:08:18 | cdent | but the general ideas was simply: an extensible only enumeration is easier to manage than one than can be shrunk | |
| 18:08:32 | aspiers | Sure | |
| 18:08:39 | aspiers | OK, so it stays | |
| 18:08:49 | aspiers | In that case I'll just need to amend the docs to say not to use it for anything | |
| 18:08:58 | cdent | yeah, that's probably a good idea | |
| 18:09:02 | efried | Yeah, I kept trying to phrase that in terms of this specific trait, where it doesn't necessarily apply. That wasn't the most convincing approach. | |
| 18:09:15 | efried | thanks for the save cdent | |
| 18:09:18 | efried | :* | |
| 18:09:29 | cdent | :hugs: | |
| 18:09:53 | cdent | It does suggest that we probably need some kind of "are you really really sure" mechanism when we start adding traits | |
| 18:10:06 | cdent | when these went by I don't remember them seeming bad or suspect in any way | |
| 18:10:06 | sean-k-mooney | i am trying to think is there still a usecase for the trait but with the resouce class approch not really | |
| 18:10:20 | cdent | so it _might_ be that they are still okay in general, just not for this use | |
| 18:10:25 | sean-k-mooney | the only one i have is a forbiden trait | |
| 18:10:27 | aspiers | efried: Your idea of combining the resources: extra spec with an AMD trait is a nice idea. We're into bikeshedding territory now which is probably not ideal when formulating specs, but it is *conceivable* (if not likely) that in the future AMD might release another memory encryption technology - I dunno, maybe SEV2 or something | |
| 18:10:39 | sean-k-mooney | e.g. i have only a few host that support SEV so please avoaid them | |
| 18:10:48 | aspiers | In that case, not having an SEV-specific resource class would be problematic | |
| 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 | sean-k-mooney | actully i was going to say that was confusing with intels SGX | |
| 18:14:23 | efried | just so. | |
| 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 | aspiers | sean-k-mooney: thanks! | |
| 18:16:19 | sean-k-mooney | aspiers: efried i take it taht we are close however on the spec? | |
| 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 | sean-k-mooney | we are ratholeing i think :) | |
| 18:22:55 | efried | but then I would need a separate flavor for every possible flag | |
| 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 | efried | Or, for that matter, SEV | |
| 18:24:33 | aspiers | haha, nor me | |
| 18:24:44 | aspiers | I know it's a CPU flag though ;-) | |