| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-01-29 | |||
| 16:07:21 | dansmith | but it's not a sticking point | |
| 16:07:21 | sean-k-mooney | *that | |
| 16:07:25 | dansmith | sean-k-mooney: correct | |
| 16:07:43 | stephenfin | they could already ddos things but just repeatedly hitting the API with working extra specs | |
| 16:07:50 | stephenfin | we log each request iirc | |
| 16:07:56 | stephenfin | *by just | |
| 16:08:05 | stephenfin | that's what API rate limiting is for | |
| 16:08:27 | sean-k-mooney | well i suspect the error could be long if you add a bunch of invalide extra specs so its a larger risk | |
| 16:08:42 | sean-k-mooney | but again its an admin only api by default | |
| 16:08:46 | dansmith | and logging something that is a warning as info doesn't make it info | |
| 16:08:58 | sean-k-mooney | so the request will get rejected by a normal user well before it hit your code | |
| 16:09:00 | dansmith | but anyway, like I say, not a sticking point | |
| 16:09:37 | stephenfin | Is it a warning though? Per above, info does seem appropriate if the user has explicitly requested no/limited validation | |
| 16:09:58 | stephenfin | It's a warning if they didn't, which they'll see in their HTTP 4xx response | |
| 16:10:07 | dansmith | seems like a warning to me :) | |
| 16:10:08 | dansmith | anyway | |
| 16:10:16 | dansmith | we needn't argue about it | |
| 16:10:27 | dansmith | I will just toldjaso if you get CVE paperwork over it :) | |
| 16:10:29 | stephenfin | fine by me :) | |
| 16:16:01 | bauzas | mmm, what the heck is this ? | |
| 16:16:04 | bauzas | stestr: error: unrecognized arguments: --test-path=./nova/tests/functional run test_nova_manage | |
| 16:16:09 | bauzas | holy shit | |
| 16:16:53 | bauzas | I probably need to upgrade stestr by hand | |
| 16:16:59 | bauzas | but I did recreated my venc | |
| 16:17:02 | bauzas | venv* | |
| 16:17:09 | stephenfin | tox -e function --recreate ? | |
| 16:17:17 | stephenfin | *al | |
| 16:18:32 | stephenfin | unless you're using stestr without tox, which is odd | |
| 16:18:57 | stephenfin | seeing as you can do stuff like 'tox -e functional -- -n path_to_functional_test.py::TestClass.test_method' | |
| 16:22:34 | bauzas | stephenfin: that's what I did | |
| 16:22:51 | bauzas | and I ended up with stestr==2.6.0 | |
| 16:23:24 | bauzas | I always asked to run a subset of tests by doing tox -efunc <my_regex> | |
| 16:23:27 | bauzas | and it worked | |
| 16:24:57 | stephenfin | bauzas: That's what I have too. Working fine here | |
| 16:25:17 | bauzas | checking with stestr==2.5.0 | |
| 16:25:38 | bauzas | functional runtests: commands[0] | stestr --test-path=./nova/tests/functional run test_nova_manage | |
| 16:25:42 | bauzas | mmmmm | |
| 16:26:21 | stephenfin | bauzas: '$ tox -e functional -- test_nova_manage' wfm | |
| 16:27:05 | bauzas | I never had to use the positional markers, but whatever, gonna try | |
| 16:27:41 | bauzas | crazy, still same issue | |
| 16:28:07 | stephenfin | want to dump the complete output to paste.o.o | |
| 16:28:19 | stephenfin | it's something simple, I'd suspect | |
| 16:30:06 | bauzas | yeah me too, but can't see the problem | |
| 16:30:22 | bauzas | it's just stestr which doesn't sound to accept --test-path | |
| 16:30:24 | bauzas | http://paste.openstack.org/show/788935/ | |
| 16:31:11 | bauzas | actually, nope | |
| 16:33:59 | bauzas | well, I'm puzzled | |
| 16:34:37 | stephenfin | ah, wait, have you added additional tests for nova-manage? | |
| 16:35:13 | stephenfin | There's a bug with oslo.config whereby the CLI parser is global'ish | |
| 16:35:49 | stephenfin | Yeah, '--remote_debug-port' is a nova-manage option. You're not mocking stuff properly | |
| 16:38:06 | stephenfin | bauzas: mriedem saw the issue pop up in a unit test at https://review.opendev.org/#/c/694806/2/ and it's currently causing an issue with glance and the latest version of cliff | |
| 16:40:19 | bauzas | stephenfin: interesting, if I use the functional-py36 target, it does work | |
| 16:40:49 | stephenfin | even if you rebuild the venv? | |
| 16:41:03 | bauzas | it was created, I never used the target yet | |
| 16:41:13 | stephenfin | gotcha | |
| 16:41:20 | stephenfin | weird | |
| 16:41:24 | stephenfin | then I'm not sure :( | |
| 16:41:25 | bauzas | to make it clear, the functional-py36 target works, but not the standard one | |
| 16:41:53 | bauzas | either way, I know what to do, but I have to look at the target differences in tox.ini | |
| 16:42:32 | efried | bauzas: would it be productive for me to read the current PS of the numa topo spec, or wait til you rev it? | |
| 16:43:06 | bauzas | efried: I'm wraping my head around the group_policy issue, but your thoughts could be helpful | |
| 16:43:59 | bauzas | efried: and we have a disagreement on the memory modeling with NUMA with sean-k-mooney, your opinion could help us finding a consensus | |
| 16:44:25 | bauzas | efried: to answer your question, yeah comments would be appreciated on the current rev | |
| 16:44:32 | efried | okay, I'll give it a read. My view on group_policy is that we should be ignoring it. It doesn't really have a place with granular groups and the other knobs we put in in recent microversions. | |
| 16:44:59 | efried | I at least proposed (though I don't remember if we actually pulled the trigger on this) making it no longer required in a recent microversion. | |
| 16:45:09 | sean-k-mooney | bauzas: sorry can we pick this up after the internal call | |
| 16:45:19 | sean-k-mooney | e.g. in 15 mins | |
| 16:45:29 | bauzas | sean-k-mooney: yeah, and I even wanted to discuss it during the internal call :D | |
| 16:45:42 | bauzas | (but I'm superseded by other topics :) ) | |
| 16:45:52 | sean-k-mooney | ya i saw | |
| 16:47:14 | efried | I won't be much help on the memory modeling, probably, as I really don't understand that level of detail of NUMA itself. But I'll give it a shot. | |
| 16:48:38 | bauzas | tbh, me too | |
| 16:49:13 | bauzas | the big question is should we iteratively model huge pages and have memory split now, or care about the whole now ? | |
| 16:51:02 | efried | I'll have to refresh my memory (heh) on whether we did things to support cross-provider accumulation of resources, e.g. so you could still land on a NUMA-modeled host with 128/128 if you asked for 256. | |
| 16:52:10 | efried | I seem to recall we tried to KISS by saying you land on a NUMA-modeled host by asking for NUMA-modeled resources, and the converse, but that may have only been a point in time in the discussion, not where we landed. | |
| 16:52:15 | efried | I'll have to swap this all back in. | |
| 16:53:05 | bauzas | efried: yeah that's what I recall too | |
| 17:03:35 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: Fix volume attachment rollback https://review.opendev.org/704847 | |
| 17:07:39 | efried | nts: we did abandon "can_split" https://review.opendev.org/#/c/658510/ | |
| 17:08:03 | sean-k-mooney | yes we did | |
| 17:09:29 | stephenfin | sean-k-mooney: for that memory issue, is there a reason we need to continue to support floating memory when NUMA is used? | |
| 17:09:49 | stephenfin | do we do strict NUMA affinity when using a NUMA topology at the moment? | |
| 17:09:52 | sean-k-mooney | that depends. yes but the question is do we care | |
| 17:10:06 | stephenfin | for memory, that is | |
| 17:10:13 | sean-k-mooney | we would have to pin the memoyy based on the placemetn allocation of all vms | |
| 17:10:18 | stephenfin | I think we don't unless we explicitly request a pagesize, yeah? | |
| 17:10:34 | sean-k-mooney | but for vms with out a numa toplogy we could pin that vm aross host numa nodes | |
| 17:11:00 | stephenfin | okay, so that leads to my question: do we need to support that model? | |
| 17:11:10 | stephenfin | VMs with a NUMA topology alongside those without? | |
| 17:11:13 | efried | Again, I think we decided it was acceptable to enforce a segregated data center | |
| 17:11:15 | sean-k-mooney | if we want to support vms without a numa toplogy yes | |
| 17:11:21 | efried | where some hosts are NUMA-aware and some are not. | |
| 17:11:26 | stephenfin | sean-k-mooney: we could have a knob | |
| 17:11:32 | stephenfin | use_numa_in_placement | |
| 17:11:38 | efried | And if you ask for a NUMA topo, you land on the former, always, exclusively. And the converse. | |
| 17:11:46 | stephenfin | efried: right, thing we're talking about the same thing | |
| 17:11:48 | stephenfin | *think | |
| 17:11:54 | sean-k-mooney | i would prefer to handel it via resouce classes | |
| 17:12:05 | sean-k-mooney | so if you report memory_mb its non numa aware memory | |
| 17:12:12 | efried | Except for the upgrade issue, I think it wouldn't matter. | |