| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 23:14:00 | mriedem | oh i guess we'd just fallback to doing what we did before right? | |
| 23:15:38 | aspiers | mriedem, efried: fixed version is now uploaded https://review.openstack.org/#/c/538498/19..20//COMMIT_MSG | |
| 23:15:46 | aspiers | mriedem, efried: now I will rebase and fix the conflict | |
| 23:15:56 | mriedem | jroll: check my logic in here https://review.openstack.org/#/c/636699/ | |
| 23:16:59 | melwitt | seems like it would fall back, given that vm_power_state is passed into the method and the new code just overwrites it if the driver can pull from not cache | |
| 23:17:11 | mriedem | yeah ok | |
| 23:17:43 | openstackgerrit | Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 23:18:16 | aspiers | mriedem, efried: now rebased in patch set 21 | |
| 23:19:15 | efried | aspiers: looking. Will try to get it done before I have to leave for class... | |
| 23:19:24 | aspiers | efried: thanks :) | |
| 23:20:17 | efried | else mañana | |
| 23:25:49 | efried | aspiers: Done, that was pretty easy. | |
| 23:26:06 | efried | great work there, Adam, really appreciate you picking that up and sticking with it through all our waffling. | |
| 23:26:18 | aspiers | :) | |
| 23:28:49 | openstackgerrit | Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 23:29:14 | aspiers | efried: nit addressed | |
| 23:29:51 | openstackgerrit | Merged openstack/python-novaclient master: Add support for microversion 2.70 - expose device tags https://review.openstack.org/636779 | |
| 23:30:12 | efried | aspiers: +2 again. Assuming others don't notice, we've asserted a design statement there about trait namespacing :) | |
| 23:30:20 | mriedem | melwitt: Kevin_Zheng: artom: dansmith: see if we're in agreement with this summary of the nova meeting discussion about the root volume detach/attach + tag issue http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003367.html | |
| 23:30:24 | aspiers | efried: right ;-) | |
| 23:32:28 | Kevin_Zheng | mriedem: thanks for putting this up, I agree with the current agreement | |
| 23:34:50 | melwitt | mriedem: yeah, matches my understanding. I get that it's not great to go half-baked, but I tend toward it being nicer to make some progress and not have to dump context and start all over again from a mental standpoint. reloading the concept is still necessary but I personally still find it easier when partial support has landed, vs not | |
| 23:57:51 | mriedem | Kevin_Zheng: so i didn't look yet, but you added the code to change the RequestSpec.image when attaching a new root volume? | |
| 23:57:56 | mriedem | so that unshelve will schedule properly? | |
| 23:58:22 | Kevin_Zheng | Yeah I did that and also added a test | |
| 23:58:49 | mriedem | https://review.openstack.org/#/c/623981/21/nova/tests/functional/test_attach_detach_root_volume.py | |
| #openstack-nova - 2019-03-01 | |||
| 00:03:17 | dansmith | mriedem: melwitt Kevin_Zheng: sent a reply to the list | |
| 00:05:39 | Kevin_Zheng | dansmith: cool, thanks, will check it later | |
| 00:06:14 | dansmith | Kevin_Zheng: no, you will check it now! | |
| 00:06:19 | dansmith | I mean, of course :P | |
| 00:07:43 | mriedem | Kevin_Zheng: i left some comments in that functional test | |
| 00:08:19 | mriedem | Kevin_Zheng: i'd like to see a functional test that exercises that when attaching a new root volume with a new image, we properly update the request spec to ensure we unshelve on a host that only works for that new image | |
| 00:09:16 | melwitt | I definitely sympathize with the idea of not wiping the tag on detach. that was my worry, was someone not realizing that would happen | |
| 00:10:29 | melwitt | I need more brain to think about the rest of it right now | |
| 00:12:43 | mriedem | where the virus lives | |
| 00:12:46 | mriedem | nice | |
| 00:17:32 | Kevin_Zheng | mriedem: I will try to write one today | |
| 00:17:53 | melwitt | a virus? geez kevin | |
| 00:19:11 | artom | mriedem, I don't even know anymore. I saw we revert device tagging altogether, who needs it anyways? | |
| 00:19:15 | artom | *say | |
| 00:21:29 | Kevin_Zheng | melwitt: I will try my best:) | |
| 00:21:55 | Kevin_Zheng | Check the news tomorrow | |
| 00:22:02 | melwitt | :D | |
| 00:23:57 | mriedem | trump told us we can't trust those huawei guys | |
| 00:24:03 | artom | Out of curiosity, do we have a way to scope CONF objects (fixtures?) to a single service in func tests - specifically, I want 2 computes with different vcpu_pin_set (for example) | |
| 00:24:28 | mriedem | dansmith: Kevin_Zheng: replied with some questions for clarification - i know it's getting late so probably have to pick this up tomorrow | |
| 00:24:46 | mriedem | Kevin_Zheng: regardless of the tag decision, my comments on the functional tests are probably enough to keep you busy for a bit | |
| 00:25:28 | mriedem | artom: since CONF is global changes are no | |
| 00:25:39 | mriedem | *chances | |
| 00:25:48 | melwitt | artom: I _think_ you can do that by self.flags(value for compute 1) start compute service 1, self.flags(value for compute 2), start compute service 2 | |
| 00:25:51 | mriedem | there is a ConfFixture, and fixtures are context managers, | |
| 00:26:02 | mriedem | so it's possible you could temporarily set config via context | |
| 00:26:11 | melwitt | but maybe it won't stick, if it's going to look at it after startup | |
| 00:26:42 | mriedem | i'm going to be in big trouble for not getting dinner started so i have to run | |
| 00:26:47 | melwitt | yeah, maybe what I said would only work if it's a conf value only considered during init_host | |
| 00:27:04 | artom | Reason I'm asking is - without this, I don't see a way to func test NUMA LM meaningfully | |
| 00:27:11 | artom | melwitt, that'd be enough, I tihnk | |
| 00:27:19 | dansmith | melwitt: only if the values are read and cached at start | |
| 00:27:32 | dansmith | when I wrote the oschown thing, I chased that down | |
| 00:27:35 | dansmith | it's a huge problem | |
| 00:27:40 | melwitt | yeah, I think it won't work if the conf option is read later on | |
| 00:27:48 | dansmith | in that it's completely fundamentally global as heck forever | |
| 00:27:53 | melwitt | but I know I've done something like this before in func test where it was startup only | |
| 00:27:57 | melwitt | haha yeah | |
| 00:28:17 | dansmith | melwitt: right, if it's read at startup and ever again, and it does that before the start returns, then it'll work, but it's fragile | |
| 00:28:36 | melwitt | yeah. definitely not saying it's robust | |
| 00:28:40 | artom | Bleah, vpcu_pin_set is read after startup | |
| 00:28:48 | melwitt | it's the kind of janky thing I do in tests when I find them | |
| 00:29:01 | melwitt | after the desperation sets in | |
| 00:30:21 | artom | dansmith, so, we can follow up on ML, but I think that rules out NUMA LM func testing? | |
| 00:30:35 | artom | I don't see another way to "force a conflict", so to speak | |
| 00:31:02 | dansmith | artom: it means you have to mock something out, which we try to avoid in functional tests, but can't really avoid for hardware things (like virt driver stuff) | |
| 00:31:06 | dansmith | which is why functional is not enough | |
| 00:31:37 | artom | dansmith, mock to different values with 2 compute services running? | |
| 00:31:52 | dansmith | artom: mock somewhere other than config | |
| 00:32:07 | dansmith | artom: we have useful functional tests for other things that depend on global state | |
| 00:32:18 | dansmith | it's not trivial to do, but it's doable | |
| 00:32:34 | artom | dansmith, can I have an example? I'll use that as inspiration :) | |
| 00:33:12 | dansmith | artom: the cells stuff all depends on a completely global DB state | |
| 00:33:58 | dansmith | it's been a challenge to get that stuff working because it's so global, but like numa, it's hard to test multiple cells for real, so they're quite useful | |
| 00:34:32 | artom | dansmith, NUMA is a matter of hardware | |
| 00:34:46 | dansmith | what's your point | |
| 00:34:47 | dansmith | ? | |
| 00:34:54 | artom | Err, good question :) | |
| 00:35:12 | dansmith | it still requires a non-trivial environment to test for real, as does multiple cells | |
| 00:35:12 | artom | I guess you only need 1 (or 2, for migrations) NUMA machines | |
| 00:35:23 | artom | For real multi-cell you'd need... how much, actually? | |
| 00:35:42 | dansmith | you can do it all in one box, but it's not trivial to set up | |
| 00:35:43 | dansmith | either way, | |
| 00:36:24 | dansmith | you're drawing parallels that don't matter... it's a complicated thing that is hard to test for real, so extra work in making more-than-unit tests are worthwhile.. It all depends on some unfortunately turbo-global state, which make those hard | |
| 00:36:33 | dansmith | none of that points to "meh, it's hard, so just punt on tests" to me | |
| 00:37:42 | artom | That wasn't really the thinking | |
| 00:38:16 | artom | If func tests are super hard, I'd rather invest time and effort into setting up a real CI | |
| 00:38:22 | dansmith | I was going on this: [16:27:04] <artom>Reason I'm asking is - without this, I don't see a way to func test NUMA LM meaningfully | |
| 00:38:29 | dansmith | and | |
| 00:38:30 | dansmith | [16:30:21] <artom>dansmith, so, we can follow up on ML, but I think that rules out NUMA LM func testing? | |
| 00:40:20 | artom | dansmith, more in the sense of "I won't bother attempting it" | |
| 00:40:34 | artom | I spoke to the openlab guys a bit this morning | |
| 00:40:45 | artom | My request seemed to make sense for them | |
| 00:40:51 | artom | So I'd rather push on that | |