| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-22 | |||
| 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 | |
| 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 | |
| 18:21:28 | dansmith | using what directly? libvirt? | |
| 18:21:35 | artom | The idea would be to update the bits of the source XML that have "newer versions" in the XML from the dest | |
| 18:21:42 | artom | Using the XML | |
| 18:21:56 | artom | As in, it won't just get .format_dom() into the XML the source sends | |
| 18:22:05 | artom | It'll be cherry-picks, so to speak | |
| 18:22:13 | dansmith | my point being you pass xml from libvirt version X with nova/libvirt/qemu config Y to another host, it mangles it according to libvirt version Z and config (oops out of letters) and then passes it back, which the source then passes to the destination again in the migration, where it could fail | |
| 18:22:53 | dansmith | generating a <cpu_pinning_stuff> fragment on the destination side and passing it back to the source makes more sense to me, if that's what you mean | |
| 18:23:09 | artom | It's exactly what I mean | |
| 18:23:16 | dansmith | okay, 52% on that | |
| 18:23:34 | dansmith | however, don't we have some FooBarNUMATopology objects that self-serialize we could use in migrate data for that? | |
| 18:23:47 | artom | Yeah, which is what the spec calls for | |
| 18:23:55 | dansmith | I like that a lot better, fwiw | |
| 18:23:59 | artom | But I'd end up replicating the code that does all the calculations | |
| 18:24:11 | dansmith | why? | |
| 18:24:30 | dansmith | don't we do the hardware.fit_to_underpants code on the objects? | |
| 18:24:37 | dansmith | (I dunno, it's friday) | |
| 18:25:01 | artom | dansmith, so, starting from https://github.com/openstack/nova/blob/18.0.0.0b1/nova/virt/libvirt/driver.py#L5171 | |
| 18:25:34 | artom | The instance_numa_topology is definitely used, and if the dest would pass a few more bits of into to the source it works out sort of OK | |
| 18:25:37 | dansmith | ah, it just returns the config, okay, | |
| 18:25:48 | dansmith | the destination just needs to return the other inputs to that function right? | |
| 18:25:49 | artom | But just look at the code for _get_guest_numa_config | |
| 18:26:04 | artom | Or _get_guest_memory_backing_config | |
| 18:26:14 | artom | That would all have to done again on the source | |
| 18:26:17 | dansmith | yeah, s'pretty gross | |
| 18:26:29 | dansmith | yeah, but, who cares? | |
| 18:26:37 | artom | About what? | |
| 18:26:48 | dansmith | about doing it again on the source before a migration | |
| 18:27:02 | artom | Unless we do some major refactoring, it'd have to be new code | |