Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-13
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
20:59:03 artom Outright waiting? I understood it as he'll get his done, minus the working live migration stuff
20:59:09 mriedem no, i mean,
20:59:15 dansmith artom: waiting and also looking fairly impatient
20:59:21 dansmith artom: like a bus is late
20:59:22 mriedem numa networks just won't work with live migration, because numa doesn't work with live migration

Earlier   Later