Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-18
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
22:05:54 sean-k-mooney but yes
22:05:56 efried edleafe would suggest using trait metadata on the placement side so we can rank the traits in priority order.
22:06:14 sean-k-mooney if we had a histogram of how often traits exisit for a given resouce class
22:06:22 sean-k-mooney we could use that as an input
22:06:34 edleafe efried: I would??
22:06:52 sean-k-mooney edleafe: ofcouse efried just said so above :)
22:07:18 sean-k-mooney it would be eaiser to do some of this on the placement side however
22:07:19 efried oh, edleafe, is this *your* goat?
22:07:51 mriedem oh nice a stack overflow in unit tests http://logs.openstack.org/45/649345/7/check/openstack-tox-py36/ba15c17/job-output.txt.gz#_2019-04-18_18_10_53_423952
22:07:55 edleafe Weighers in Placement - yay!
22:09:06 sean-k-mooney mriedem: so there is definetly an infinity loop between _get and __getattr__ in tha tpatch
22:09:25 efried but only in py36
22:09:53 mriedem sean-k-mooney: i've seen this TestRPC class intermittently failing unit tests all over the gate today
22:09:56 mriedem it's not this patch

Earlier   Later