Earlier  
Posted Nick Remark
#openstack-nova - 2023-06-20
12:54:59 noonedeadpunk yeah, but it's reseted to the same value
12:55:12 noonedeadpunk So you kinda don't need to update conf
12:55:32 noonedeadpunk And thus - don't restart service
12:55:42 sean-k-mooney regardless of if its updateed to the same or diffent value i woudl expect keystone to acppet existing non expired tokens
12:55:54 noonedeadpunk And it wasn't an issue in X and even in Y I believe
12:56:00 sean-k-mooney so that why i said it sounded like a keystone issue
12:56:35 sean-k-mooney it sounds like they have made updating the password invalidation all current tokens
12:56:46 sean-k-mooney which would be a major api brake
12:57:15 sean-k-mooney as in it should requrie a major api bump as that woudl completely change the meaning of the token experation
12:58:15 noonedeadpunk I'm not sure that's exactly the case, was more guessing what hapens
12:58:34 noonedeadpunk As I can hardly imagine any other reason for such behaviour
12:59:05 noonedeadpunk The interesting part also, that according to the report, only neutron connection breaks
12:59:28 sean-k-mooney well if the user and password is the same when we create the admin client it shoudl get a new token
12:59:42 sean-k-mooney this is presumable port binding?
13:00:01 noonedeadpunk Yeah, I believe so.
13:00:03 sean-k-mooney we generally dont use nova for anything else we use the end useers token
13:00:22 sean-k-mooney ya so portbidning is admin only so we use the admin clinet withthe user/password form teh config
13:00:42 noonedeadpunk And it fails with `nova.exception.NeutronAdminCredentialConfigurationInvalid`
13:01:10 noonedeadpunk (which is weird exception kinda)
13:02:35 noonedeadpunk One thing ofc, is that we will just stop resetting password to the same value. This was added quite some time ago to ensure that password is correct
13:08:03 noonedeadpunk but even though I'd say it shouldn't fail that way. So maybe just having some retry or try/except would be good to get new token when needed
13:08:35 anskiy I'm the reporter of the https://bugs.launchpad.net/openstack-ansible/+bug/2023370. I see this behaviour in Y too, except that in Z it does recover, whilst in Y one needs to restart Nova API service. I haven't tested this in X, but I can do it if that would help.
13:08:58 noonedeadpunk anskiy: I think latest Y should be quite the same?
13:09:12 noonedeadpunk As OSSA-2023-003 was backported to Y
13:09:16 anskiy noonedeadpunk: oh, yes, true.
13:09:35 noonedeadpunk no idea though
13:27:09 bauzas noonedeadpunk: sean-k-mooney: I don't know how Neutron ensures Keystone authd, but at least for Nova, all our meat is provided by keystonemiddleware
13:27:19 bauzas I assume the same for Neutron
13:27:38 bauzas so yeah, sounds a Keystone issue, probably in middleware
13:28:09 bauzas I don't see why we would need to recycle the nova-api services, but if middleware does some sort of caching, this may explain
13:29:25 noonedeadpunk yeah, ok, will try to bother keystone folks then
13:30:00 bauzas noonedeadpunk: https://docs.openstack.org/keystonemiddleware/latest/middlewarearchitecture.html
13:30:31 bauzas particularly https://docs.openstack.org/keystonemiddleware/latest/middlewarearchitecture.html#improving-response-time
13:31:14 noonedeadpunk yeah, I'm pretty sure memcached is being configured
13:32:12 bauzas https://blog.benhall.me.uk/wp-content/uploads/2015/01/cache-invalidation.png
13:32:34 bauzas pretty well known stance, I assume
13:32:50 noonedeadpunk the werid thing though, is that on subsequent request it jsut passes
13:33:06 noonedeadpunk which made me thinking if it's jsut some simple retry that can be added somewhere
13:34:17 bauzas well, sounds a design problem to me, which is never simple to solve :)
13:34:48 bauzas like, memcached has to be flushed against a user if that user password changed
13:36:44 bauzas unrelated, was the f... is going on with nova-live-migration jobs ? I got two CI failures on the same patch with the same error https://review.opendev.org/c/openstack/nova/+/886232
13:40:06 stephenfin bauzas: melwitt commented about that last week
13:40:19 stephenfin <melwitt> we likely need to look into this to improve gate fail rate
13:40:19 stephenfin fyi just got two CI failures on the same patch in the nova-live-migration and nova-grenade-multinode jobs https://bugs.launchpad.net/neutron/+bug/1940425 and it reminded me I have been seeing this failure often lately
13:40:21 bauzas stephenfin: ack and the story is ?
13:40:30 bauzas ok
13:41:40 bauzas https://zuul.openstack.org/builds?job_name=nova-live-migration&skip=0 sounds pretty bad if you want MHO
13:42:24 bauzas ralonsoh: lajoskatona: you'll be happy to hear we have some kind of neutron hard failure on nova-live-migration jobs
13:42:43 ralonsoh bauzas, please!
13:43:00 bauzas what a nice day, isn't it ? :)
13:43:08 lajoskatona bauzas: this one perhaps: https://bugs.launchpad.net/neutron/+bug/2024160 ?
13:43:10 ralonsoh do you know what is happening?
13:43:27 bauzas ralonsoh: one of the failing logs https://ffd910c1fba2c4e789e5-da0bf4b2b0817e3979adc64c27f459a5.ssl.cf5.rackcdn.com/880719/5/check/nova-live-migration/08a7455/testr_results.html
13:43:31 ralonsoh so this is related only with the trunk ports, right?
13:43:46 bauzas yeah
13:43:47 ralonsoh ok, we have the triage meeting in 20 mins
13:43:53 bauzas tempest.api.compute.admin.test_live_migration.LiveMigrationTest is failing
13:43:56 bauzas due to a failed assert
13:43:58 ralonsoh I'll raise it as urgent
13:44:10 ralonsoh can you disable this test temporarily?
13:44:13 ralonsoh hold on
13:44:16 bauzas lajoskatona: sounds related
13:44:25 ralonsoh is this CI in a gate/check queue?
13:44:39 ralonsoh I mean, is this blocking you from merging patches?
13:45:19 lajoskatona ralonsoh, bauzas: yeah by the logs seems bug/2024160 , and to the OVN version bump
13:46:30 ralonsoh bauzas, is this in a gate/check queue? is this blocking you from merging patches?
13:46:44 ralonsoh if so, I'll disable this test temporarily
13:48:10 bauzas ralonsoh: (sorry, was elsewhere) yeah this is a voting job
13:48:22 bauzas on both check and gate
13:48:30 bauzas Tempest seems impacted too
13:48:58 ralonsoh ok, I'll disable make this test unstable temporarily
13:49:08 ralonsoh but we'll start working on this right now
13:50:07 bauzas I can add a skip test in zuul
13:50:23 bauzas ideally, we should have a tempest bug report against it
13:50:32 bauzas want me to declare it ?
13:51:43 ralonsoh bauzas, isn't enough with the Neutron LP bug?
13:51:54 ralonsoh I'm sending a patch right now for tempest
13:52:15 bauzas ralonsoh: sorry I misread your last comment, I thought you said the opposite
13:52:30 ralonsoh broken phone, I think
13:52:37 ralonsoh sorry if I wasn't clear
13:56:30 ralonsoh --> https://review.opendev.org/c/openstack/tempest/+/886496
13:56:39 bauzas ralonsoh++
13:59:34 lajoskatona +1
15:02:44 bauzas reminder : nova meeting in 1 hour-ish here
16:01:32 bauzas sorry
16:01:36 opendevmeet The meeting name has been set to 'nova'
16:01:36 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:36 opendevmeet Meeting started Tue Jun 20 16:01:36 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:36 bauzas #startmeeting nova
16:01:49 bauzas #topic Bugs (stuck/critical)
16:01:56 bauzas #info No Critical bug
16:02:12 bauzas whoops, forgot to tell howdy :)
16:02:18 bauzas #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:03:11 bauzas #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 27 new untriaged bugs (+9 since the last meeting)
16:03:21 bauzas but last week was hectic :)
16:03:31 bauzas so, let's try to look again this week
16:05:00 bauzas #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster
16:05:11 bauzas I'll try to look at them this week
16:05:13 bauzas so,
16:05:18 bauzas #info bug baton is being passed to bauzas

Earlier   Later