Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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)
14:49:01 coreycb mriedem: for pike specifically we haven't had anything go into pike-updates since december. it's possible though that something in the base xenial packages changed though.
14:51:14 coreycb mriedem: for base xenial packages you can find dates on Launchpad if you know the package name, ie. https://launchpad.net/ubuntu/+source/apache2
14:51:36 mriedem ok was trying to find just a global list like in https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/16.04 but no dice
14:52:41 ameeda jaypipes: please don't forget to check this https://review.openstack.org/#/c/526900/ for me
14:52:42 coreycb mriedem: yeah unfortunately i don't think there's a list for stable updates
14:52:51 mriedem don't see any changes in 2018 to libvirt or qemu though so it's not that
14:52:53 mriedem thanks anyway
14:53:44 mriedem OH SNAP
14:53:45 mriedem https://launchpad.net/ubuntu/+source/python2.7
14:53:47 mriedem jroll: ^
14:53:56 mriedem https://launchpad.net/ubuntu/+source/python2.7/2.7.12-1ubuntu0~16.04.3
14:54:00 mriedem released 1/18
14:55:36 mriedem should compare the versions of the python2.7 package in the failing ironic CI jobs
14:57:16 mriedem bauzas: thanks for hitting those osc-placement changes
14:59:48 efried rgerganov So as written, this test will fail?
14:59:54 rgerganov efried, yes
15:01:33 efried rgerganov Good deal. If you don't mind, as I work through this today, I think I'm going to incorporate your test and (some version of) your fix into the update_from_provider_tree patch. You'll get co-author credit, of course :)
15:02:04 rgerganov efried, fine with me :)
15:04:58 cdent efried: I tried to do another recheck run through your changes this morning (and some others) but I'm not sure how much impact it had

Earlier   Later