Earlier  
Posted Nick Remark
#openstack-nova - 2023-07-18
12:46:26 gibi yeah I agree with sean-k-mooney on both patch
13:03:30 opendevreview Kashyap Chamarthy proposed openstack/nova master: Bump MIN_{LIBVIRT,QEMU} for "Bobcat" https://review.opendev.org/c/openstack/nova/+/887255
13:49:07 stephenfin sean-k-mooney: gibi: The issue is that we are currently SQLAlchemy 2.x compatible and don't want to regress. However, people don't look at non-voting jobs so they're effectively useless for anti-regression purposes IMO
13:50:06 stephenfin There is of course a risk that SQLAlchemy could introduce a breaking change but if we're serious about being ready for SQLA 2.x by C then we'll need to handle those issues. Also, SQLA is super mature so the chances of that seem minute, while we can simply toggle it to non-voting if they inadvertently introduce a bug
13:52:54 stephenfin Also also, I've proposed the same thing for ironic, cinder, placement, and a few others. Neutron are running all their functional tests with sqlalchemy master for some time now. I think the benefits outweigh the concerns
13:56:21 bauzas sean-k-mooney: I quite agree with stephenfin, let's KISS
13:56:28 bauzas we also have other jobs
13:58:52 bauzas but -1 b/c of the gate
13:59:56 dansmith could we not just make the 310 job SA 2.0 and leafve the 3.9 one as it is? having another job seems excessive to me
14:00:36 sean-k-mooney i would prefer to just raise our min version to 2.0
14:00:40 auniyal hi dansmith, sorry for not responding on your question on time before new revision, yes as you mentioned in comment, on melwitt suggestion, I passed the context from caller and did not created new context and I added the assert. as per suggestion. Actually I had the reply on draft but was waiting for CI job to pass that time.
14:00:54 sean-k-mooney but ya i can also live with dansmith suggestion i guess
14:01:01 gibi yeah, if we want to track 2.0 then lets bump now to 2.0
14:01:05 dansmith we're really running three functional jobs and it seems like we could just re-use one to move forward
14:01:34 sean-k-mooney could we bump the uc for py3.10 specificaly to 2.0
14:01:55 sean-k-mooney then we could follow the same pattern in all project
14:02:09 dansmith can we do that? if so that'd also work I suppose
14:02:12 sean-k-mooney or as i said just move nova to 2.0
14:02:23 dansmith I mean I know requirements.txt can do it, but will a bot complain?
14:02:33 sean-k-mooney dansmith: we can we used ot do it for py2.7 vs py 3
14:02:42 dansmith sean-k-mooney: we can't move nova to *require* 2.0 right now
14:02:55 dansmith because it would mean nova can't be installed on the same machine as keystone, for example
14:03:17 stephenfin we can't bump to 2.0 in requirements.txt - the requirements check job won't let us (co-installability)
14:03:27 stephenfin i.e. what dansmith said
14:03:46 sean-k-mooney i ment in the reqiuremetns repo
14:04:00 sean-k-mooney can we increases the cap to 2.0 for py3.10
14:04:07 dansmith yeah, can't do that until everyone can use 2.0 but we're not ready for that
14:04:09 sean-k-mooney i guess that could break devstack jobs
14:04:17 sean-k-mooney ack
14:04:19 stephenfin sean-k-mooney: manila still isn't compatible, nor is masakari and a few other projects
14:04:31 dansmith nor keystone, last I checked
14:04:47 sean-k-mooney ok so i guess looping back to dansmith suggestion of just doing this in one of the existing job
14:04:55 sean-k-mooney its that prefer or having the extra job
14:05:03 bauzas ok cool with me too
14:05:16 gibi OK with me to force py310 to run with 2.0
14:05:32 dansmith I just think the actual likelihood of breakages between 3.9 and 3.10 is minor, so using 3.10 as our 2.0 job makes frugal sense,
14:05:40 stephenfin Also, we can't just reuse a job unless we want to get rid of our use of job templates
14:05:44 dansmith and we can probably spot the difference between SA problems and some python base issue
14:05:54 dansmith stephenfin: ah, you're right
14:06:05 dansmith fine, fine, just stack another job I guess
14:06:06 stephenfin because it's the job templates that specifies our use of openstack-tox-whatever
14:06:24 dansmith yup
14:06:33 bauzas ~o~
14:07:09 stephenfin ack, with any luck it should be gone in 3 months or so 🤞 hopefully sooner but definitely in C
14:07:09 stephenfin ack, with any luck it should be gone in 3 months or so 🤞 hopefully sooner but definitely in C
14:07:25 sean-k-mooney ok
14:07:32 sean-k-mooney so we will proceed with the patch as is
14:07:43 dansmith I will bet you one unit of currency that it will not be gone in three months :P
14:08:36 stephenfin I value my currency and will not take that bet
14:08:43 dansmith hehe
14:09:04 gibi :)
15:14:34 bauzas reminder : nova meeting in 45 mins here
15:36:32 opendevreview Merged openstack/nova stable/wallaby: Reproducer for bug 1983753 https://review.opendev.org/c/openstack/nova/+/853273
15:48:07 dansmith sean-k-mooney: got another guest panic this morning: https://27abb73f6979e2fd6932-3e445c1a5b8a8c84f71b5a61cff5a09b.ssl.cf1.rackcdn.com/879499/10/check/nova-multi-cell/5c92eb8/testr_results.html
15:50:01 dansmith looks like *very* early in kernel boot
15:55:20 gibi its smells like APIC https://bugs.launchpad.net/nova/+bug/1939108
15:57:53 dansmith gibi: I dunno that bug trace made it much farther than mine did.. note all the kernel timestamps are 0.0
15:58:25 dansmith but yeah I guess the timer failed messages before the crash look the same
15:58:39 dansmith so maybe it's just a difference in the kernel from then to now
15:59:32 dansmith and in check_timer() where we panic, so okay yeah
16:00:12 dansmith and another report from 2022 at the end of that report that looks more like mine
16:00:23 bauzas starting the meeting now folks
16:00:29 gibi both calls setup_IO_APIC that was my matching point
16:00:31 dansmith kashyap: I wonder if it might be worth chasing a kernel bug with that now
16:00:44 bauzas let's discuss this gate failure in a sec
16:00:50 bauzas #startmeeting nova
16:00:50 opendevmeet Meeting started Tue Jul 18 16:00:50 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:50 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 opendevmeet The meeting name has been set to 'nova'
16:00:55 bauzas hey folks
16:01:02 gibi o/
16:01:04 bauzas #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting
16:01:45 elodilles o/
16:01:49 bauzas who's around ?
16:02:59 bauzas okay, we can softly start
16:03:14 bauzas #topic Bugs (stuck/critical)
16:03:20 bauzas #info No Critical bug
16:03:31 bauzas #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 40 new untriaged bugs (+1 since the last meeting)
16:03:41 bauzas thanks melwitt for the triaging
16:04:20 bauzas any bug to discuss ?
16:04:25 Uggla o/
16:05:00 bauzas looks not, moving on
16:05:04 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:23 bauzas IIRC, artom is on PTO this week, so he can't take the baton
16:05:37 bauzas Uggla: wants to have it ?
16:06:06 Uggla yes it is ok
16:06:11 bauzas cool thanks
16:06:19 bauzas #info bug baton is being passed to Uggla
16:06:51 bauzas next topic
16:06:53 bauzas #topic Gate status
16:06:57 bauzas #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs
16:07:03 bauzas #link https://etherpad.opendev.org/p/nova-ci-failures
16:07:15 bauzas gibi: wants to discuss the kernel panic bug you found ?
16:07:26 gibi that is dansmith finding
16:07:42 gibi I just matched it to an older report
16:08:04 gibi I guess we can try the apic debug kernel param
16:08:31 bauzas ack
16:08:58 gibi as the kernel error message suggests
16:08:59 gibi Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.
16:09:52 bauzas any link to share .

Earlier   Later