| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-13 | |||
| 20:11:41 | melwitt | I've seen people get stuck if they had an old url that ends in /v2.0, that would prevent you from ever getting any new microversions | |
| 20:11:51 | jmlowe | https://iu.jetstream-cloud.org:8774/v2/e0c43302e9a740a480d05381d20aa66e/os-server-groups | |
| 20:14:01 | jmlowe | hmm which probably comes from /v2/%(tenant_id)s | |
| 20:15:26 | melwitt | I think that v2 there is wrong, that will prevent you from getting microversions | |
| 20:15:39 | melwitt | it should be v2.1 | |
| 20:15:58 | jmlowe | yep, that endpoint dates all the way back to kilo probably | |
| 20:16:18 | jmlowe | and I now get my microversions | |
| 20:16:40 | melwitt | yeah, the folks at Oath ran into the same thing, upgrading from Juno, they had an old school url in the service catalog that they needed to update to v2.1 | |
| 20:17:24 | jmlowe | thanks melwitt and mriedem! | |
| 20:18:16 | mriedem | i was just wondering that too | |
| 20:18:21 | melwitt | we have a cells v2 faq but not a general faq | |
| 20:18:24 | mriedem | we don't really have faqs, only for cells v2 | |
| 20:18:45 | mriedem | it's likely already on ask.o.o but not sure how discoverable it would be since it's a really obscure problem | |
| 20:19:08 | mriedem | it wouldn't be asked as "microversions don't work", it would be, "operation foo" doesn't work | |
| 20:19:50 | melwitt | yeah, agreed | |
| 20:21:13 | mriedem | the endpoint creation here in the install guide is correctly v2.1 https://docs.openstack.org/nova/latest/install/controller-install-ubuntu.html | |
| 20:21:23 | mriedem | but there is/was nothing like that for upgrades from pre-microversions to microversions | |
| 20:21:30 | mriedem | lucky if anything was in the pre-reno release notes worki | |
| 20:21:32 | mriedem | *wiki | |
| 20:21:54 | mriedem | https://wiki.openstack.org/wiki/ReleaseNotes/Kilo#OpenStack_Compute_.28Nova.29 | |
| 20:22:39 | mriedem | sad trombone http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html#other-deployer-impact | |
| 20:23:13 | melwitt | yeah, was thinking similar if it was part of the upgrade reno when microversions came into existence | |
| 20:23:26 | melwitt | that's where we'd need to signal people ideally | |
| 20:24:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Don't heal allocations for deleted servers https://review.openstack.org/575222 | |
| 20:24:19 | mriedem | mgagne: thar she blar ^ | |
| 20:25:14 | mgagne | mriedem: lgtm | |
| 20:25:17 | dansmith | mriedem: so.. we could have stale allocations for deleted instances, right? | |
| 20:25:23 | mgagne | mriedem: I see potential with the filters variable | |
| 20:25:28 | dansmith | I guess compute will actually nuke those? | |
| 20:25:45 | mgagne | dansmith: afaik, the tool doesn't delete stalled allocations? | |
| 20:26:04 | dansmith | I'm just thinking | |
| 20:26:22 | dansmith | if it's in the db as deleted, compute will actually clean them up I think | |
| 20:26:23 | mgagne | next iteration of the tool =) | |
| 20:26:30 | dansmith | that's the only case it cleans up now, IIRC | |
| 20:27:17 | mgagne | which db is used to list instances? nova_api? | |
| 20:27:29 | dansmith | no, the cell | |
| 20:27:34 | dansmith | the instances only live there | |
| 20:27:47 | mgagne | but there is an instance_mapping in nova_api | |
| 20:27:51 | dansmith | and we don't have deleted= flags in the api db | |
| 20:27:57 | mgagne | so I thought maybe it could read something from here first | |
| 20:28:13 | dansmith | we don't know much at all about the instance in the api db | |
| 20:28:14 | mgagne | yea, that was the point I wanted to make | |
| 20:28:26 | melwitt | efried: is the bp you had mentioned at the onboarding session as completed but not marked as completed still not marked completed here? https://blueprints.launchpad.net/nova/rocky | |
| 20:28:31 | mgagne | right | |
| 20:31:34 | jmlowe | ok, one more, after changing the endpoint nova client ignores https but osc does the right thing | |
| 20:33:48 | mriedem | jmlowe: which version of novaclient? | |
| 20:33:52 | mriedem | the https thing sounds familiar | |
| 20:34:08 | jmlowe | 9.1.0 | |
| 20:35:15 | jmlowe | weird, in debug the curl hint does the right thing REQ: curl -g -i -X GET https://iu.jetstream-cloud.org:8774/v2.1 -H "User-Agent: python-novaclient" -H "Accept: application/json" | |
| 20:35:46 | jmlowe | client tries http in spite of this | |
| 20:38:36 | mriedem | i bet andreykurilin would remember the https thing in novaclient i'm trying to think of | |
| 20:41:02 | mriedem | i'm thinking of this https://github.com/openstack/python-novaclient/commit/bd0a2adefe5e89c4269f6589837f871764c6f1f6#diff-815379030879ca27268b9336fecbe7dc | |
| 20:41:06 | mriedem | but that's in 9.1.0 | |
| 20:47:35 | artom_ | dansmith, so, about https://review.openstack.org/#/c/566398/ - is a MigrationContext created for live migration, and if so, where? | |
| 20:47:52 | dansmith | just a sec | |
| 20:48:02 | dansmith | it's different for live (ofcourse) | |
| 20:48:35 | artom_ | dansmith, heh - I'm going by the spec (https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html), so this migration context business is news to me | |
| 20:48:48 | artom_ | I saw it for cold migration, but couldn't find anything for live | |
| 20:49:06 | dansmith | oh, you know, | |
| 20:49:13 | dansmith | I might be confusing the migration with the context actually | |
| 20:49:25 | artom_ | Admittedly, migration and claims aren't areas I know well | |
| 20:49:27 | dansmith | we weren't doing that for live migration before I added it for the double claim fix | |
| 20:49:37 | dansmith | but yeah you might be right actually | |
| 20:50:16 | dansmith | so, I think we don't claim anything on the destination for live migration, IIRC | |
| 20:50:23 | dansmith | so I'm not sure what sahid means about the claiming part | |
| 20:51:04 | artom_ | dansmith, we do stuff with placement allocations, that's for sure | |
| 20:51:20 | dansmith | artom_: for the base resources, but not numa | |
| 20:51:28 | mriedem | we don't do claims for live migration | |
| 20:51:31 | dansmith | hence my comment on the later one | |
| 20:51:41 | artom_ | dansmith, right, and NUMA isn't ready in placement, so we're using RT for now (right?) | |
| 20:51:55 | dansmith | artom_: RT for numa, and not for live migration | |
| 20:51:57 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L74 | |
| 20:53:21 | jmlowe | uh oh, seems I broke horizon as well as nova cli | |
| 20:54:03 | artom | We definitely create a Migration, nova/conductor/manager.py L404, but I didn't find any MigrationContext | |
| 20:54:07 | mriedem | i want to make a 'damn it jim' joke | |
| 20:54:14 | mriedem | artom: the migratoin context is in the RT | |
| 20:54:17 | jroll | damn it matt | |
| 20:54:17 | mriedem | which doesn't track live migratoins | |
| 20:54:28 | artom | And the Migration only has the basic stuff in it, source, dest, etc | |
| 20:54:43 | mriedem | we also have the migration record for tracking allocations in placement during the move | |
| 20:54:48 | mriedem | so they aren't doubled on the instance | |
| 20:54:50 | artom | Also, MigrateData was specifically created to include virt-specific stuff, which this kinda is | |
| 20:55:20 | dansmith | artom: it was yeah | |
| 20:55:20 | mriedem | migrate data is definitely for, and only used by, live migration | |
| 20:55:35 | dansmith | artom: I think you're fine on this, I just wasn't thnking | |
| 20:55:43 | artom | dansmith, ooof, thanks :) | |
| 20:55:47 | mriedem | artom: we're all counting on you, good luck | |
| 20:56:04 | artom | mriedem, only if you review it ^_^ | |
| 20:57:01 | artom | mriedem, so wait, how do I go about claiming the NUMA resources on the dest? Does RT need to start tracking LM now? | |
| 20:57:24 | artom | Or can claims be done "independently", so to speak? | |
| 20:57:40 | mriedem | having never read that spec yet, i defer | |
| 20:58:05 | dansmith | artom: you don't want to go down that rabbit hole | |
| 20:58:06 | dansmith | take the other pill | |
| 20:58:16 | artom | mriedem, heh, fair about, I think hay and sylvain are on the hook for that, maybe stephen | |
| 20:58:20 | artom | *fair enough | |
| 20:58:22 | mriedem | i honestly don't know what the numa resource claim code looks like | |
| 20:58:23 | dansmith | artom: IMHO, get your stuff working without claims, like everything else does currently related to live, and then point at placement as the gap that will fix it | |
| 20:58:25 | mriedem | i intentionally avoid that mess | |
| 20:58:36 | artom | dansmith, it does seem like a massive rabbit hole | |
| 20:58:42 | mriedem | artom: stephenfin said he was waiting for you to do numa live migration for his numa networks stuff | |