Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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
15:05:43 efried cdent Seen and appreciated sir. Silver lining: it takes *some* of the pressure off getting the top of the series perfect.
15:06:03 efried At this rate, even things +W'd by FF will take a week to merge.
15:09:22 openstackgerrit Alex Xu proposed openstack/nova master: placement: using the dict format for the allocation in claim_resources https://review.openstack.org/536083
15:09:23 openstackgerrit Alex Xu proposed openstack/nova master: placement: enable required traits from the flavor extra specs https://review.openstack.org/536085
15:09:23 openstackgerrit Alex Xu proposed openstack/nova master: Fix nits in support traits on allocation candidates API https://review.openstack.org/537351
15:09:56 alex_xu edleafe: mriedem stephenfin, thanks for the review, ^ addressed all the comments
15:11:55 edleafe alex_xu: thanks - will review soon
15:12:07 alex_xu edleafe: thanks
15:12:44 mriedem alex_xu: were you going to put up a patch for the placement api-ref docs changes? https://github.com/openstack/nova/blob/master/placement-api-ref/source/allocation_candidates.inc#L27
15:13:11 efried cdent mriedem Sorry for not understanding how placement version lockstepping works; are we now ready to address these comments? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L902-L904 https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1117-L1119
15:13:45 cdent efried: https://review.openstack.org/#/c/528794/
15:14:07 cdent that may be out of date by now, since it's been sitting there for quite a while
15:14:16 efried cdent Thanks, at least it's on the radar.
15:15:23 mriedem efried: yeah we require >=1.14 now really, or that's what nova-status is checking for and the compute requires for root providers,
15:15:33 mriedem efried: but at this point might as well hold that off until rocky - the cleanup i mean
15:16:24 mriedem dansmith: that reminds me - we havent bumped major compute rpc api versions in a few years; that's historically something you've been the master of, are you interested in doing one of those, since i think it has to happen shortly before RC1 yeah?
15:16:51 mriedem we have a lot of "drop this compat code when we bump major versions"
15:17:01 efried okay. I must also not have a good handle on what kind of patch will be accepted after FF. This isn't a feature, so...?
15:17:49 dansmith mriedem: yeah I should probably do that
15:20:16 mriedem Roamer`: looking at the latest cells job failure on your patch http://logs.openstack.org/33/140733/19/check/legacy-tempest-dsvm-cells/3e2f79f/

Earlier   Later