Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-28
15:17:33 dansmith it's that everyone's systems report numa stuff, and if any of this works on a numaless guest instance for CI but is weird on a real system... we won't have coverage of that
15:17:34 mriedem mrhillsman: would it be possible to use openlab for numa testing for nova?
15:17:37 sean-k-mooney artom: wether they are a blocker on not is seperate form if we should write them an i think we would all like to see functional tests for this eventually
15:18:41 artom sean-k-mooney, oh yeah, they'll be there
15:19:09 dansmith also, some amount of live migration of numa-having instances works today but just doesn't claim or do the right thing, right?
15:19:14 artom I'm wondering more "what gives others better confidence in the code to help it merge, automated integration tests that you have to run manually in your own env, or func tests?"
15:19:29 dansmith if we were to break that in a way that doesn't let people move their instances in an emergency, even if the numaness gets messed up, that's still a big problem I think
15:19:55 mrhillsman mriedem yes sir
15:20:28 sean-k-mooney dansmith: if the cpus are free on the destination then today everything works for pinned instance
15:20:37 sean-k-mooney similarly for hugepage instnace
15:20:39 dansmith right
15:21:04 sean-k-mooney the clamims get updated too i think
15:21:11 dansmith so if we break that in this because we didn't test it on real systems... that's not "the situation can't get worse" to me
15:21:25 sean-k-mooney they are either healed by the periodic task or done explicitly i cant remember
15:22:09 mrhillsman so long as we can provide what is needed. filling out https://github.com/theopenlab/openlab/issues/new?template=test-request.md with what is needed is required
15:22:47 artom sean-k-mooney, periodic task
15:24:26 mriedem mrhillsman: ah cool ok, i'll put this in our ptg agenda for discussion to see what minimum levels of testing we'd hope to get
15:24:27 sean-k-mooney mrhillsman: do numa testing we would need either nested virt on a host with at least 2 numa nodes or a dual numa beremetal host
15:24:32 mriedem mrhillsman: btw, who writes the tests? or is tempest used?
15:24:38 cfriesen sean-k-mooney: mriedem: hypervisor check bug is https://bugs.launchpad.net/nova/+bug/1818092
15:24:39 openstack Launchpad bug 1818092 in OpenStack Compute (nova) "hypervisor check in _check_instance_has_no_numa() is broken" [Undecided,New]
15:25:31 sean-k-mooney cfriesen: cool can you add "Close-Bug: 1818092" to the commit in your patch
15:25:41 cfriesen yup, doing it now
15:25:46 sean-k-mooney awsome
15:25:52 mrhillsman mriedem you or some volunteers would
15:26:23 artom Unless it's like, in Perl or JS or something.
15:26:23 sean-k-mooney mriedem: we hope to move the redhat whitebox tempest plugin to openstack namespace
15:26:31 mrhillsman there is a lot of flexibility in how that works
15:27:36 mrhillsman i think adding to the ptg is good if it is not a priority right now
15:27:46 mriedem yup done L77 https://etherpad.openstack.org/p/nova-ptg-train
15:28:04 mrhillsman cool, i will be sure to be there
15:28:09 mriedem maybe chenrui's team can help a bit, i.e. Kevin_Zheng since he is familiar with nova
15:28:15 mrhillsman ++
15:30:07 openstackgerrit Chris Friesen proposed openstack/nova master: fix up numa-topology live migration hypervisor check https://review.openstack.org/635350
15:31:51 cfriesen sean-k-mooney: mriedem: there you go ^
15:34:48 mriedem stephenfin: i saw your patch to deprecate config_drive_format for vfat
15:34:53 mriedem stephenfin: and it reminded me of this https://review.openstack.org/#/c/567860/
15:35:12 cfriesen anyone know why requirements-check is failing for https://review.openstack.org/#/c/631363 ? It says "Package 'os-traits' is constrained to 0.4.0 which does not match the minimum version specifier 0.11.0 in requirements.txt"
15:35:17 mriedem stephenfin: i'm not 100% but i don't think we actually test live migration in the gate with a config drive on the instance
15:35:21 bauzas mriedem: yeah we agreed on following the deprecation path this morning
15:35:26 mriedem stephenfin: it would be good to have that wrinkle somewhere
15:35:33 mriedem bauzas: sure i understand, but that's not my point
15:35:36 bauzas ok
15:35:45 mriedem my point is we don't test live migration + config drive
15:35:47 openstackgerrit Merged openstack/nova master: conf: Call out where pci.alias should be set https://review.openstack.org/624445
15:35:49 mriedem i don't think
15:36:19 mriedem so we might want to consider forcing config drive in our nova-live-migration job,
15:36:23 mriedem or the grenade live migration job
15:37:06 mriedem i think we also do everything with qcow2 image backend
15:37:11 mriedem and in https://review.openstack.org/#/c/567860/ i changed it to use raw
15:37:25 mriedem which is another wrinkle we don't really touch
15:39:23 cfriesen okay, why do we specify minimum package versions in both lower-constraints *and* requirements.txt?
15:40:10 mriedem tonyb: ^
15:40:48 jangutter cfriesen: because the computer likes repetition because the computer likes repetition (paranoia reference)
15:42:11 jangutter cfriesen: I found this ( https://docs.openstack.org/project-team-guide/dependency-management.html ) a while ago and I'm not 100% sure.
15:42:13 openstackgerrit Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363
15:42:14 openstackgerrit Chris Friesen proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.openstack.org/639934
15:44:08 sean-k-mooney cfriesen: proably pinned in upperconstraitns
15:44:25 cfriesen sean-k-mooney: turns out I missed updating lower_constraints
15:44:32 sean-k-mooney oh ok
15:45:27 sean-k-mooney i chekcked that but you had already fixed it when i did i guess
15:46:37 cfriesen sean-k-mooney: don't know if you saw my comment last night....this patch series ^ is working as far as local resize with emulated TPM.
15:46:51 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:48:27 sean-k-mooney cfriesen: im reworking https://review.openstack.org/#/c/602432/ but that is next on my list
15:49:05 cfriesen cool. I'm working on adding more unit tests to bring it up to the proper level.
15:54:18 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add remove_resources_from_instance_allocation to report client https://review.openstack.org/639653
15:54:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:55:04 gibi mriedem, jaypipes: the bottom two patches are up to date ^^ (and I think they are ready to fly)
15:55:32 mriedem looking
15:55:37 openstackgerrit Matt Riedemann proposed openstack/nova master: Test live migration with config drive https://review.openstack.org/567860
16:01:31 gibi mriedem: regarding filing InstancePCIRequest.requester_id with flavor.flavorid or network_id . Which one do you prefere? Fill it properly (e.g. use flavor.flavorid) or keep it None and fill it only when it is needeD?
16:02:20 mriedem gibi: i haven't yet looked at how that is used,
16:02:33 mriedem and i saw avolkov asked about a requester_type,
16:03:02 mriedem my one worry is that we have something in that field which isn't a port_id, but we assume it's a port_id and then something fails later because it turns out it was a flavor or network
16:03:26 mriedem so maybe it's better to not set it for flavor/network in order to avoid confusion about when it can be used
16:04:12 mriedem i guess you are future-proofing for when flavor resources are in a RequestGroup in the RequestSpec?
16:04:22 gibi mriedem: InstancePCIRequest.requester_id is matched against RequestGroup.requester_id
16:04:35 gibi mriedem: in https://review.openstack.org/#/c/623543/34/nova/compute/manager.py
16:05:03 gibi so it is a bit of future proofing yes, but now I feel it would be better to keep it empty
16:05:29 gibi so I think I will remove the flavor.id and netwokr_id bits
16:05:33 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Use aggregate_add_host in nova-manage https://review.openstack.org/640080
16:05:40 efried mriedem: This bud's for you ^
16:05:45 efried ...bud
16:06:27 mriedem gibi: that is probably safest
16:06:31 efried mriedem: LMK if you're on board with it conceptually and I'll fix up the testes.
16:06:36 gibi mriedem: OK, cool
16:07:16 efried mriedem: in particular, if you think I should split out the aggregate_add_host signature change.
16:07:21 mriedem gibi: worst case is we'd set the InstancePCIRequest.request_id to a flavor.flavorid (which makes sense if the pci request comes via the flavor), and then we try finding the matching request group mapping and it's not found, so we just wasted time looking for something that we never setup
16:07:37 gibi mriedem: agreed
16:07:40 mriedem well, i guess worst case is ^ and we log something like "couldn't find mapping" or raise or something
16:07:45 gibi mriedem: it was to early to add it
16:07:51 mriedem you're ahead of your time
16:07:55 gibi yeah
16:08:22 mriedem efried: i can't digest that right now
16:08:34 efried mriedem: No urgency
16:24:55 openstackgerrit Balazs Gibizer proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310
16:25:38 gibi jaypipes, mriedem: and the third one is up-to-date as well
16:29:28 mriedem gibi: +2 on https://review.openstack.org/#/c/622421/ - nits inline so it's up to you if you want to address those quick or follow up
16:30:04 gibi mriedem: I think I can respin it real quick
16:33:58 gibi mriedem: FYI ALLOCATIN for https://review.openstack.org/#/c/622421/32/nova/network/neutronv2/api.py@1734 need a rebase first.

Earlier   Later