| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-22 | |||
| 13:32:26 | fried_rice | Alternative would be implementing a "limit allocation candidates to this list of (root?) providers" | |
| 13:32:34 | fried_rice | Actually... | |
| 13:32:53 | fried_rice | If we know the specific host, and nested isn't in play, we could construct an allocation request without ever talking to allocation_candidates. | |
| 13:33:07 | fried_rice | With nested and/or shared, it's a bit harder, cause now we're duplicating logic. | |
| 13:33:20 | fried_rice | And btw, I'm saying we don't bother checking capacity; if the request bounces, it bounces. | |
| 13:35:11 | cdent | the point of talking to placement at all in this context, is to make sure there is capacity, so we shouldn't skip that part | |
| 13:35:20 | cdent | sorry there should be a "?|" on the end of that | |
| 13:35:31 | cdent | first day with the new keyboard | |
| 13:43:31 | fried_rice | cdent: The primary goal of talking to placement in this context is to get an allocation. If we already know which host we want to land on and what resources we want, we can just ask for that allocation. We don't need "candidates". If there's not capacity, we'll bounce (hopefully with an error code that lets us know that we bounced due to exceeded capacity as opposed to some other error). | |
| 13:44:01 | cdent | Hmm. I would have assumed we would want to bounce "sooner" | |
| 13:45:05 | fried_rice | ? | |
| 13:45:05 | fried_rice | PUT /allocations/{u} | |
| 13:45:05 | fried_rice | pick a candidate | |
| 13:45:05 | fried_rice | GET /a_c | |
| 13:45:05 | fried_rice | cdent: I haven't looked lately, but isn't the scheduler flow very tightly | |
| 13:46:29 | fried_rice | I'm saying if we know the host, we could in simple cases skip those first two steps. Because we don't need to *ask* about candidates - we can figure it out ourselves. | |
| 13:46:44 | cdent | fried_rice: no, getting null candidats back _if_ we had a way to say "this host only" | |
| 13:47:52 | fried_rice | Right, I get that, I'm brainstorming an alternative to a new microversion with yet another query param. | |
| 13:47:53 | cdent | right, and I'm saying, if (big if) we felt like adding the capability, we could avoid making the spawn call, which I assume is expensive | |
| 13:48:01 | cdent | microversions are cheap | |
| 13:48:20 | fried_rice | microversions are cheap to make, but the complexity accumulates. | |
| 13:48:43 | fried_rice | avoid making the spawn call? The spawn call happens *after* a successful PUT /allocations. | |
| 13:48:47 | mriedem | short update on runways: the 3 slots were flushed, 2 of the 3 bps were completed, the other was moved out and is blocked on neutron api changes; i've added cpu features as traits https://etherpad.openstack.org/p/nova-runways-rocky | |
| 13:49:22 | cdent | fried_rice: oh sorry, I think I misunderstood you. You're saying "construst an allocdation and try to PUT it" | |
| 13:49:22 | mriedem | Kevin_Zheng: i've held https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+status:open out of the runway slot b/c it needs to be rebased | |
| 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 | 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 | |