| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-23 | |||
| 10:32:51 | sean-k-mooney | you shoudl be using the cinder fixture yes | |
| 10:33:27 | sean-k-mooney | your not actully usin gthe cidner fixture in this test | |
| 10:33:31 | sean-k-mooney | https://paste.opendev.org/show/bY6ZjvBzDO4QXbzrpQ70/ | |
| 10:33:36 | sean-k-mooney | yoru using a uuid from it | |
| 10:33:53 | sean-k-mooney | but you have not actully used the cinder fixture to provide a fake sinder | |
| 10:33:58 | sean-k-mooney | *cinder | |
| 10:34:06 | auniyal_ | in WAY 2, line 52 | |
| 10:34:07 | sean-k-mooney | right now your test is trying to actully call keystone | |
| 10:34:15 | sean-k-mooney | thats not using the fixture | |
| 10:34:22 | sean-k-mooney | on line 52 | |
| 10:34:32 | sean-k-mooney | its just geting a constnat that is defiend in it | |
| 10:35:33 | auniyal_ | okay, but shouldn't it be treated as volume while instance creation, (fake volume) | |
| 10:36:30 | auniyal_ | or I should add some other property as well | |
| 10:36:56 | sean-k-mooney | add self.useFixture(nova_fixtures.CinderFixture(self)) to the setUp | |
| 10:37:12 | sean-k-mooney | on line 20 | |
| 10:37:36 | sean-k-mooney | and from nova.tests import fixtures as nova_fixtures | |
| 10:38:01 | sean-k-mooney | ah you have that on line 4 | |
| 10:38:32 | sean-k-mooney | to enable a fixture you actullly need to do self.useFixture | |
| 10:39:28 | sean-k-mooney | also why did you comment out base.ServersTestBase, and integrated_helpers.InstanceHelperMixin | |
| 10:40:09 | auniyal_ | actually, CinderFixture is already added in inherited class | |
| 10:40:13 | auniyal_ | in here - https://opendev.org/openstack/nova/src/commit/aad31e6ba489f720f5bdc765c132fd0f059a0329/nova/tests/functional/integrated_helpers.py#L1208 | |
| 10:41:14 | sean-k-mooney | right but your not ment to be inheriting form that | |
| 10:42:02 | auniyal_ | okay, so I should inherit base.ServersTestBase, and integrated_helpers.InstanceHelperMixin | |
| 10:42:08 | auniyal_ | and add CinderFixtute | |
| 10:42:52 | sean-k-mooney | yes as i said a few time in the past integrated_helpers._IntegratedTestBase does not use the fake libvirt implemeattion | |
| 10:43:03 | sean-k-mooney | the bug your working on only happens in the libvirt driver | |
| 10:43:08 | sean-k-mooney | so you cant use that | |
| 10:43:28 | sean-k-mooney | which is why i perviouly told you to use base.ServersTestBase, and integrated_helpers.InstanceHelperMixin | |
| 10:45:08 | auniyal_ | actually, I tried that as well, so thats why, only commented and not removed from test | |
| 10:46:17 | auniyal_ | it failes with - https://paste.opendev.org/show/bL7nGtDSyTzc11Utb0AA/ | |
| 11:02:12 | sean-k-mooney | yes that is a diffent issue | |
| 11:02:33 | sean-k-mooney | we need to mock out the calls to check for secure boot | |
| 11:03:09 | sean-k-mooney | that is at least using the libvirt driver which is good | |
| 11:08:10 | auniyal_ | secure boot, by adding 'os_secure_boot': 'required', in image properties | |
| 11:08:34 | sean-k-mooney | no | |
| 11:08:55 | sean-k-mooney | if you read the traceback you will see it failing in the driver code | |
| 11:09:24 | sean-k-mooney | specificaly its trying to parse supprot for secure boot | |
| 11:09:44 | sean-k-mooney | the fake libvirt fixture is likely not faking that properly | |
| 11:10:09 | sean-k-mooney | so either you need to moack out the supports_secure_boot function or update the data the fixture is provideing | |
| 11:11:38 | sean-k-mooney | the libvirt fixture shoudl be mockign this out | |
| 11:11:40 | sean-k-mooney | https://github.com/openstack/nova/blob/f8c91eb75fc5504a37fc3b4be1d65d33dbc9b511/nova/tests/fixtures/libvirt.py#L1993-L2045 | |
| 11:12:29 | sean-k-mooney | which makes me thing that the libvirt fixture is not currently in use | |
| 22:59:17 | clarkb | Does anyone here know why the Nodepool CI job that tests against openstack using devstack is suddenly tripping over the check at https://opendev.org/openstack/nova/src/branch/master/nova/network/neutron.py#L603-L613 when this code doesn't appear to have changed recently? | |
| 22:59:26 | clarkb | https://zuul.opendev.org/t/zuul/build/74fab5fdddee4c3d88e71e40ad6795a7/log/docker/nodepool_nodepool-launcher_1.txt#1345 is the nodepool side of things reporting the error | |
| 22:59:51 | clarkb | Since the code hasn't chagned as far as I can tell I'm thinking the policy may have? But I'm not seeing where the policy might be set | |
| 23:04:31 | clarkb | hrm 909b0b02470dc795fd3d2775ee33864b055dd678 changed the default check_str from project admin to admin | |
| 23:05:07 | clarkb | But I think we've been able to do this successfully more recently than when that change landed | |
| 23:10:06 | clarkb | Sorry here is where we log that error message https://zuul.opendev.org/t/zuul/build/74fab5fdddee4c3d88e71e40ad6795a7/log/syslog#40077 which then maps back to that nodepool error (which is far more terse as that is what the sdk gives us) | |
| 23:22:14 | clarkb | It seem that both the recent failures and the most recent successful devstack installs for these jobs installed the same version of nova: aad31e6ba4 Merge "Update nova-manage doc page" | |
| 23:31:06 | clarkb | gmann: you've been pushing the rbac stuff along do you know if anything changed for that in the last day ? | |
| 23:34:39 | gmann | clarkb: policy is changed to admin from project admin means any admin can access it, so it is made more broader access than restrictive. also we have the old policy supported so it should work as it is | |
| 23:35:16 | gmann | may be we need to check if any change in token accessing it? | |
| 23:36:08 | clarkb | gmann: I don't think anything changed in how we access it unless openstacksdk just made a release /me checks | |
| 23:36:24 | clarkb | no the sdk updated a month ago | |
| 23:36:59 | gmann | clarkb: here, non admin is trying to access it https://zuul.opendev.org/t/zuul/build/74fab5fdddee4c3d88e71e40ad6795a7/log/syslog#40066 | |
| 23:37:19 | gmann | 'is_admin': False, | |
| 23:37:36 | clarkb | gmann: yes, but that was working yesterday | |
| 23:38:05 | clarkb | is it possible to be a project admin but not an admin? | |
| 23:39:35 | gmann | no, project admin is nothing but admin with project_id matching | |
| 23:40:18 | gmann | admin is just role 'admin' match so any project _id so every project admin is admin | |
| 23:41:06 | gmann | I think 'is_admin':False is changed somewhere in sdk or so | |
| 23:41:07 | clarkb | got it | |
| 23:41:23 | gmann | it should be true | |
| 23:41:25 | clarkb | I'm now trying to compare the successful run to the failed one more broadly | |
| 23:41:35 | clarkb | to see if there are differences | |
| 23:47:55 | clarkb | Both the successful and failed jobs have this problem in the nova logs. But the failed one also has nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed and eventlet timeouts | |
| 23:49:07 | clarkb | is it posible that rbac error is just noise? And the real issue is that nova does go ahead and try to create virtual interfaces anyway but fails? | |
| 23:52:51 | clarkb | gmann: ok, I think https://zuul.opendev.org/t/zuul/build/74fab5fdddee4c3d88e71e40ad6795a7/log/syslog?severity=0#84665-84692 might be the actual fatal bit (I don't understand why we get the rbac errors but I'm thinking they may juts be noise now) | |
| 23:56:13 | gmann | humm, not sure why rbac error that is confusing then | |
| 23:57:21 | clarkb | gmann: I guess it is also possible that openstacksdk is probing the nova api to determine what actions it can take? | |
| 23:57:32 | clarkb | but I agree it is confusing | |
| 23:58:03 | gmann | yeah, may be | |
| #openstack-nova - 2022-09-24 | |||
| 00:02:40 | clarkb | gmann: most of openstack devstack testing is still on focal right now? | |
| 00:02:51 | clarkb | (I notice we're running on jammy so that may be one difference) | |
| 00:08:40 | gmann | clarkb: yes, its on Focal currently and planned to migrate to jammy in next cycle | |
| 00:12:28 | clarkb | ok thanks. I've got a modified job setup in ci now to grab libvirt logs to see if we can diagnoes this better with libvirt info | |
| #openstack-nova - 2022-09-25 | |||
| 08:44:38 | opendevreview | Merged openstack/nova stable/xena: neutron: Unbind remaining ports after PortNotFound https://review.opendev.org/c/openstack/nova/+/842586 | |
| 09:31:05 | opendevreview | Merged openstack/nova stable/yoga: nova-live-migration tests not needed for Ironic https://review.opendev.org/c/openstack/nova/+/854257 | |
| 19:00:15 | opendevreview | J.P.Klippel proposed openstack/nova master: fix typo in architecture document https://review.opendev.org/c/openstack/nova/+/859201 | |
| #openstack-nova - 2022-09-26 | |||
| 04:03:02 | opendevreview | junbo proposed openstack/nova master: Limit bandwidth during postcopy migration. https://review.opendev.org/c/openstack/nova/+/859207 | |
| 12:41:48 | opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | |
| 12:57:07 | opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | |
| 13:00:07 | justas_napa | We have submitted a spec to add support for Napatech SmartNICs in Nova. If you have any questions - please ping me here or via dm. | |
| 13:12:57 | opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | |
| 16:09:44 | gibi | auniyal: responded to sean-k-mooney's comment in https://review.opendev.org/c/openstack/nova/+/791135 . Let me know if the direction is unclear to you | |
| 16:52:25 | opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859312 | |
| 16:52:26 | opendevreview | Balazs Gibizer proposed openstack/nova stable/yoga: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859313 | |
| 16:53:31 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859314 | |
| 16:53:32 | opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859315 | |
| 16:54:21 | opendevreview | Balazs Gibizer proposed openstack/nova stable/wallaby: Reproduce bug 1981813 in func env https://review.opendev.org/c/openstack/nova/+/859320 | |
| 16:54:22 | opendevreview | Balazs Gibizer proposed openstack/nova stable/wallaby: Gracefully ERROR in _init_instance if vnic_type changed https://review.opendev.org/c/openstack/nova/+/859321 | |
| #openstack-nova - 2022-09-27 | |||
| 00:35:02 | opendevreview | melanie witt proposed openstack/nova master: Unit test exceptions raised duing live migration monitoring https://review.opendev.org/c/openstack/nova/+/859358 | |
| 09:09:49 | Uggla | gibi, bauzas, hello. I have a question about share_mapping deletion behavior. Assuming we cannot umount the share due to error. So we could be stuck in the state share cannot be deleted because it cannot be unmounted. What do you prefer a "force" option in the API or deleting it despite the error and warn the user that the umount was not properly done ? | |
| 09:10:17 | bauzas | damn | |
| 09:11:01 | bauzas | I'd prefer to return an error and still having the share status to be ACTIVE | |
| 09:11:50 | gibi | Uggla: yeah what bauzas said. The DB record is cheap to keep so I would not optimize on removing that. | |
| 09:12:53 | bauzas | Uggla: tbc, if we can't umount the share, then the user would need to ask again | |
| 09:14:43 | Uggla | ok in that case it means the op need to fix the umount issue to remove the share. Do we agree on that ? | |
| 09:15:11 | bauzas | honestly, I think so | |
| 09:15:32 | bauzas | the user can't know why nova doesn't work | |