Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-24
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.
15:37:34 openstackgerrit Matt Riedemann proposed openstack/osc-placement master: Usage docs and initial release note for osc-placement https://review.openstack.org/536858
15:37:37 mriedem stephenfin: done ^
15:37:44 cdent If you are depenendent on that, you're not rally making a very resilient system?
15:37:46 efried cdent Whereas if I do a subsequent GET, I don't know if an intervening operation incremented the generation as well.
15:37:55 cdent yes that's _always_ the case
15:38:01 cdent whether you did the the GET or not
15:38:11 efried cdent No, not when I get the generation in the response.
15:38:17 cdent you have no idea, ever, what any other client or thread might be doing with the same resource provider
15:38:37 Roamer` mriedem, yes, I saw it was rax-dfw on the previous runs, too, that's why I haven't complained to -infra (I guessed somebody else with more authority would complain again sooner or later), but thanks for raising it in -infra right now
15:38:41 cdent when you get the generation in the response, something else, immediately, might have changed it
15:38:47 cdent that's always true
15:38:55 cdent what ever mechanism you are using to track generations
15:38:59 efried cdent Yes, but I don't need to care about that until the next time I go to update something.
15:39:12 cdent which should always be the case
15:39:21 cdent you should always be prepared to get a 409
15:39:30 cdent and act accordingly
15:39:39 edleafe gotta agree - I don't see what getting the generation in the response buys you
15:39:49 efried I need to be able to get a 409 reliably, though.
15:39:51 efried Look look.
15:39:57 cdent the generation should be utterly meaningless
15:40:06 cdent sorry, I gotta go fetch the cat, will catch up in 30'
15:40:08 efried That's exactly why I shouldn't be assuming it gets incremented by 1
15:40:18 efried (the meaningless thing, not the cat thing)
15:40:37 edleafe if the delete succeeds, then it will be incremented by 1. You can certainly assume that
15:40:41 mriedem Roamer`: see -cinder
15:40:46 Roamer` mriedem, yes, looking
15:40:50 efried edleafe No way.
15:40:51 Roamer` I mean watching
15:40:54 mriedem looks like cinder made a change in the last 24 hours that is slowing down volume backup
15:41:01 edleafe What you can't assume is that the next time you do something, it won't have been changed by something else
15:41:07 efried edleafe That's not part of the contract. It just happens to be the way placement is implemented.
15:41:23 efried This is exactly my point

Earlier   Later