| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 21:18:33 | mriedem | well, won't work in train - might work in stein | |
| 21:18:43 | efried | right; which we're fine with | |
| 21:18:53 | efried | But, are you considering taking this on in train? | |
| 21:19:05 | efried | or hoodwinking stephenfin into doing so :P | |
| 21:19:07 | sean-k-mooney | by the way i moved the ci stuff here https://etherpad.openstack.org/p/nova-ptg-train-ci but im not really sure what we want to get out of it | |
| 21:19:23 | mriedem | efried: it's not really much to take on | |
| 21:19:31 | efried | sean-k-mooney: Good, since you're here, that's a question I'm basically trying to ask everyone about their topics. | |
| 21:19:55 | mriedem | rm -rf nova/console | |
| 21:19:56 | efried | mriedem: death of a thousand cuts? | |
| 21:20:12 | mriedem | this is definitely not a priority for me | |
| 21:20:47 | efried | k. I'll fup on the ML like I did for the privsep topic, proposing to cut it from the agenda unless objections. | |
| 21:21:05 | mriedem | i see the tc has a ptg item about "can we just start breaking stuff so people can get all the fancy new awesome cloud stuff" so we could just drop, say it's the tc's fault, and then move on | |
| 21:22:19 | efried | perfect | |
| 21:34:11 | sean-k-mooney | efried: can you get some of the intel folks to attend https://etherpad.openstack.org/p/nova-ptg-train-ci that will be setting up/runing the cis | |
| 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 | |