Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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 mriedem artom: message:"Connection reset by peer" AND tags:"screen-n-cpu.txt"
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: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 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:04 artom Hrmm, so it started all of a sudden on Jan 16th
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
14:20:56 edleafe alex_xu: I am concerned that the change you made could break if placement changes in the future
14:21:45 bauzas mriedem: huh, unfortunately not, only every year ;)
14:21:52 bauzas we need snow
14:22:10 stephenfin mriedem: Done. Only have comments for https://review.openstack.org/#/c/536858/
14:24:19 mriedem stephenfin: thanks
14:24:44 alex_xu edleafe: if we change the allocation_request format in the future, we must do another patch just like 536083. that parameter 'version=allocation_request_version' can't do a magic let us upgrade to the new format
14:25:51 alex_xu edleafe: we can say: the reason for including the allocation_request_version in the selection obj is so that claim_resources can know how to handle alloc_reqs.
14:26:58 mriedem "the reason for including the allocation_request_version in the selection obj is so that claim_resources can know how to handle alloc_reqs." - not exactly, but that is a side effect
14:27:10 mriedem since we have client side code that needs to know what format the thing is in
14:27:49 mriedem the point of the version in the selection object, though, is so the client on a reschedule makes the same PUT /allocations request in the version/format that the scheduler initially created the allocation request (from GET /allocation_candidates)
14:30:10 edleafe alex_xu: if placement is upgraded to a new version that changes the AR format, the way you changed it will force it to be posted to placement as 1.12, which would be wrong
14:30:11 mriedem alex_xu: edleafe: "if we change the allocation_request format in the future" - if that happens, i think we'll have to add an AllocationRequest versioned object to nova to deal with the version differences getting passed over rpc
14:30:37 alex_xu mriedem: edleafe yes, but I don't want to implement the claim_resources method and the sub method to support two version format, that makes the code hard to read, I want to convert the format to consistent in the begining of claim_resources method
14:30:38 mriedem edleafe: if placement is upgraded to a new version, it shouldn't affect the client side code since the client side code is requesting a specific microversion
14:30:42 mriedem which shouldn't change
14:30:43 edleafe mriedem: allocation requests are *supposed* to be opaque
14:30:52 edleafe mriedem: we are violating that here to fix a bug
14:31:16 edleafe Once we are in Rocky, the need for this modification goes away
14:31:33 mriedem i agree once we are in rocky this can go away,
14:31:36 edleafe and all this doubling code can be removed
14:31:36 mriedem the modification here is for upgrades
14:31:45 edleafe I understand
14:32:05 alex_xu edleafe: when placement upgrade, our client won't use the lastest version, we have specified the version in the client https://review.openstack.org/#/c/536083/7/nova/scheduler/client/report.py@338
14:32:14 edleafe I just don't want all requests to be posted at 1.12

Earlier   Later