Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-22
13:49:27 fried_rice correct
13:49:29 cdent that's a good idea, but only easy to do in very limited cases
13:49:33 fried_rice right
13:49:45 mriedem stephenfin: is https://review.openstack.org/#/q/topic:bp/numa-aware-vswitches ready for a runway slot?
13:49:55 fried_rice no nested/sharing, foreknowledge of traits, ...
13:50:11 stephenfin mriedem: I think so, yes. dansmith and giblet have been actively reviewing it
13:50:17 mriedem ack, adding it to a slot
13:50:42 cdent fried_rice: based on all the other complexities we have made, that seems a rare case, or at least a hard to predict case, the way I was describing we don't need to "see" much
13:50:59 fried_rice I agree.
13:51:37 mriedem yikun: https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged) looks ready for a runway slot so i'm adding it
13:51:45 openstackgerrit Sylvain Bauza proposed openstack/nova master: libvirt: Fix the rescue race for vGPU instances https://review.openstack.org/577424
13:52:19 mriedem dansmith: 3 new things in the runways slots now so the channel topic could be updated
13:52:48 dansmith mriedem: I was going to do that runway shuffling this morning after my meeting
13:53:04 cdent melwitt, mriedem please remind me of the location of the blueprint tracking etherpad?
13:53:25 mriedem cdent: https://etherpad.openstack.org/p/nova-rocky-blueprint-status
13:53:30 openstackgerrit Edward Hope-Morley proposed openstack/nova-specs master: Add spec for extending Aggregate scheduling capabilties. https://review.openstack.org/524664
13:54:09 openstackgerrit Merged openstack/python-novaclient master: Fix help text in server-group-create https://review.openstack.org/577341
13:54:40 cdent thanks
14:00:57 openstackgerrit Andreas Scheuring proposed openstack/nova master: Add method to get cpu traits https://review.openstack.org/560317
14:03:59 openstackgerrit Eric Fried proposed openstack/nova master: Tighten up ReportClient use of generation https://review.openstack.org/556669
14:04:27 fried_rice jaypipes: mriedem, cdent: This should be ready to go now ^
14:05:06 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Deprecate 'network_manager' https://review.openstack.org/530923
14:05:28 fried_rice mriedem: IIRC, this was something you were wanting for something you were doing.
14:05:50 mriedem yeah the sync_aggregates CLI depends on it
14:05:56 mriedem but, i'm not going to work on that today
14:08:16 mriedem put a pretty nice dent in blueprints this past week, nice work folks
14:09:00 fried_rice ++
14:11:33 fried_rice cdent: Partial answer to your question about stein specs, Takashi proposed https://review.openstack.org/#/c/573602/ but it's not in yet.
14:12:09 cdent thanks
14:13:48 openstackgerrit Eric Fried proposed openstack/nova master: Bump keystoneauth1 minimum to 3.9.0 https://review.openstack.org/577431
14:13:51 fried_rice cdent: ^
14:13:58 fried_rice (for the raise_exc thing)
14:14:01 cdent huzzah
14:25:56 fried_rice cdent: Can we get rid of or consolidate nova.tests.fixtures.PlacementFixture and nova.tests.functional.api.openstack.placement.fixtures.placement.PlacementFixture at this point?
14:26:13 cdent no, they are different
14:26:25 cdent I just recently de-consolidated them
14:26:30 fried_rice merged?
14:26:59 cdent question?
14:27:51 fried_rice Is the deconsolidation proposed or merged?
14:28:13 fried_rice oh, was it part of the PlacementDirect series and I just forgot because that happened like DAYS ago?
14:28:16 cdent merged: you reviewed it: https://review.openstack.org/#/c/568359/
14:34:44 gilfoyle Hi, given a VM UUID, is it possible to follow the log trail in the controller to identify the compute node where it was created? if so, could I get some hints? Thanks :)
14:36:30 fried_rice gilfoyle: There should be a couple of request IDs in the log line. If you search the compute log for the VM UUID, you'll see in the log lines something like [req-<one_UUID> req-<another_UUID>]
14:36:56 fried_rice gilfoyle: If you take that first one, req-<one_UUID>, you should be able to search for that in the controller log and follow the flow for that whole request.
14:37:00 fried_rice gilfoyle: Is that what you were asking?
14:37:29 artom gilfoyle, if you have access to the admin APIs (which I assume you do, since you have SSH access to the hosts), just 'nova show <vm>' will have the hypervisor hostname in there somwhere
14:37:45 gilfoyle fried_rice: did you meant compute or controller node in the first message?
14:38:04 gilfoyle artom: the vm has been deleted already
14:38:05 fried_rice gilfoyle: Well, either one - anywhere you can find the instance UUID.
14:38:24 artom gilfoyle, ah, direct database access then
14:38:39 artom It's a soft-delete, so it's still there
14:38:56 gilfoyle I have full access to the cluster, I just don't know where to look :)
14:38:56 artom In fact, we might even have an API switch for that
14:39:12 gilfoyle n.b: this is mitaka, not bleeding edge OS
14:40:20 artom gilfoyle, yeah, the list servers API has a deleted param you can pass: https://developer.openstack.org/api-ref/compute/#list-servers
14:40:51 gilfoyle ah!
14:40:52 gilfoyle thanks
14:43:18 openstackgerrit Eric Fried proposed openstack/nova master: Adapter raise_exc=False by default https://review.openstack.org/577437
14:43:20 fried_rice cdent: and ^
14:43:52 fried_rice (though I might wait for zuul on that one)
15:16:57 openstackgerrit Surya Seetharaman proposed openstack/nova master: Make nova list and migration-list ignore down cells https://review.openstack.org/575734
15:24:39 openstackgerrit Merged openstack/python-novaclient master: Fix trusted-image-certificate-id help text https://review.openstack.org/576555
15:27:54 kashyap I'm blind, can someone point to the nova.conf docs in this URL here: http://logs.openstack.org/85/577385/2/check/build-openstack-sphinx-docs/e2df47c/html/
15:28:23 stephenfin kashyap: http://logs.openstack.org/85/577385/2/check/build-openstack-sphinx-docs/e2df47c/html/configuration/
15:29:37 kashyap stephenfin: Thanks; _this_ is the file I was looking for - http://logs.openstack.org/85/577385/2/check/build-openstack-sphinx-docs/e2df47c/html/configuration/config.html
15:33:57 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Unchain '_get_phynet_info' from '_get_port_vnic_info' https://review.openstack.org/564443
15:33:58 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Rename '_get_phynet_info' to '_get_network_info' https://review.openstack.org/577233
15:33:59 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Rename 'create_pci_requests_for_sriov_ports' https://review.openstack.org/575488
15:34:00 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Always retrieve network information if available https://review.openstack.org/564444
15:34:01 openstackgerrit Stephen Finucane proposed openstack/nova master: network: Retrieve tunneled status in '_get_network_info' https://review.openstack.org/564445
15:34:02 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add NUMACell.network_info https://review.openstack.org/564439
15:34:03 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add NUMATopologyLimits.networks https://review.openstack.org/575486
15:34:04 openstackgerrit Stephen Finucane proposed openstack/nova master: hardware: Start accounting for networks in NUMA placement https://review.openstack.org/564448
15:34:05 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add RequestSpec.numa_networks https://review.openstack.org/564442
15:34:06 openstackgerrit Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing RequestSpec.numa_networks https://review.openstack.org/564452
15:34:07 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440
15:34:08 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441
15:40:51 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Add RequestSpec.numa_networks https://review.openstack.org/564442
15:40:52 openstackgerrit Stephen Finucane proposed openstack/nova master: scheduler: Start utilizing RequestSpec.numa_networks https://review.openstack.org/564452
15:40:53 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Add '[neutron] physnets' and related options https://review.openstack.org/564440
15:40:54 openstackgerrit Stephen Finucane proposed openstack/nova master: libvirt: Start populating NUMACell.network_info field https://review.openstack.org/564441
15:51:26 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: conf: libvirt: Update the outdated docs for `rng_dev_path` https://review.openstack.org/577385
18:15:08 artom dansmith, I think I already know the answer, but what would be your opinion of shoving a load of XML in a nova object's StringField?
18:15:35 dansmith artom: uh huh
18:15:40 dansmith artom: libvirt xml?
18:15:41 artom (Context: it's way easier to calculate the NUMA-related bits of XML on the destination host and then send them to the source)
18:15:46 artom dansmith, yeah
18:16:05 dansmith I dunno, I've thought about it, re: the file backed stuff,
18:16:08 artom (Rather than just sending "information" so to speak)
18:16:15 dansmith but you basically end up having to do all the compatibility stuff on the other end
18:16:19 artom It doens't have to be XML per se
18:16:31 dansmith which is easier to reason about if you speak in terms of "I support this thing, IMHO
18:16:45 artom I would like to have a way to serialize the GuestConfig objects and send them over the wire
18:17:07 dansmith you might as well do that as libvirt xml, given what they represent,
18:17:23 artom OK, so not totally opposed
18:17:28 dansmith but it doesn't change the fact that it becomes potentially ugly with versions and compat
18:17:28 artom I was expecting more resistance :)
18:17:41 dansmith I'm 90% against, how's that?
18:17:49 dansmith we should have a discussion about it with more people involved
18:17:50 artom Ah, ok, I misunderstood then

Earlier   Later