Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-22
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 artom In fact, we might even have an API switch for that
14:38:56 gilfoyle I have full access to the cluster, I just don't know where to look :)
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 artom I was expecting more resistance :)
18:17:28 dansmith but it doesn't change the fact that it becomes potentially ugly with versions and compat
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
18:17:52 dansmith maybe in a spec or something
18:18:02 artom Heh, that boat has sailed, for this cycle at least
18:18:26 dansmith I'm saying I know why you want to do it, I don't have a great alternative, but so far we've done it with flags to indicate what I support and am configured for
18:18:55 dansmith maybe letting the other end manipulate its own xml is a better model, I dunno, but I'm afraid of the box it opens I guess
18:19:07 dansmith so to back the 90% down I want to think and discuss
18:19:28 dansmith on the one hand it's kinda awkward that libvirt makes the sending side calculate the xml for the destination, which is why we have this problem
18:20:31 artom Well, both hosts know a bit, but don't have the whole picture
18:20:40 dansmith but, I dunno, generating xml in the ether without somewhat insta-validation like we get from passing it straight to libvirt is a recipe for weird issues I think
18:20:43 artom So, I think it makes more sense for the source to do it, but yeah, not idea
18:20:45 artom *ideal
18:21:08 artom Well, I wouldn't be using it directly

Earlier   Later