Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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
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 mriedem the modification here is for upgrades
14:31:36 edleafe and all this doubling code can be removed
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
14:32:49 edleafe alex_xu: the client should pass the AR and AR_version without inspecting the contents
14:32:50 alex_xu and that is the rule of using micorverion in the client, never use the latest version, and specified a version explicitly
14:33:10 mriedem edleafe: you said, "it would be better if you also modified the allocation_request_version to 1.12 when you modify the allocation_request in the block starting on L1163." - if you change allocation_request_version='1.12' anywhere it's going to post all requests at 1.12 regardless
14:33:40 mriedem we have to inspect the contents in this case
14:33:50 mriedem and to do that, we need to know what format it's in
14:33:55 openstackgerrit Ameed Ashour proposed openstack/nova master: detach instance volumes when VM creation fails https://review.openstack.org/528385
14:34:03 edleafe mriedem: no, that would be inside the 'if' block on L1162, so only <1.12 would be affected
14:34:18 mriedem edleafe: true, like i said in the comment, i'm fine with that
14:34:25 mriedem and i think makes sense
14:34:28 edleafe mriedem: if it's >=1.12, then it won't get changed
14:34:41 mriedem sure i'm ok with that
14:34:50 mriedem alex_xu: ^ want to just make that change?
14:35:13 alex_xu mriedem: make the version=allocation_request_version?
14:35:39 mriedem if the version is < 1.12 and you modify ar, then set allocation_request_version='1.12'
14:35:52 alex_xu mriedem: ok, no problem
14:35:54 mriedem and use allocation_request_version as before when claim_resources does it's PUT reuest
14:35:56 mriedem *request
14:36:38 alex_xu mriedem: edleafe got the point, will update soon, thanks
14:37:04 edleafe alex_xu: thanks
14:37:54 edleafe alex_xu: and don't forget my nit on https://review.openstack.org/#/c/536083/7/nova/scheduler/manager.py@146 while you're at it :)
14:38:20 alex_xu edleafe: yes sir!
14:39:40 edleafe alex_xu: :)
14:39:46 mriedem artom: jroll: one thing i was wondering was if there was a new package version of something in the Pike UCA around 1/16
14:39:56 mriedem i'm not sure if there is a package change log somewhere for the pike UCA though
14:42:13 mriedem coreycb: ^?
14:43:02 coreycb mriedem: artom: i can check. nova package right?
14:43:54 mriedem coreycb: no, just looking for a changelog for the pike cloud archive
14:44:02 mriedem CI results started going wonky since ~1/16
14:44:15 mriedem so wondering about changes to distro packages for things like qemu/libvirt/httpd, et
14:44:51 coreycb mriedem: i don't know if anything is available externally but i can at least check dates internally
14:48:08 openstackgerrit Radoslav Gerganov proposed openstack/nova master: Add update_from_provider_tree() negative test https://review.openstack.org/537406
14:48:14 rgerganov efried, ^^^
14:48:34 efried rgerganov Looking (if gerrit will ever load)

Earlier   Later