| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-20 | |||
| 10:54:27 | johnthetubaguy | yeah, there is a strong assumption about that now | |
| 10:54:30 | mgoddard | we don't have a conductor/superconductor split currently | |
| 10:55:04 | mgoddard | not even sure how that distinction is made TBH, is it just the presence of an API DB connection? | |
| 10:55:36 | johnthetubaguy | yeah | |
| 10:55:40 | johnthetubaguy | in the nova.conf | |
| 10:56:12 | johnthetubaguy | if not empty, check all cells is what it does there | |
| 10:56:48 | johnthetubaguy | I mean nova-compute shouldn't have any database strings, I think, so this is about the conductor really | |
| 10:57:12 | mgoddard | right | |
| 10:58:20 | johnthetubaguy | hmm, is that a recent change in kolla-ansible, removing the db conf from nova-compute? | |
| 11:03:49 | mgoddard | johnthetubaguy: yeah, but backported | |
| 11:08:41 | johnthetubaguy | mgoddard: ah, cool, I guess I might see that fix soon | |
| 11:12:21 | jroll | kashyap: thanks! | |
| 11:23:59 | kashyap | jroll: So, from discussion in #qemu (OFTC network): | |
| 11:24:31 | kashyap | jroll: It _is_ on disk (as you guessed): libvirt stores the state under: /var/lib/libvirt/swtpm/. It is *not* encrypted yet; however, libvirt is *capable* of it | |
| 11:25:01 | kashyap | jroll: And the relevant libvirt/QEMU devs seem to discuss the design of it, as we speak | |
| 11:26:52 | kashyap | jroll: LOL, and the QEMU dev asks me to file a libvirt RFE. Now I need to read up the relevant context to file a meaningful bug | |
| 11:29:04 | jroll | kashyap: oof, sorry I got you roped into that :/ | |
| 11:33:33 | kashyap | jroll: Apparently _another_ RFE is also required, for "swtpm" -- to let us pass keys without them being on disk. | |
| 11:34:30 | kashyap | jroll: Regardless, your question was interesting, and I learned something new. I'll let you know once the RFE bugs are filed (see how carefully I dodge the question of _who_ might file them :D) | |
| 11:35:27 | jroll | kashyap: thanks for your help with it, I do appreciate it :) | |
| 11:36:04 | jroll | now the question is, do we implement tpm passthrough in nova for the time being? or do I carry that patch downstream? :/ | |
| 11:36:59 | kashyap | jroll: Might want to also ask on the upstream list -- some operators might chime in | |
| 11:37:14 | jroll | kashyap: sorry, yes, I meant I'll email the upstream list today :) | |
| 11:38:18 | kashyap | Ah, okay :-) | |
| 11:39:32 | efried | stephenfin: I sleep. I'm actually (usually) very careful about getting enough sleep, as I find it makes all other things better. | |
| 11:51:33 | kashyap | Yes! | |
| 11:51:39 | aspiers | stephenfin: you need to try stestr run -n path.to.module.Class.test, it really does work ... | |
| 11:52:12 | kashyap | efried: In your copious free time, I vehemently suggest to read this (by a real sleep scientist, engagingly written): https://www.penguin.co.uk/books/295/295665/why-we-sleep/9780141983769.html | |
| 11:52:43 | aspiers | /dev/cft: device full | |
| 11:52:58 | kashyap | [Don't let "impressions" from the title come in your way. He writes, and speaks very engagingly and is _full_ of "signal".] | |
| 11:53:21 | efried | kashyap: oo | |
| 11:56:04 | mgoddard | that is an excellent book | |
| 11:59:18 | kashyap | Yeah, as the author, Matt Walker, dedicated 20 years (and still on going) studying sleep. | |
| 12:01:49 | stephenfin | aspiers: o rly? | |
| 12:03:33 | efried | aspiers, stephenfin: Are we highlighting -n (don't do discovery) here? | |
| 12:03:39 | stephenfin | Yuuup | |
| 12:03:44 | stephenfin | I knew it worked for files | |
| 12:03:44 | efried | ++ | |
| 12:03:50 | aspiers | see also https://github.com/mtreinish/stestr/issues/219 | |
| 12:03:51 | stephenfin | but not for Python module paths | |
| 12:04:28 | efried | Yeah, I usually can't be bothered to type the thing out, so I run it once with a substring and no -n, and then copy the test name from that output for subsequent runs with -n | |
| 12:04:39 | aspiers | yeah I do that sometimes too | |
| 12:04:47 | stephenfin | For some reason, I expected the project-team-guide to be a docs team deliverable | |
| 12:05:18 | stephenfin | I'm kind of glad it's not, since we're trying to offload what we can, but still - I want my +2 rights, dammit | |
| 12:12:17 | cdent | stephenfin: i'm certain someone will be very happy to give them to you | |
| 12:16:45 | aspiers | efried: question about implementation of https://review.opendev.org/#/c/664420/11/nova/virt/hardware.py@2144 ... | |
| 12:17:03 | efried | was just responding to that | |
| 12:17:04 | aspiers | efried: requiring each caller to implement the any() logic feels wrong | |
| 12:17:11 | efried | don't do anything drastic | |
| 12:17:18 | efried | cause I had a better idea in my sleep last night. | |
| 12:17:21 | aspiers | ah? | |
| 12:17:31 | efried | will comment, stand by. | |
| 12:17:34 | aspiers | OK! | |
| 12:22:44 | efried | aspiers: responded. | |
| 12:22:48 | aspiers | ack | |
| 12:28:57 | efried | aspiers: sane? | |
| 12:29:33 | aspiers | efried: so ditch the need to log the exact reason *why* mem encryption has been requested? | |
| 12:29:42 | rdopiera | bauzas: so about https://review.opendev.org/#/c/666394/ | |
| 12:29:43 | aspiers | I thought that was kind of useful | |
| 12:29:53 | efried | aspiers: no, I'm saying log that in the helper | |
| 12:29:57 | efried | not in the filter | |
| 12:30:00 | aspiers | oh, gotcha | |
| 12:30:15 | efried | phrased in helper-speak, not in filter-speak - see other comment | |
| 12:30:21 | aspiers | sure | |
| 12:30:30 | aspiers | so then it gets logged in the API calls too | |
| 12:30:33 | efried | yes! | |
| 12:30:39 | bauzas | rdopiera: yup, so long story there | |
| 12:30:45 | aspiers | even though that's only done for validation | |
| 12:30:49 | efried | dandy | |
| 12:30:52 | aspiers | OK | |
| 12:30:54 | efried | we're at debug, yah? | |
| 12:30:59 | aspiers | I guess so | |
| 12:31:12 | efried | If that really bothers you, add a do_log=False kwarg | |
| 12:31:18 | bauzas | rdopiera: basically, old microversions (<2.29) were forcing the destination when you were providing a target | |
| 12:31:21 | efried | but it doesn't bother me at all. | |
| 12:31:34 | aspiers | efried: nice idea, but yeah I guess it's fine anyway | |
| 12:31:39 | bauzas | rdopiera: (for live-migration and for evacuate) | |
| 12:32:10 | bauzas | rdopiera: that's why by default it's False in Nova | |
| 12:32:16 | bauzas | oops, s/False/True | |
| 12:32:31 | openstackgerrit | sean mooney proposed openstack/nova master: Revert resize: wait for events according to hybrid plug https://review.opendev.org/644881 | |
| 12:33:01 | bauzas | rdopiera: but with 2.30 microversion, we pass a 'False' value unless you have the --force option | |
| 12:34:11 | rdopiera | bauzas: what about >2.67? | |
| 12:37:25 | bauzas | rdopiera: by 2.67, we removed the --force flag | |
| 12:38:23 | bauzas | rdopiera: https://github.com/openstack/nova/commit/7aa2285e724345717a3f333adc13660d7b97dfcd | |
| 12:38:48 | bauzas | in particular https://github.com/openstack/nova/commit/7aa2285e724345717a3f333adc13660d7b97dfcd#diff-6c3b14d3964eb808ade9d3e7c5d4676d | |
| 12:39:21 | bauzas | if api_version_request.is_supported(req, min_version='2.30'): force = body["os-migrateLive"].get("force", False) force = strutils.bool_from_string(force, strict=True) | |
| 12:39:56 | bauzas | rdopiera: so Nova API defaults the force argument to False after 2.30 | |
| 12:40:22 | rdopiera | bauzas: so for >2.67 force=False always? | |
| 12:41:38 | bauzas | rdopiera: it changed a bit but https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L104-L105 | |
| 12:42:05 | bauzas | rdopiera: which does the same indeed https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/migrate_server.py#L168-L174 | |
| 12:42:40 | bauzas | rdopiera: it's just the JSON schema which changed | |
| 12:43:01 | bauzas | after 2.67, it's no longer possible to pass a force field to the API | |
| 12:43:04 | rdopiera | so in plain words, what is your recommendation for handling that in Horizon? | |
| 12:43:15 | bauzas | so it always defaults to False | |
| 12:43:36 | rdopiera | right, so we only need a special case for 2.29? | |
| 12:43:52 | bauzas | rdopiera: well, looking at https://review.opendev.org/#/c/666394/2/openstack_dashboard/api/nova.py | |
| 12:44:12 | bauzas | rdopiera: with 2.30 and later, you don't need to pass a force flag | |
| 12:45:44 | rdopiera | so something like | |
| 12:45:44 | rdopiera | if client.api_version == api_versions.APIVersion('2.29'): | |
| 12:46:29 | rdopiera | os should we just make sure to request a microversion older than 2.29 instead? | |