| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-16 | |||
| 10:38:21 | sean-k-mooney | un less they do it via that api. | |
| 10:40:31 | openstackgerrit | Merged openstack/nova master: Parse vpmem related flavor extra spec https://review.opendev.org/678456 | |
| 10:43:32 | sean-k-mooney | pmem is almost done... the PCUP can merge and all the pending feature should be landed | |
| 11:14:01 | osmanlicilegi | greetings. i'm having problem with nova-conductor, it gives "errno 111 econnrefused" while trying to connecto to rabbitmq. i know it's not a network/firewall issue because all other rabbitmq related services work like a charm. i had the same problem with nova-api and the root cause was monkey patching but this time it's not because nova-conductor does not use monkey patching. anybody had a similar | |
| 11:14:03 | osmanlicilegi | issue before? | |
| 11:19:02 | aspiers | in case anyone didn't get a chance to review my draft SEV blog post last week, here is a link which will last 24 hours (I think) https://blog.adamspiers.org/?p=1871&preview=1&_ppp=dbc2fbd3ce | |
| 11:19:20 | sean-k-mooney | the conductor shuold be useing monkey patching | |
| 11:19:21 | artom | osmanlicilegi, you'll have bette luck in #openstack, operators hang out there, this channel is for development | |
| 11:19:28 | artom | osmanlicilegi, see /topic :) | |
| 11:19:34 | sean-k-mooney | osmanlicilegi: e.g. it should be using eventlet | |
| 11:19:52 | sean-k-mooney | but i have not seen that so i dont know how to help | |
| 11:20:29 | lyarwood | artom: https://review.opendev.org/#/c/672595/ - do you think you'll have time today to work on this and potentially break out the per n-cpu service connection setting into another change? | |
| 11:20:49 | lyarwood | artom: if not I should be able to get to it this afternoon | |
| 11:21:26 | artom | lyarwood, so... Yes, but! | |
| 11:21:46 | lyarwood | But! | |
| 11:22:18 | lyarwood | Nothing good ever follows but ;) | |
| 11:22:18 | artom | But! https://review.opendev.org/#/c/681060/ is in the gate | |
| 11:22:20 | sean-k-mooney | we might want to hold of doing any upstream work until https://review.opendev.org/#/q/topic:bp/cpu-resources+(status:open+OR+status:merged) lands | |
| 11:22:40 | artom | lyarwood, which does the same thing, right? At least for the hostname part | |
| 11:22:47 | artom | For the connection I need to play around with it some more | |
| 11:24:01 | artom | lyarwood, wait, I misunderstood you, didn't I? | |
| 11:24:12 | lyarwood | artom: it does, I'd just rather do this in a helper method in the fixture instead of in a loop per test as in that series | |
| 11:24:42 | artom | You just need the heterogeneous computes helper | |
| 11:24:43 | lyarwood | artom: and again I really need something I can backport for a few fixes | |
| 11:24:52 | lyarwood | artom: yeah pretty much | |
| 11:25:13 | artom | lyarwood, well, I have to stack on top of https://review.opendev.org/#/c/681060/11 regardless | |
| 11:25:18 | sean-k-mooney | aspiers: the assertion you cant snopp if you have physical acess is a little strong. sev and mktme both do not encyrpt cache content so if you have phyical acess to the server and snoop cache you can see the unencypted state of what ever the vm is doing | |
| 11:25:19 | artom | Otherwise we'll conflict | |
| 11:25:21 | artom | But yeah | |
| 11:26:39 | sean-k-mooney | aspiers: you cant read its ram but you could constuct a view of it by recodering the reads/writes to cache | |
| 11:27:05 | lyarwood | sean-k-mooney: sorry re you're earlier comment are you also suggesting avoding POSTing new stuff at all still? I've been holding off for the last week anyway but thought we were passed the bulk of it now. | |
| 11:27:10 | artom | I think what sean-k-mooney's saying is that the SEV work was *completely* pointless >;) | |
| 11:27:10 | lyarwood | your* | |
| 11:27:52 | sean-k-mooney | lyarwood: i personally am holding off posting new stuff until stephens changes land | |
| 11:28:04 | sean-k-mooney | or we decide to punt it | |
| 11:28:13 | sean-k-mooney | i dont want to take gate time form it | |
| 11:28:33 | lyarwood | ack I'll continue to hold off then, wasn't sure if you were just talking about landing new stuff or posting. | |
| 11:28:47 | sean-k-mooney | if its small sure. if you have 10 pending patchs for different thing i dont know | |
| 11:29:08 | sean-k-mooney | today is the cut off to not need an FFE i think | |
| 11:29:14 | lyarwood | kk | |
| 11:31:19 | sean-k-mooney | artom: :) not quite but as a person who previously worked at a hardware companiy im very carful of claims of hardware releatd security features | |
| 11:32:16 | sean-k-mooney | artom: also at this point any limitation of the technology are well within amd's court to go fix aspiers work is quite good | |
| 11:34:16 | sean-k-mooney | aspiers: the only real feedback i would give is the images are a little hard to read without clicking on them. the commandline ones more then anything else | |
| 11:34:31 | sean-k-mooney | the content looks good to me | |
| 11:42:28 | openstackgerrit | ya.wang proposed openstack/nova master: Fix typor of cpu model when check CPU compatibility https://review.opendev.org/682267 | |
| 12:26:41 | bauzas | FWIW, I'm a bit on and off today, working back on the placement audit command | |
| 12:43:44 | efried | o/ nova! | |
| 12:43:50 | efried | ready for a fun-filled day of rechecks?! | |
| 12:45:08 | sean-k-mooney | at least we are down to 2 series | |
| 12:46:40 | sean-k-mooney | there is 1 patch need for vpmem, + https://review.opendev.org/#/q/topic:bp/cpu-resources+(status:open+OR+status:merged) + 2 pathes for forbiden aggreates i think | |
| 12:46:45 | efried | I'm starting to think there may actually be something wrong. | |
| 12:46:53 | efried | forbidden aggs is in. | |
| 12:47:01 | sean-k-mooney | oh ok | |
| 12:47:07 | sean-k-mooney | with the pmem stuff | |
| 12:47:07 | efried | And i think there's one for numalm, but not an important one | |
| 12:47:11 | efried | pmem and cpu-resources | |
| 12:47:14 | efried | are the big ones | |
| 12:47:32 | sean-k-mooney | i was ingoring the funcitonal tests for numalm | |
| 12:47:37 | efried | right | |
| 12:47:52 | sean-k-mooney | the actully featre has lannded just tests are leaft | |
| 12:48:17 | efried | 13 rechecks on the top cpu-resources patch | |
| 12:48:49 | efried | cascading effect of -2s in the gate from a prior patch failing. | |
| 12:48:51 | efried | mostly | |
| 12:49:05 | sean-k-mooney | ya that was what i was about to say | |
| 12:49:25 | efried | I think we have a race in select_destinations though | |
| 12:49:38 | efried | been seeing quite a few like this https://storage.gra1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_778/674895/42/check/openstack-tox-py36/7787cd5/testr_results.html.gz | |
| 12:51:56 | sean-k-mooney | maybe or that test is just not deterministic | |
| 12:52:15 | efried | yeah, either way | |
| 12:52:19 | efried | it's not just that one test | |
| 12:52:32 | efried | I saw several similar failures with that same select_destinations unequal | |
| 12:52:48 | efried | I didn't dig all the way into them (lack of appropriate tooling on my phone) | |
| 12:52:51 | sean-k-mooney | all in the fallback tests | |
| 12:52:53 | efried | but thinking maybe I should at this point. | |
| 12:53:06 | efried | no, I remember seeing one in a pre-existing test (I think) | |
| 12:53:15 | efried | i.e. regression | |
| 12:53:39 | sean-k-mooney | we might not be mocking some global state in the tests? | |
| 12:54:06 | sean-k-mooney | that said the fallback code is very new so there might be something there | |
| 12:56:35 | stephenfin | efried: I'm thinking we should stop rechecking the two few patches for now | |
| 12:56:40 | stephenfin | *top | |
| 12:56:45 | efried | whyzat? | |
| 12:56:58 | efried | oo, I have a local repro | |
| 12:57:04 | efried | running the whole test class | |
| 12:57:10 | efried | nova.tests.unit.scheduler.test_scheduler.SchedulerManagerTestCase | |
| 12:57:15 | efried | sean-k-mooney: ^ | |
| 12:57:39 | sean-k-mooney | ok then it is likely either a shared state issue or a bug in the code | |
| 12:57:42 | stephenfin | On account of having to recheck again if anything lower gets in. Better just get those lower ones in | |
| 12:57:55 | sean-k-mooney | but if that repoduces it locally that makes it eaiser to figure out | |
| 12:58:11 | stephenfin | Hmm, I've seen that as well, actually | |
| 12:58:28 | stephenfin | Okay, that sounds like a bug. That's testing the retry logic | |
| 12:59:05 | efried | stephenfin: if it's not affecting queue times -- which it probably isn't at this point -- then it's better to have the top ones kicked out by merge-failed -2s than to have to wait for them to pass the check pipeline again once the lower ones are in, imho | |
| 12:59:34 | stephenfin | that's a fair point | |
| 12:59:35 | sean-k-mooney | efried: im just about to grab lunch but ill dig into it when i get back if ye have not figured it out by then | |
| 12:59:35 | efried | stephenfin, sean-k-mooney: I definitely remember seeing the failure on a patch lower in the series at some point. | |
| 12:59:48 | efried | I don't remember which one now | |
| 12:59:53 | efried | where was that fallback introduced, again? | |
| 13:00:24 | stephenfin | efried: https://review.opendev.org/#/c/671801/ | |
| 13:00:50 | sean-k-mooney | ya thats the patch that updated those tests too | |
| 13:00:59 | stephenfin | intermittently failing tests are the _best_ | |
| 13:01:09 | sean-k-mooney | brb | |
| 13:05:46 | shilpasd | Eric: finally after so many rechecks isoalte agg patches are merged, tnx for your extended support | |