| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 21:55:05 | mriedem | i think i've gone up to 20 fake computes with an 8vcpu/8gb ram host and it was ok, but more than that and it starts to fall over, | |
| 21:55:19 | mriedem | because it's using ncpu/2 API workers for conductor/scheduler/api services on the single host | |
| 21:55:39 | mriedem | you can set API_WORKERS=1 to trim that down | |
| 21:55:54 | mriedem | so bunch of computes, 1 process per controller service | |
| 21:56:34 | mriedem | i also create servers with networks=none so i don't hit port quota in neutron | |
| 21:57:46 | marst | mriedem: Will give it a try tonight. Thanks a lot once again! :) | |
| 21:57:51 | mriedem | np | |
| 22:00:19 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: Remove TypeError handling for get_info https://review.openstack.org/640043 | |
| 22:00:19 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: ironic: check fresh data when sync_power_state doesn't line up https://review.openstack.org/636699 | |
| 22:00:31 | jroll | efried: you owe me back a +2 :P | |
| 22:32:39 | mriedem | marst: you inspired me https://review.openstack.org/640205 | |
| 22:32:52 | mriedem | feedback appreciated on if any of that doesn't work for you | |
| 22:38:50 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640207 | |
| 22:45:57 | marst | mriedem: thank you! I'll try it, but pretty sure it'll work as expected. | |
| 22:46:12 | mriedem | easy +w https://review.openstack.org/#/c/635350/5 | |
| 22:53:51 | tonyb | cfriesen: because they have different consumers and a requirements file is different from a constraints file | |
| 22:54:21 | tonyb | cfriesen: I get it's a little duplication but is it really that bad? How would you chnage it? | |
| 22:59:28 | efried | jroll: done, thanks for the squash. | |
| 22:59:37 | jroll | efried: np, thanks for the reviews | |
| 23:02:24 | efried | mriedem: I'm gonna leave stephenfin to that +W. I would nitpick it to death. | |
| 23:02:46 | mriedem | yar matey | |
| 23:06:43 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Drop legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640219 | |
| 23:07:55 | melwitt | mriedem: want to make sure this is kosher for backporting (ironic driver virt api change) https://review.openstack.org/636699 | |
| 23:08:31 | mriedem | well i can certainly look | |
| 23:09:03 | cfriesen | tonyb: I just was surprised because I was upversioning os-traits and didn't realize it needed to be changed in two places. | |
| 23:10:06 | cfriesen | tonyb: seems silly to specify "I need at least version 0.11.0 of os-traits" in two different ways. | |
| 23:10:16 | melwitt | mriedem: I just looked at it. TypeError handled but no warning log for out-of-tree people. I made a comment | |
| 23:10:45 | melwitt | maybe that's overkill for helping out-of-tree. it's mentioned in the reno already | |
| 23:10:54 | cfriesen | tonyb: I can live with it of course. :) | |
| 23:12:49 | mriedem | melwitt: same, plus it's broken | |
| 23:13:10 | mriedem | melwitt: you'd handle the type error and then get another error for an undefined variable | |
| 23:13:19 | melwitt | ohh | |
| 23:13:23 | melwitt | ouch | |
| 23:13:35 | openstackgerrit | Adam Spiers proposed openstack/nova master: Convert driver supported capabilities to compute node provider traits https://review.openstack.org/538498 | |
| 23:13:37 | mriedem | well maybe not | |
| 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 | |