| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-21 | |||
| 17:47:57 | mriedem | stephenfin: on which repo? os-vif? | |
| 17:48:04 | stephenfin | mriedem: yup | |
| 17:48:19 | mriedem | i assume that job is pretty fast isn't ? | |
| 17:48:35 | sean-k-mooney | yes it is | |
| 17:48:47 | mriedem | then might as well leave it another cycle | |
| 17:48:48 | mriedem | drop in U | |
| 17:50:41 | sean-k-mooney | ok ill just add a new fucntional-py3 env then. im trying to move my dev envs over to python3 by default but there is no harm keeping the py27 one as well | |
| 17:52:48 | mriedem | fwiw functional-py27 caught an issue in one of my cross-cell changes that passed on the py35 job | |
| 17:52:59 | mriedem | something deep down in the db api layer | |
| 17:54:44 | sean-k-mooney | mriedem: i generally run both locally but there is no py3 fucntionl env currently so to run them on python3 i was locally hacking the file. | |
| 18:02:07 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access https://review.openstack.org/631242 | |
| 18:02:08 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec. https://review.openstack.org/631243 | |
| 18:02:08 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244 | |
| 18:02:09 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245 | |
| 18:03:06 | openstackgerrit | Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 18:06:18 | mriedem | alright stable cores, several +2ed changes on stable/queens ready for review https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/queens+label:Code-Review=2 | |
| 18:10:31 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Correct examples in "Manage Compute services" documentation https://review.openstack.org/638475 | |
| 18:42:26 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: [pike-only] Fix resize_instance rpcapi call https://review.openstack.org/603439 | |
| 18:52:33 | melwitt | mriedem: fyi, initial implementation for counting quota usage is done. working on organizing the patches better and adding test coverage now | |
| 19:18:34 | openstackgerrit | Merged openstack/nova master: Calculate RequestGroup resource provider mapping https://review.openstack.org/616239 | |
| 19:18:46 | openstackgerrit | Merged openstack/nova stable/rocky: Fix a missing policy in test policy data https://review.openstack.org/637085 | |
| 19:31:32 | openstackgerrit | Adam Spiers proposed openstack/nova master: Add detection of SEV support from QEMU/AMD-SP/libvirt on AMD hosts https://review.openstack.org/633855 | |
| 19:39:21 | mriedem | melwitt: ok | |
| 19:50:59 | artom | Wait, does the API handle the possibility of NoValidHost when live migrating? | |
| 19:51:57 | mriedem | artom: depends on microversion | |
| 19:52:12 | mriedem | v2.1 is an rpc call from the api to conductor to scheduler which can be a NoValidHost | |
| 19:52:25 | mriedem | i think it was 2.32 i want to say that changed that to a cast | |
| 19:52:28 | mriedem | from api to conductor | |
| 19:53:07 | mriedem | 2.34 https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id31 | |
| 19:53:58 | artom | mriedem, hrmm, but pre-2.34 it should still return a 400, not 500 | |
| 19:54:03 | artom | Which is what I'm seeing in my func tests | |
| 19:54:11 | artom | So I'm doing something wrong then, it seems | |
| 19:56:04 | artom | Which is weird, because I'm definitely catching the "new" ComputeResourcesUnavailable from the claims, and re-raising it as a MigrationPreCheckError | |
| 19:56:10 | artom | Which the conductor *catches* | |
| 19:56:15 | artom | Or should, according to the code | |
| 19:56:23 | mriedem | is your test using the CastAsCall fixture? | |
| 19:57:52 | artom | Huh, do func tests use it by default? | |
| 19:58:09 | mriedem | no, but you might be extending a class that uses it | |
| 19:58:40 | artom | Ah, yeah, _IntegratedTestBase | |
| 19:58:50 | artom | Oh, that would be why the NoValidHost ends up in the API | |
| 19:59:17 | artom | Heh, can I "unuse" a single fixture? | |
| 20:14:56 | artom | No, there's something else. | |
| 20:15:18 | artom | It dies on the select_destinations call (which is always a call) in _find_destinations in the live migrate task | |
| 20:16:28 | artom | I... I think this exists in master as well. | |
| 20:30:32 | mriedem | jaypipes: so i'm not sure if my comments in here warrant a -1 or if it's just follow up fodder https://review.openstack.org/#/c/619528/ | |
| 20:30:56 | mriedem | but there are some serious performance impacts there if you're doing multi-create and not actually doing fancy port bw scheduling | |
| 20:32:44 | artom | Hrmm, or not. | |
| 20:32:59 | jaypipes | mriedem: multi-create meaning multiple instances in the same request, yeah? | |
| 20:33:04 | mriedem | yeah | |
| 20:33:09 | jaypipes | mriedem: mayhaps. | |
| 20:33:11 | mriedem | but this is even heavy for a single instance | |
| 20:33:25 | mriedem | post-scheduler, call placement to get allocations and traits for each provider in those allocations | |
| 20:33:32 | mriedem | for an instance that might not even have one of these fancy ports | |
| 20:33:34 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: De-shim PlacementFixture https://review.openstack.org/637959 | |
| 20:39:32 | jaypipes | mriedem: which is kinda what I said in the original review.. | |
| 20:39:57 | jaypipes | mriedem: but the alternative is to unpack the JSON in the Selection.allocation_request field blobified goop. | |
| 20:40:31 | mriedem | that won't work, | |
| 20:40:39 | mriedem | oh wait | |
| 20:40:47 | mriedem | maybe it will because that has the resource provider uuid in it right? | |
| 20:41:03 | mriedem | it's just a json version of https://developer.openstack.org/api-ref/placement/#update-allocations | |
| 20:41:22 | mriedem | yeah dude that's way faster than hitting placement for each instance | |
| 20:41:38 | mriedem | well, *should be* faster | |
| 20:44:53 | mriedem | that's also potentially the same Selection object (allocation_request) for multiple servers in the same build operation | |
| 20:45:19 | mriedem | so deserialize once rather than GET /allocations/{consumer_id} x number of instances | |
| 20:47:38 | jaypipes | mriedem: ack. | |
| 20:48:16 | mriedem | we can follow up also and avoid that GET /resource_provider/{rp_id}/traits call yeah? by stashing the GET /a_c provider_summaries traits per provider on the Selection object we return from the scheduler | |
| 20:48:17 | jaypipes | mriedem: which violates our original intention that the allocation_request would be a BLOBby thing that could be sent as-is as the request payload to placement on the event of a reschedule/retry operation] | |
| 20:48:20 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: De-shim PlacementFixture https://review.openstack.org/637959 | |
| 20:48:39 | jaypipes | mriedem: but as you say, it's considerably faster than re-querying placement for each instance | |
| 20:48:47 | mriedem | i'm not sure how it violates that | |
| 20:49:16 | mriedem | for the first selection in the list, it's allocatoin request has already been 'consumed' | |
| 20:49:18 | jaypipes | mriedem: well, it violates the principle that the allocation_request's structure could change and nothing in nova would need to be changed. | |
| 20:49:26 | jaypipes | mriedem: yes, understood. | |
| 20:49:43 | jaypipes | again, this was the original thought... things have changed/softened in our thinking since then | |
| 20:49:44 | jaypipes | :) | |
| 20:49:53 | mriedem | i'm not sure what you're saying :) | |
| 20:50:11 | mriedem | it's still a string on the selection object, in this code we just deserialize that field to get the rp uuids | |
| 20:50:22 | mriedem | well, the actual allocations i guess | |
| 20:50:28 | jaypipes | it's not just the rp uuids. | |
| 20:50:33 | jaypipes | yeah, it's all the allocation info | |
| 20:50:47 | mriedem | i guess what you're saying is we'd be treating the allocatoin request like a response | |
| 20:50:49 | mriedem | when it's not | |
| 20:51:04 | jaypipes | and of course, if we change the structure of the allocation_request response, boom, that "deserialize this blob and inspect it" code would of course need to change | |
| 20:51:11 | jaypipes | mriedem: yes. | |
| 20:51:37 | jaypipes | mriedem: I'm just trying to give you some background on why that's a JSON string and not an object :) | |
| 20:51:54 | mriedem | yeah i remember | |
| 20:52:00 | mriedem | and why we also provider the version | |
| 20:52:01 | jaypipes | ok, I will go away now | |
| 20:52:03 | mriedem | *provide | |
| 20:52:07 | mriedem | don't go away jay | |
| 20:52:09 | mriedem | please stay | |
| 20:52:09 | jaypipes | :P | |
| 20:52:29 | openstackgerrit | Merged openstack/nova stable/queens: Fix a missing policy in test policy data https://review.openstack.org/637112 | |
| 20:52:37 | openstackgerrit | Merged openstack/nova stable/rocky: tox: Don't write byte code (maybe) https://review.openstack.org/636917 | |
| 20:55:10 | mriedem | so maybe what i'll do is pull this down, put in the very easy "if the request spec doesn't have requested_resources, don't do anything with this new code" thing, leave a bunch of todos for gibi to follow up | |
| 20:55:24 | mriedem | that solves 99% of my performance worry | |
| 20:55:44 | mriedem | jaypipes: ^ how do you like that? | |
| 20:57:01 | efried | mriedem: That sounds like a pretty reasonable solution to me. And you would be doing it rather than letting gibi do it because... you want to get it merged today? | |
| 20:57:14 | mriedem | yes | |
| 20:57:21 | mriedem | time is as they say of the essence | |