| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-08 | |||
| 20:19:21 | dansmith | getting the two to work is also making me hate life, so maybe a note in the test would be better | |
| 20:20:33 | gmann | so any extra things to show in sevrer reponse has to be moved to project=scoped only as parent policy is project-scoped only | |
| 20:20:35 | dansmith | these tests are hard to debug sometimes, figuring out which context can do a thing that shouldn't be allowed | |
| 20:22:45 | gmann | dansmith: I tried too be more optimize there may be. instead those can be simple/readable with more separate tests for allowed and not-allowed | |
| 20:24:01 | dansmith | gmann: they're very obsessive which is good, they're just hard to debug, but more infra around them can make it easier | |
| 20:25:30 | gmann | sure | |
| 20:34:51 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 20:46:25 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 20:53:47 | dansmith | gmann: why does this not include other_project_* and legacy_admin ? https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/tests/unit/policies/test_flavor_extra_specs.py#L399 | |
| 20:54:18 | dansmith | gmann: is it because we're not passing a context to the index check so we're not *actually* preventing those users from doing the flavor extra specs index on servers, because the server rule should have stopped them? | |
| 20:56:38 | dansmith | gmann: by the way, this is what I'm trying to get the tests to (only showing the context setup): https://pastebin.com/UKcd62Th | |
| 20:56:51 | dansmith | which I think is a lot easier to read, especially with the comments | |
| 23:10:31 | gmann | dansmith: RE: other_project_* and legacy_admin - yes as server rule will take care of accessing server | |
| 23:11:18 | dansmith | gmann: ack | |
| 23:11:43 | gmann | and in flavor, as there is no project_id there so anyone can access | |
| 23:12:44 | dansmith | gmann: well, right but in the server tests, I think the casual reader (and definitely the policy-editing operator) would expect that to be the server's project_id | |
| 23:13:23 | dansmith | meaning, when accessing the flavor on a server | |
| 23:14:13 | dansmith | i.e. here https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/tests/unit/policies/test_flavor_extra_specs.py#L327 | |
| 23:14:41 | dansmith | so I will put a note in there, but that's probably another reason to have the rules eventually be separate and to pass a target with the proper project_id in it | |
| 23:16:46 | gmann | dansmith: yeah, we can put project_id in current rule too for safer side (if server can be seen by anyone but extra specs not) here - https://github.com/openstack/nova/blob/171138146a648d22474b7021ac730e26f03455f8/nova/api/openstack/compute/views/servers.py#L236 | |
| 23:17:13 | dansmith | yeah | |
| 23:17:22 | dansmith | anyway, note added | |
| 23:17:38 | dansmith | I will try to finish this up tomorrow and get another version posted with more of it cleaned up | |
| 23:18:31 | gmann | dansmith: and on this: https://pastebin.com/UKcd62Th | |
| 23:19:28 | gmann | in ScoptType: self.admin_authorized_contexts need to include project_admin also right? | |
| 23:20:24 | dansmith | gmann: no? system-only for creating flavors right? | |
| 23:20:35 | gmann | or you can name self.system_admin_authorized_contexts and self.project_admin_authorized_contexts | |
| 23:20:53 | dansmith | well, flavor extra_specs anyway | |
| 23:20:54 | gmann | dansmith: ohk, so only for flavor or generically ? | |
| 23:21:40 | dansmith | I guess in the new way, project admin should be able to do that for project-private flavors, since admin==operator | |
| 23:21:48 | dansmith | I didn't change the policy on create/update (yet) so that's why it's sytem-only there | |
| 23:22:22 | gmann | ohk | |
| 23:22:36 | dansmith | I left it that way because I haven't done flavor yet, only flavor extra_specs because the servers change broke those tests, | |
| 23:22:41 | dansmith | so I'm a little out of order, | |
| 23:22:44 | gmann | got it | |
| 23:22:45 | dansmith | so I just didn't tweak that yet | |
| 23:23:35 | gmann | i can take those. this way it will be more clear on who access what. | |
| 23:24:00 | gmann | and I am almost done with listing all rule in wiki table, might be ready by tonight or tomorrow | |
| 23:24:29 | dansmith | okay, I will try to get this cleaned up and updated in gerrit tomorrow so maybe we can use it as a pattern going forward | |
| 23:24:41 | gmann | +1, thanks | |
| 23:41:35 | clarkb | nova should consider removing nova-live-migration-ceph from the gate queue as the job is non voting | |
| 23:54:05 | opendevreview | Merged openstack/nova master: Add autopep8 to tox and pre-commit https://review.opendev.org/c/openstack/nova/+/806182 | |
| #openstack-nova - 2021-11-09 | |||
| 04:36:53 | opendevreview | Merged openstack/nova master: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/813263 | |
| 08:02:51 | gibi | lyarwood: I saw elodilles explained the setuptools pin question. thanks elodilles | |
| 08:10:09 | bauzas | hola folks | |
| 08:10:42 | bauzas | gibi: I'm asked to present some PTG updates in a company session today at the same time of the upstream meeting | |
| 08:10:58 | gibi | bauzas: o/ | |
| 08:10:59 | bauzas | gibi: it would be a 2 min presentation about Nova | |
| 08:11:18 | bauzas | gibi: could you help me by chairing the meeting when I'm asked to discuss ? | |
| 08:11:27 | gibi | bauzas: sure | |
| 08:11:37 | bauzas | I could run the meeting, then passing it to you for 5 mins | |
| 08:11:49 | bauzas | and then, either you continue or me :) | |
| 08:12:57 | gibi | ok | |
| 08:13:11 | gibi | I will handle it when you need to switch | |
| 08:18:01 | bauzas | gibi: thanks | |
| 08:18:10 | bauzas | appreciated | |
| 08:22:25 | gibi | no worries | |
| 08:54:13 | gibi | lyarwood, elodilles: I'm seeing multiple guest kernel panics in stable/victoria volume related tests | |
| 08:55:53 | gibi | 1) https://zuul.opendev.org/t/openstack/build/67c89daf17e3475cb1d632f87beeb60d/log/controller/logs/tempest_log.txt#5950 | |
| 08:56:28 | lyarwood | Just jumping on a call but I wonder if we were still using cirros 0.4.0 back then? | |
| 08:57:13 | lyarwood | /opt/stack/devstack/files/cirros-0.5.1-x86_64-disk.img | |
| 08:57:15 | lyarwood | maybe not | |
| 08:57:32 | gibi | 2) https://1a59031cf12ee85b5b8a-5c947c8d22eb7769ff9d2de46bec4cc9.ssl.cf5.rackcdn.com/810915/2/gate/nova-grenade-multinode/ebc944c/testr_results.html | |
| 08:57:32 | lyarwood | however I also see image.http_image = http://download.cirros-cloud.net/0.3.1/cirros-0.3.1-x86_64-uec.tar.gz | |
| 08:58:13 | lyarwood | anyway I'll take a look after this call | |
| 08:58:36 | gibi | ack, I see both 0.3.1 and 0.5.1 in the logs | |
| 09:00:31 | gibi | hm the issue in the grenade job uses a different cirros as it has kernel 4.4.0 while the failed test case in the live migration job has kernel 5.3.0 | |
| 09:01:52 | gibi | both kernel stack trace shows page fault but in different processes | |
| 09:11:33 | kashyap | gibi: Got a link to the traceback? | |
| 09:11:44 | gibi | kashyap: https://zuul.opendev.org/t/openstack/build/67c89daf17e3475cb1d632f87beeb60d/log/controller/logs/tempest_log.txt#5950 | |
| 09:11:48 | gibi | that is one | |
| 09:12:04 | kashyap | Yep, finally it loaded; thanks | |
| 09:12:24 | kashyap | So, the above trace is with kernel 4.4.0? (i.e. CirrOS 0.5.1?) | |
| 09:13:08 | gibi | this one is kernel 5.3 | |
| 09:13:24 | gibi | [ 15.489062] CPU: 0 PID: 284 Comm: ip Not tainted 5.3.0-26-generic #28~18.04.1-Ubuntu | |
| 09:14:07 | kashyap | Yes, just saw it. Silly me | |
| 09:14:08 | gibi | sorry wrong buffer | |
| 09:14:08 | gibi | ... | |
| 09:14:23 | gibi | [ 15.302770] CPU: 0 PID: 9 Comm: ksoftirqd/0 Not tainted 5.3.0-26-generic #28~18.04.1-Ubuntu | |
| 09:14:31 | gibi | this one is from the stack trace you are looking at | |
| 09:16:53 | gibi | and that is matching with cirros 0.5.1 | |
| 09:17:02 | kashyap | Yeah, figured as much. The trace seems to go into kernel RCU (read-copy update) code in the kernel ... which I was told can be used to "frighten small children and adults alike" | |
| 09:17:23 | kashyap | s/in the kernel// | |
| 09:17:47 | gibi | :) | |
| 09:18:15 | kashyap | Hm, I wonder what changed suddenly in stable/victoria for us to hit these | |
| 09:18:45 | gibi | I can try to check how frequently we hit kernel panics in stable/victoria and when we get the increawse | |
| 09:26:17 | gibi | we don't have much logs going backward in time for nova-live-migration as it was turned off for a while on stable | |
| 09:27:21 | gibi | https://zuul.opendev.org/t/openstack/builds?job_name=nova-live-migration&branch=stable%2Fvictoria | |
| 09:27:57 | gibi | based on this it started failing yesterday | |
| 09:28:06 | gibi | but it is small sample | |
| 09:32:14 | gibi | it seems other branches (wallaby, xena, master) are not affected but only master has good amount of runs to be sure | |
| 09:33:41 | gibi | but master uses cirros 0.5.2 | |
| 09:35:38 | gibi | ohh both wallaby and xena also uses 0.5.2 | |
| 09:35:44 | gibi | maybe it is the cirros version | |
| 09:36:06 | gibi | I'm wondering where we define the cirros version | |
| 09:37:12 | gibi | ok, that is devstack | |
| 09:37:20 | gibi | the 0.5.2. bump was this patch https://review.opendev.org/c/openstack/devstack/+/779179 | |
| 09:37:21 | kashyap | Hmm | |
| 09:37:38 | kashyap | Okay, so failing since yesterday; and only affects stable/victoria | |
| 09:39:07 | kashyap | (The bump was only this year - it shouldn't affect stable/victoria?) | |