| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 17:04:10 | aspiers | darn | |
| 17:05:05 | aspiers | weird, can't see that locally | |
| 17:05:22 | aspiers | oh, wrong environment | |
| 17:05:37 | aspiers | I wonder why tox -e flake8 is allowed | |
| 17:07:18 | openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | |
| 17:07:22 | aspiers | sean-k-mooney: fixed | |
| 17:32:30 | cdent | aspiers: that's the just the unfortunate way tox works... | |
| 17:32:38 | openstackgerrit | Merged openstack/nova master: libvirt: set device address tag only if setting disk unit https://review.openstack.org/611974 | |
| 17:59:26 | efried | aspiers: Re-reviewed SEV spec | |
| 17:59:57 | aspiers | efried: thanks | |
| 17:59:58 | efried | cdent: I tried to explain there ^ why we don't ever remove things from os-traits, even if they're trash. | |
| 18:00:14 | efried | perhaps you can reinforce/augment | |
| 18:00:25 | cdent | efried: looking | |
| 18:05:12 | aspiers | efried, cdent: To "The pathological theoretical case is where somebody (not limited to nova) is on 0.11.0 or 0.12.0, sees the trait and uses it for $whatever", my question is: what could $whatever possibly be? Literally there is zero code which uses it. | |
| 18:06:05 | efried | I'm basically saying it doesn't matter | |
| 18:06:06 | aspiers | And even if they somehow concocted some way to use it, that couldn't possibly relate to SEV in any way, because again there is zero SEV code merged which uses it anywhere. | |
| 18:06:32 | cdent | aspiers, efried : the additional aspect is that whenever a placement service sees a new version of os-traits it syncs up its database with the strings that are in the package, creating a row in the traits table, with an id that becomes a foreign key in other tables | |
| 18:06:40 | cdent | s/becomes/can become/ | |
| 18:06:44 | aspiers | Ahah | |
| 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 | |