Earlier  
Posted Nick Remark
#openstack-nova - 2018-06-13
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
20:59:26 mriedem s/waiting/punting/
20:59:35 artom mriedem, great, more pressure
20:59:50 artom No wonder no one wanted to touch this for years
20:59:53 artom ;)
21:00:03 mriedem https://www.youtube.com/watch?v=SmHeP9Sve48

Earlier   Later