Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-18
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
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?
22:21:10 sean-k-mooney yes which will be most of it
22:21:28 sean-k-mooney the qemu overhead is ment to be tracked using the resved meory config option
22:22:36 aspiers Yeah, that's the bit which danpb is suggesting should have an rlimit at the top /machine.slice cgroup I think?
22:22:37 sean-k-mooney or on a hugepage host its assumed you leave enough free non hugepage memeroy on the host for the os and any qemu memroy required outside of the guest ram
22:22:48 sean-k-mooney ya
22:22:50 aspiers i.e. reserving some memory for the host
22:23:01 aspiers I added some paras in the spec about this - please could you check them if you didn't already?
22:23:12 sean-k-mooney so my suggetion is still use the locked element but dont set the hard_limit
22:23:21 aspiers Yes, I already changed the spec to propose that
22:23:25 sean-k-mooney and preferably use hugepages
22:23:40 aspiers it pretty much says that too
22:23:50 aspiers Most of my recent edits were just copying your advice ;)
22:23:58 sean-k-mooney if you dont use hugepages we need to tell the operators to set the ram_allocatoin_raito to 1.0
22:24:00 aspiers but I'm not 100% sure I got it all accurate
22:24:20 sean-k-mooney ill take a look at it before the ptg
22:24:25 aspiers cool thanks
22:27:56 mriedem "'>' not supported between instances of 'NoneType' and 'datetime.datetime'" seems to be showing up in stephen's cells v1 removal series first...i'm not sure what could have introduced that
22:28:40 sean-k-mooney did we merge any of that yet
22:28:46 mriedem yes
22:32:41 sean-k-mooney maybe the instance list change
22:34:30 sean-k-mooney maybe not im wondering if we change how we are handeling the sorted list

Earlier   Later