| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-18 | |||
| 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 | sean-k-mooney | ya the ... out of scope is the imporant bit | |
| 21:56:16 | efried | and \o/ the trait is no longer trash :) | |
| 21:56:22 | sean-k-mooney | :) | |
| 21:56:22 | aspiers | haha | |
| 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 | |
| 22:10:31 | sean-k-mooney | with the same oslo config issue? | |
| 22:10:48 | mriedem | maybe? | |
| 22:10:51 | mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22%7C%20Fatal%20Python%20error%3A%20Cannot%20recover%20from%20stack%20overflow.%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d | |
| 22:11:35 | mriedem | what did we merge on april 15? | |
| 22:12:32 | sean-k-mooney | in oslo config. apparently droping python 35 testing | |
| 22:12:46 | mriedem | ... | |
| 22:12:52 | mriedem | why would that matter in a nova py36 job? | |
| 22:13:02 | mriedem | especially if an oslo.config change is unreleased for us to use it | |
| 22:13:06 | sean-k-mooney | i assume this is a version bump in upper constratins or a new release? | |
| 22:13:25 | mriedem | https://github.com/openstack/requirements/commit/a96ee0e258aafb2880149b3e25dd5959f7b37c09 | |
| 22:13:31 | efried | sean-k-mooney: are you at the PTG through Saturday? | |
| 22:14:09 | sean-k-mooney | im flying there the friday before and leaving the Starday afternoon so yes | |
| 22:14:50 | sean-k-mooney | mriedem: oslo.config 4.11.2 came out 2 days ago | |
| 22:15:07 | efried | sean-k-mooney: I'm going to assert that the CI topic is one we don't need jaypipes for; and dtroyer is booked Th+Fr. So I'll set the CI topic for Saturday a.m., cool? | |
| 22:15:17 | sean-k-mooney | oh never mind | |
| 22:15:22 | sean-k-mooney | that is old | |
| 22:15:40 | sean-k-mooney | efried: ya that sound fine | |
| 22:15:46 | mriedem | we're using 6.8.1 from 2 months ago | |
| 22:16:14 | mriedem | i also started seeing seg faults in pip 3.6 installs yesterday, so maybe something in py36 on bionic nodes since april 15 | |
| 22:18:39 | mriedem | https://bugs.launchpad.net/nova/+bug/1825435 | |
| 22:18:40 | openstack | Launchpad bug 1825435 in OpenStack Compute (nova) "TestRPC unit tests intermittently fail with "'>' not supported between instances of 'NoneType' and 'datetime.datetime'"" [Undecided,Confirmed] | |
| 22:19:06 | aspiers | sean-k-mooney: I forgot to get your take on whether hugepages are still helpful for SEV, in terms of accounting | |
| 22:19:32 | sean-k-mooney | am i think they are | |
| 22:19:34 | aspiers | sean-k-mooney: I'm a little confused by recent discussions but I got the impression they can only be used for accounting guest RAM | |
| 22:19:42 | sean-k-mooney | mainly because you still have to lock the memory | |
| 22:19:48 | aspiers | and QEMU allocates a whole bunch of other stuff | |
| 22:20:13 | sean-k-mooney | yes it does for mmio/dma | |
| 22:20:42 | sean-k-mooney | with SEV instace there will be no oversubsription of memory | |
| 22:20:48 | sean-k-mooney | that is also true of hugepages | |
| 22:20:53 | aspiers | is it useful to only track part of what is allocated though? | |