| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-24 | |||
| 13:34:24 | efried | ...but that .exists(uuid) should be False! | |
| 13:34:28 | efried | Because we removed that guy. | |
| 13:34:40 | rgerganov | no, we pass the parent uuid here | |
| 13:34:45 | rgerganov | and it is there | |
| 13:35:19 | artom | Am I doing this right? http://logstash.openstack.org/#dashboard/file/logstash.json?query=libvirtError%3A%20Cannot%20recv%20data | |
| 13:35:30 | rgerganov | efried, _ensure_resource_provider is called with the uuid of the root RP | |
| 13:35:45 | artom | It says 0 hits, but we clearly got some here: http://logs.openstack.org/97/536897/2/check/legacy-tempest-dsvm-cells/fc9986a/logs/screen-n-cpu.txt.gz?level=ERROR#_Jan_23_23_16_41_428802 | |
| 13:35:53 | efried | rgerganov I see, and you were trying to add the bogus trait to the child? | |
| 13:36:02 | rgerganov | efried, correct | |
| 13:36:05 | efried | So we invalidated the child, but not the root. | |
| 13:36:11 | rgerganov | yup | |
| 13:36:13 | efried | Okay, it's coming together. | |
| 13:36:44 | rgerganov | could you please tell why my patch won't refresh the tree? | |
| 13:37:52 | efried | rgerganov No I can't. It should. | |
| 13:38:04 | efried | oh | |
| 13:42:17 | efried | rgerganov So with your patch, is rps_to_refresh populated at that breakpoint? | |
| 13:43:26 | rgerganov | efried, yes | |
| 13:43:46 | efried | rgerganov And after populate_from_iterable, is the _provider_tree populated properly? | |
| 13:43:47 | rgerganov | it contains both parent and child | |
| 13:44:05 | rgerganov | as far as I can see, yes | |
| 13:44:29 | mvenesio | Hi guys i'm trying to set nova to use SSL for the database connection, i set the mysql connection as well as i set it for the rest of the projects like cinder and glance, but for nova it does not work and i got an OperationalError. Any idea about how to set it right ? | |
| 13:45:49 | efried | mvenesio I think that's a better question for #openstack (see channel topic). | |
| 13:46:10 | efried | rgerganov So if the child is in the cache... where do we run into a problem? | |
| 13:46:17 | openstackgerrit | Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886 | |
| 13:46:36 | lyarwood | melwitt: https://review.openstack.org/#/c/457886/ ^ I wonder if this is something we could land by the rc | |
| 13:47:26 | mvenesio | efried: ok i'll do it, thanks | |
| 13:47:27 | rgerganov | efried, the child gets in the cache with my patch and then we don't have a problem (at least not now :) ) | |
| 13:48:20 | efried | rgerganov I must have misunderstood "could you please tell why my patch won't refresh the tree?" | |
| 13:49:38 | rgerganov | efried, I asked that because you said "As written, that change will *not* refresh the tree, though" | |
| 13:49:40 | rgerganov | nevermind | |
| 13:50:08 | efried | rgerganov Okay, yeah, I was wrong. I had missed the 'return uuid' part and was misunderstanding my own code :( | |
| 13:51:06 | efried | rgerganov So your solution will work, but it's skipping a nontrivial optimization that I would like to keep if possible. | |
| 13:52:13 | efried | rgerganov One possible alternative would be for that cache invalidation to in fact kill the whole tree. But the implications of that are probably too far-reaching to be practical. | |
| 13:52:58 | efried | rgerganov Other than that patch, do you have any local code on the series? | |
| 13:53:19 | efried | rgerganov In particular, we should definitely commit whatever test case you're running to hit this problem. | |
| 13:53:30 | openstackgerrit | Merged openstack/nova master: Transform instance.resize_confirm notification https://review.openstack.org/482557 | |
| 13:53:45 | efried | rgerganov Though I would like to do it as part of the update_from_provider_tree patch. | |
| 13:54:13 | rgerganov | efried, so basically the test case should be virt driver adding an incorrect trait | |
| 13:54:33 | efried | rgerganov ...to a child | |
| 13:54:36 | efried | right? | |
| 13:54:39 | rgerganov | yes | |
| 13:55:03 | efried | rgerganov How close to your EOD are you? | |
| 13:55:16 | rgerganov | efried, I will head out in 2 hours | |
| 13:57:15 | efried | rgerganov So I've *almost* got this code path in my test_report_client work in progress. | |
| 13:57:56 | efried | rgerganov I've got one piece setting a bogus trait on the root. And another setting inventory in a bogus *resource class* on a descendant. The latter of which should *probably* have the same effect. | |
| 13:58:21 | efried | rgerganov But since we've identified this exact issue, it wouldn't go amiss to have a small, isolated test case that's separate from that big one. | |
| 13:58:46 | efried | rgerganov Do you have the time/inclination/know-how to write that test case before you leave? | |
| 13:58:57 | rgerganov | efried, I will give it a try | |
| 13:59:05 | efried | rgerganov Thanks! | |
| 13:59:22 | rgerganov | efried, do you want me to update an existing patch or start a new patch? | |
| 14:00:49 | mriedem | alex_xu: i'm fine with checking the version in the Selection object or just checking if the allocation request is the list or dict format and adjusting properly, up to you, but i think we have to handle both cases in queens, we can then probably remove that check later in rocky | |
| 14:02:24 | artom | mriedem, 'morning - did we figure out if the libvirt connection reset errors were a real bug or not? | |
| 14:02:29 | efried | rgerganov New one. We can always slot it into the series, or squash it into the existing commit. | |
| 14:02:57 | efried | rgerganov And that way I can continue working on these test cases locally in parallel. | |
| 14:03:09 | artom | Also - I think I'm using logstash wrong - http://logstash.openstack.org/#dashboard/file/logstash.json?query=Connection%20reset%20by%20peer is turning up nothing for the past month | |
| 14:03:11 | rgerganov | efried, ok cool | |
| 14:03:48 | bauzas | mriedem: when you said "sneaky" in https://review.openstack.org/#/c/535693/, you meant okay for that or not ? | |
| 14:04:15 | Roamer` | actually, yeah, I've been meaning to ask - is there some documentation on using logstash somewhere? I've seen people compose nice queries, like "a message that looks almost like this in this set of files", but I'd like to know more :) | |
| 14:04:15 | mriedem | artom: message:"Connection reset by peer" AND tags:"screen-n-cpu.txt" | |
| 14:04:23 | mriedem | bauzas: it's ok | |
| 14:04:24 | mriedem | just sneaky | |
| 14:04:30 | Roamer` | ah... that's more or less exactly it | |
| 14:04:32 | artom | mriedem, cheers :) | |
| 14:05:07 | mriedem | Roamer`: artom: http://lucene.apache.org/core/4_0_0/queryparser/org/apache/lucene/queryparser/classic/package-summary.html#package_description | |
| 14:05:29 | Roamer` | mriedem, thanks! | |
| 14:05:31 | alex_xu | mriedem: for handle both cases in queens, do you means check both the list or dict and version at sametime? | |
| 14:05:53 | alex_xu | mriedem: for checking version, i have done today, it looks like this https://review.openstack.org/#/c/536083/7/nova/scheduler/client/report.py@1161 | |
| 14:05:56 | mriedem | alex_xu: we do'nt need to check the version and the type, just one or the other | |
| 14:06:23 | Roamer` | mriedem, and thanks again for the +2 yesterday; unfortunately 140733 has had a bad case of "the same spurious totally unrelated test failure showing in a different job on every recheck" all day today :( | |
| 14:06:24 | alex_xu | mriedem: ok, I done that, I choice checking the version | |
| 14:09:04 | artom | Hrmm, so it started all of a sudden on Jan 16th | |
| 14:09:04 | artom | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22libvirtError%3A%20Cannot%20recv%20data%3A%20Connection%20reset%20by%20peer%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22 | |
| 14:09:41 | bauzas | I'm around for reviewing | |
| 14:09:58 | bauzas | mriedem: which priority changes should I be doing ? | |
| 14:10:00 | mriedem | artom: keep in mind that logstash only holds 10 days worth of logs, so that's getting close to the cutoff | |
| 14:10:02 | bauzas | nested RPs ? | |
| 14:10:32 | mriedem | bauzas: actually i'd really like to get a few more osc-placement changes merged before we do the first 1.0.0 release this week, | |
| 14:10:36 | mriedem | i've got a +2 on a change here https://review.openstack.org/#/c/505643/ | |
| 14:10:50 | mriedem | and there is an easy cleanup and docs series starting here https://review.openstack.org/#/c/536870/ | |
| 14:10:53 | mriedem | stephenfin: ^ | |
| 14:11:18 | mriedem | this change had a +2 from jaypipes before a rebase https://review.openstack.org/#/c/525505/ | |
| 14:11:45 | stephenfin | mriedem: Sure, I can take a look | |
| 14:11:54 | mriedem | bauzas: and this is an easy libvirt volume driver add https://review.openstack.org/#/c/140733/ | |
| 14:12:11 | stephenfin | Speaking of jaypipes, wonder where he's at. I'd like some eyes on https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1744965 | |
| 14:12:23 | mriedem | "work conference" i was told | |
| 14:12:30 | stephenfin | Vegas it is | |
| 14:12:39 | mriedem | heh maybe | |
| 14:13:37 | bauzas | okay looking | |
| 14:13:47 | bauzas | FWIW, I'm also in a conference now for the next 3 days | |
| 14:13:52 | bauzas | organizing it, so I have time :p | |
| 14:14:00 | bauzas | http://snowcamp.io | |
| 14:16:04 | mriedem | didn't that ski conference already happen a couple of weeks ago? | |
| 14:16:08 | mriedem | is that a monthly conference? | |
| 14:18:39 | artom | mriedem, ah - heh, it's kinda misleading that you can search for a month back though | |
| 14:19:03 | artom | Well, 16th is 8 days | |
| 14:19:26 | artom | Hrmpf | |
| 14:20:08 | mriedem | artom: fwiw, some other stuff start randomly exploding around the 16th too in the ironic multinode grenade job | |
| 14:20:14 | edleafe | alex_xu: commented on https://review.openstack.org/#/c/536083/ | |
| 14:20:15 | mriedem | jroll was investigating that - random segfaults | |
| 14:20:48 | artom | mriedem, ah, interesting | |