Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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
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: Fix nits in support traits on allocation candidates API https://review.openstack.org/537351
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: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/
15:20:22 mriedem it's timing out waiting for a volume backup to complete,
15:20:31 mriedem looking at the node it's running on: http://logs.openstack.org/33/140733/19/check/legacy-tempest-dsvm-cells/3e2f79f/zuul-info/inventory.yaml
15:20:38 mriedem provider: rax-dfw
15:20:52 mriedem those have been really really slow since the intel kernel patcharoo
15:22:52 openstackgerrit Merged openstack/osc-placement master: CLI for aggregates (v1.1) https://review.openstack.org/505643
15:23:14 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove 'NUMATopologyLimits.obj_from_db_obj' https://review.openstack.org/537412
15:23:15 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove legacy '_from_dict' functions https://review.openstack.org/537414
15:23:15 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Remove legacy '_to_dict' functions https://review.openstack.org/537413
15:23:54 openstackgerrit Takashi NATSUME proposed openstack/nova master: Transform instance.resize_prep notification https://review.openstack.org/465081
15:27:52 edmondsw_ gibi here's your requested daily reminder to look at https://review.openstack.org/#/c/526094/ if you get a chance :)
15:33:54 gibi edmondsw_: thanks :)
15:34:09 efried cdent edleafe Not loving the fact that DELETE RP inventory returns 204 and the client code is assuming the RP generation can just be incremented by one.
15:34:48 cdent if you've deleted an RP why would you need to know it's generation?
15:34:49 cdent it's gone
15:34:55 openstackgerrit Merged openstack/osc-placement master: Add missing runtime requirements https://review.openstack.org/536870
15:35:06 efried cdent Deleted its inventory, not the RP itself.
15:35:26 edleafe efried: what would you love more?
15:35:30 cdent then GET the /rp/{uuid}, that's what it's there for
15:36:09 cdent this notion that it is bad to make requests is unproven. just make requests
15:36:24 efried edleafe Either DELETE returns a payload, which would look like { 'resource_provider_generation': N, 'inventories': {} }, or we always use PUT with {}
15:36:51 efried ...which does that
15:37:11 efried cdent It's not quite that simple.
15:37:26 openstackgerrit Merged openstack/osc-placement master: Address comments from original inventory patch https://review.openstack.org/521578
15:37:27 efried cdent The point of getting the generation in the response is that I know it's the generation right after the inventory was deleted.

Earlier   Later