| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 21:35:21 | efried | hrm, I'm actually not sure if our boots-on-the-ground CI folk are going to be attending. | |
| 21:35:37 | efried | But I believe dtroyer is the, ahem, spokesperson for the effort. | |
| 21:37:12 | sean-k-mooney | ok well 2 of the feature intel is pushing for this cycle would need 3rd part ci. | |
| 21:37:20 | sean-k-mooney | persitent memeoy and rmd | |
| 21:37:36 | efried | oh, yes, we are well aware. | |
| 21:39:33 | aspiers | sean-k-mooney: do you have a suggestion for a resource class name instead of MEM_ENCRYPTED_CONTEXT? | |
| 21:40:34 | efried | sean-k-mooney: I can see you're still working on that agenda; as you go along, if you could be thinking about what we hope to achieve in the room, that we actually need to all be in a room for, that would be neat. | |
| 21:40:36 | sean-k-mooney | if we combine it with the trait i think it fine but i was also oke with SEV_CONTEXT | |
| 21:41:08 | aspiers | efried: sean-k-mooney's earlier suggestion of trait:HW_CPU_AMD_SEV=forbidden as a valid use case has finally sunk in. It seems to me that operators could use this in flavors as soon as the SEV code merged, for keeping non-SEV guests off SEV machines. | |
| 21:41:28 | sean-k-mooney | efried: well i would like mriedem input on that | |
| 21:42:02 | aspiers | Of course this would mean providing the trait from day 0, but I'm tempted to think that it's already a compelling enough use case that maybe I should propose that in the spec | |
| 21:42:17 | sean-k-mooney | this item basicaly came form the fact the nfv ci went way(on the nova side) and we got a bunch of new numa/hardware feature requests | |
| 21:42:18 | efried | if it's important to keep SEV-capable machines free of non-SEV instances. Do we care? | |
| 21:42:32 | aspiers | I would definitely expect some operators to want that, yes | |
| 21:42:51 | sean-k-mooney | aspiers: some but not all | |
| 21:42:53 | sean-k-mooney | ? | |
| 21:42:58 | aspiers | Surely it would be likely that a compute plane would be mostly non-SEV hosts, with a few SEV hosts to cater for the more demanding customers | |
| 21:43:23 | aspiers | sean-k-mooney: sorry, you lost me - not all what? | |
| 21:43:35 | efried | Okay. Then cool, I have no problem reintroducing the trait for that purpose - and also the future purpose of being able to distinguish between different mem encryption technologies. | |
| 21:43:36 | sean-k-mooney | aspiers: i think the quest efiried is asking is it required for it to work | |
| 21:44:11 | efried | no, I was just asking whether it matters that we consume non-sev-context resources on a sev-capable machine | |
| 21:44:13 | aspiers | It's probably not *required*, but the trait is already in os-traits and the code to provide it is already working, so ... :) | |
| 21:44:31 | aspiers | efried: Yes, I think it would matter to many operators | |
| 21:44:42 | efried | aspiers: Yes, and adding the trait at the same time as you add the context inventory is trivial, and enables this use case with no additional work. | |
| 21:44:48 | aspiers | AFAIK SEV hardware is still niche (and maybe more expensive too, I dunno) | |
| 21:44:54 | aspiers | efried: exactly | |
| 21:45:03 | efried | other than that 2LOC in update_provider_tree, you get to write a paragraph in the docs. That's it. | |
| 21:45:10 | aspiers | Right | |
| 21:45:28 | aspiers | I'll mention the potential future use case too | |
| 21:45:47 | efried | except... didn't we have a better way to turn on a "don't land here" by default? | |
| 21:45:56 | efried | rather than having to put it in every non-SEV flavor? | |
| 21:46:08 | aspiers | Probably not | |
| 21:46:11 | efried | Forbidden aggregates... | |
| 21:46:19 | aspiers | Oh | |
| 21:46:27 | aspiers | And required traits would override that? | |
| 21:46:38 | efried | https://review.openstack.org/#/c/609960/ | |
| 21:47:05 | efried | it's... a little complicated. | |
| 21:47:21 | aspiers | hah | |
| 21:47:25 | aspiers | but similar looking | |
| 21:47:29 | sean-k-mooney | efried: you mean the RP forbiden traits feature i suggested liek a year ago or soemthing else | |
| 21:47:54 | sean-k-mooney | * RP required tratis | |
| 21:48:01 | sean-k-mooney | wwell actuly it was both | |
| 21:48:03 | efried | sean-k-mooney: Yes, exactly the same use case. | |
| 21:48:31 | efried | it's just, you were the only person in the world who could get their mind around reverse-required traits. | |
| 21:48:46 | sean-k-mooney | haha | |
| 21:49:02 | efried | This solution isn't beautiful, but it's at least *slightly* less confusing to mere mortals. | |
| 21:49:04 | sean-k-mooney | if only the term required traits was not already used | |
| 21:50:49 | efried | aspiers: I would have to reread that spec to understand whether the SEV trait would be applicable, or whether it would have to be a different kind of trait or aggregate somethingsomething. | |
| 21:51:27 | aspiers | Yeah | |
| 21:51:47 | efried | ah, okay, yes | |
| 21:51:55 | aspiers | Well I'll make the SEV spec raise the idea of using the trait sooner rather than later, but I'll leave it up for debate in subsequent reviews | |
| 21:52:33 | efried | so aspiers it would actually want to work more like this: you would want a generalized trait - basically exactly matching the freaking resource class - for people to isolate all their mem-enc-capable systems for mem-enc-only VMs. | |
| 21:52:39 | efried | or | |
| 21:53:01 | efried | you could still have the traits be granular, and the operator would simply have to add all of them to the agg metadata. | |
| 21:53:07 | efried | that would be fine too. | |
| 21:53:38 | sean-k-mooney | or you could not do it in placement and just have a 4 like weigher | |
| 21:53:45 | sean-k-mooney | *4 line | |
| 21:54:12 | aspiers | maybe a topic for Denver? | |
| 21:54:30 | efried | aspiers: I think it would be goodness for you to set the trait on sev-capable hosts, but not suggest any specific uses for it in the docs. | |
| 21:54:45 | sean-k-mooney | it might be intersting to have a generalised weigher that operates on traits | |
| 21:54:57 | aspiers | efried: OK, but the spec would still need to justify setting it | |
| 21:55:06 | sean-k-mooney | efried: yep i think that is a good idea too | |
| 21:55:22 | sean-k-mooney | aspiers: not really | |
| 21:55:29 | efried | aspiers: In the spec, you can mention the two cases we've discussed here: 1) When more than one mem-enc technology is available, you can use it to get a specific one; and 2) it can be used with <reference forbidden aggs spec> to keep non-SEV guests clear of SEV-capable hosts. | |
| 21:55:43 | aspiers | ack | |
| 21:55:54 | efried | "...but those impls are outside the scope of this spec." | |
| 21:56:02 | aspiers | +1 | |
| 21:56:16 | efried | and \o/ the trait is no longer trash :) | |
| 21:56:16 | sean-k-mooney | ya the ... out of scope is the imporant bit | |
| 21:56:22 | aspiers | haha | |
| 21:56:22 | sean-k-mooney | :) | |
| 21:56:49 | aspiers | but this needs to be updated still https://docs.openstack.org/os-traits/latest/reference/index.html#amd-sev | |
| 21:57:04 | aspiers | well, just the last sentence | |
| 21:57:07 | aspiers | the rest is good I think | |
| 21:57:33 | efried | hmph, that paragraph is a lie | |
| 21:57:36 | aspiers | Instead it probably needs to caution *against* relying on just trait:HW_CPU_AMD_SEV=required | |
| 21:57:47 | efried | implies that you can get SEV by specifying the trait. That's not true yet. | |
| 21:58:04 | efried | so yeah, that doc should be updated regardless. Sooner rather than later, even. | |
| 21:58:09 | sean-k-mooney | efried: or ever with out the resoruce request | |
| 21:58:24 | aspiers | Good point. We originally expected it all to be merged within Stein :-( | |
| 21:58:27 | efried | aspiers: Re Denver, if we can possibly get away with resolving this before we get there, I will be very happy. | |
| 21:59:15 | aspiers | But yeah, I guess the last paragraph should have started out as a forward-looking statement | |
| 21:59:28 | aspiers | and then been changed to present tense later, when it was all implemented | |
| 21:59:33 | aspiers | Lesson learnt for next time | |
| 22:00:53 | sean-k-mooney | efried: actully on the traits weigher thing. would it make sense to have a weigh that looked at teh traits on the selcect resouce providers and looked at the traits you requested and used that to calulate a weight for the host | |
| 22:01:04 | sean-k-mooney | unrealted to SEV | |
| 22:01:09 | efried | sean-k-mooney: The ol' "preferred traits" deal | |
| 22:01:21 | sean-k-mooney | kind of but not quite | |
| 22:01:35 | efried | It be like a "reverse preferred traits" deal | |
| 22:01:40 | sean-k-mooney | perferred tratis worked by you saying i would like x | |
| 22:01:57 | efried | right, you're saying "If I didn't ask for X, prefer hosts that *don't* have X" | |
| 22:02:07 | sean-k-mooney | ya | |
| 22:02:37 | efried | That would be a pretty cool weigher. Sounds like fun to write too. | |
| 22:02:43 | sean-k-mooney | or rather prefer the host whos traits match the ones you asked for the closes | |
| 22:02:58 | sean-k-mooney | i might hack on it before the ptg | |
| 22:03:22 | sean-k-mooney | the premmis being host with less traits have less intersting stuff | |
| 22:03:31 | sean-k-mooney | so prefer the boaring hosts | |
| 22:05:01 | efried | it would also be nice to know which traits were more interesting than other traits. | |
| 22:05:29 | efried | Like, I probably care way less about HW_CPU_X86_AVX512F than I do HW_AMD_SEV | |
| 22:05:41 | sean-k-mooney | we can sprinkle in a little ML/AI it will be grand | |