| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-21 | |||
| 17:37:53 | stephenfin | sean-k-mooney: Actually, that was the way that it was before tox 3.1. Since then, (b) and (c) are switched and you'll get a warning if they conflict | |
| 17:37:54 | stephenfin | sean-k-mooney: Ahh | |
| 17:38:35 | stephenfin | sean-k-mooney: Yeah, then yeah, 'python3' is good | |
| 17:38:46 | stephenfin | *Yeah, then 'python3' is good | |
| 17:39:05 | sean-k-mooney | ok thanks ill repspin with that :) | |
| 17:39:09 | stephenfin | (It'll run whatever python3 is symlinked to on the distro) | |
| 17:39:24 | sean-k-mooney | would you prefer if i had two envs or one | |
| 17:39:49 | sean-k-mooney | e.g. should i keep a functionl 2.7 env and add a functional-py3 env | |
| 17:40:10 | jaypipes | ralonsoh: ++ what sean-k-mooney said. | |
| 17:40:32 | stephenfin | sean-k-mooney: I'm happy to drop py2.7 functional tests if we still have unit tests. mriedem might have something to say as well, since he's done some work here lately, I think | |
| 17:40:51 | sean-k-mooney | actully i should check the pti docs and see what it say we should do for stien | |
| 17:40:52 | stephenfin | s/drop py2.7/switch from py2.7 to py3/ | |
| 17:42:18 | bauzas | melwitt: hum, I guess we probably have to work on https://etherpad.openstack.org/p/nova-tc-vision-self-eval | |
| 17:42:51 | melwitt | yes. I've done nothing yet :( not a great timing for this one, near the end of the cycle | |
| 17:43:14 | sean-k-mooney | stephenfin: hehe i mean i would like to drop py2.7 but we cant do that until U | |
| 17:43:16 | bauzas | I can try to think a bit about it | |
| 17:44:18 | melwitt | mriedem: thanks for making the forum brainstorm etherpad | |
| 17:44:24 | sean-k-mooney | ralonsoh: by the way i have to check your patch but if its ok with you i would prefer to default to useing the ovs-vsctl client instead of the native client for stien since we wont really have time to let it bake in the ci and see if it has issue before monday | |
| 17:44:27 | melwitt | bauzas: thanks | |
| 17:44:50 | bauzas | I guess I'll be challenged on that anyway... | |
| 17:45:39 | sean-k-mooney | ralonsoh: we can swap the default in train and or remvoe the cli client after the m1 release | |
| 17:46:17 | ralonsoh | sean-k-mooney, yes, let's see first if the native implementation works, then we can remove the CLI one | |
| 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: Create and bind Cyborg ARQs. https://review.openstack.org/631244 | |
| 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: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 | |