| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-22 | |||
| 09:25:30 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add encrypted volume support to feature matrix docs https://review.openstack.org/570255 | |
| 09:38:16 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: Be graceful about vif plugging in early ironic driver startup https://review.openstack.org/576948 | |
| 09:39:29 | cdent | dansmith, mriedem, efried_pto: wanted to draw your attention to this bug if you hadn't already seen it: https://bugs.launchpad.net/nova/+bug/1777591 | |
| 09:39:30 | openstack | Launchpad bug 1777591 in OpenStack Compute (nova) "‘limit’ in allocation_candidates where sometimes make fore_hosts invalid" [Undecided,In progress] - Assigned to xulei (605423512-j) | |
| 09:39:43 | cdent | it's a bit unclear but I think there may be some interesting issues to extract from it | |
| 09:44:09 | openstackgerrit | Dinesh Bhor proposed openstack/nova master: Virt driver: Build guest xml https://review.openstack.org/577372 | |
| 09:54:01 | openstackgerrit | Yang Youseok proposed openstack/nova master: Add data section parameters for mkfs.xfs command https://review.openstack.org/577363 | |
| 10:17:24 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: conf: libvirt: Update the outdated `rng_dev_path` docs https://review.openstack.org/577385 | |
| 10:18:45 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: conf: libvirt: Update the outdated `rng_dev_path` docs https://review.openstack.org/577385 | |
| 10:30:13 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Not reraise DiskNotFound if instance is resized https://review.openstack.org/571410 | |
| 10:30:45 | lyarwood | mdbooth: just added you to ^ re https://bugs.launchpad.net/nova/+bug/1774249 | |
| 10:30:46 | openstack | Launchpad bug 1774249 in OpenStack Compute (nova) "update_available_resource will raise DiskNotFound after resize but before confirm" [Medium,In progress] - Assigned to Lee Yarwood (lyarwood) | |
| 10:34:20 | openstackgerrit | yanpuqing proposed openstack/nova master: Rename auth_uri to www_authenticate_uri https://review.openstack.org/576820 | |
| 10:35:11 | mdbooth | lyarwood: ack. | |
| 11:41:29 | openstackgerrit | Chason Chan proposed openstack/nova master: Fix the duplicated config options of api_database and placement_database https://review.openstack.org/577023 | |
| 12:05:27 | openstackgerrit | Jay Pipes proposed openstack/nova master: Fix bug to api-ref https://review.openstack.org/571375 | |
| 12:06:52 | openstackgerrit | Jay Pipes proposed openstack/nova master: Fix bug to filter_scheduler https://review.openstack.org/571998 | |
| 12:07:27 | jaypipes | tianhui: ^ rebased your patches. they were based on an old commit which was why they were not merging. | |
| 12:09:56 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Make nova list and migration-list ignore down cells https://review.openstack.org/575734 | |
| 13:09:15 | cdent | melwitt, or anyone else: are we happy for people to start putting specs in a stein directory yet? | |
| 13:27:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Heal allocations with incomplete consumer information https://review.openstack.org/574488 | |
| 13:30:56 | fried_rice | cdent: Looked at the bug. Seems pretty clear to me. Should we avoid sending limit down when force_hosts is set? | |
| 13:31:40 | cdent | that seems wrong to me | |
| 13:31:58 | cdent | or rather: wasteful | |
| 13:32:16 | cdent | we know which hosts we want in the response... | |
| 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 | cdent: I haven't looked lately, but isn't the scheduler flow very tightly | |
| 13:45:05 | fried_rice | GET /a_c | |
| 13:45:05 | fried_rice | pick a candidate | |
| 13:45:05 | fried_rice | PUT /allocations/{u} | |
| 13:45:05 | fried_rice | ? | |
| 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 | 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:22 | cdent | fried_rice: oh sorry, I think I misunderstood you. You're saying "construst an allocdation and try to PUT it" | |
| 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 | |