| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-20 | |||
| 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 | efried | ++ | |
| 12:03:44 | stephenfin | I knew it worked for files | |
| 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 | if client.api_version == api_versions.APIVersion('2.29'): | |
| 12:45:44 | rdopiera | so something like | |
| 12:46:29 | rdopiera | os should we just make sure to request a microversion older than 2.29 instead? | |
| 12:46:34 | bauzas | well, you would then change the UX right? | |
| 12:47:03 | rdopiera | I think that was the idea behind the reported issue in the first place | |
| 12:47:13 | bauzas | remember, before 2.30, it wasn't possible to not force a destination | |
| 12:48:03 | bauzas | it was either possible to either pass a destination and then force to it without checking the scheduler *or* not pass a destination and then the scheduler would be giving you some target | |
| 12:48:06 | bauzas | rdopiera: ^ | |
| 12:48:15 | rdopiera | and after 2.67 it's impossible to force it | |
| 12:48:22 | bauzas | correct | |
| 12:48:33 | rdopiera | so there is going to be a change at some point either way | |
| 12:48:44 | bauzas | so, I'd recommend you to not ask for a target with 2.29 and older | |
| 12:49:14 | bauzas | and for 2.30, accept a target by defaulting to not force to it | |
| 12:49:39 | bauzas | that actually depends on what kind of user experience you'd like to provide | |
| 12:50:15 | bauzas | the force flag was just a way to keep the same behaviour for some time | |
| 12:51:30 | rdopiera | personally I don't feel like I have enough knowledge about Nova to decide on user experience, I would rather ask for recommendation from people who designed it | |
| 12:52:53 | rdopiera | you know what, how about I just abandon that patch and close the bug with "current version" explaining that later versions of the api behave as expected? | |
| 13:23:21 | mriedem | o/ | |
| 13:23:30 | sean-k-mooney | o/ | |
| 13:33:10 | bauzas | rdopiera: whoops, missed your question | |
| 13:33:38 | efried | kashyap: "Book will arrive tomorrow" --Renae (aka wife aka personal shopper) | |