Earlier  
Posted Nick Remark
#openstack-nova - 2022-11-29
16:14:10 bauzas not all of us work upstream everyday :)
16:14:10 sean-k-mooney we could but the idea was to have 2 of them
16:14:15 sean-k-mooney to take the pressure off m3
16:14:26 sean-k-mooney so one before m2 and one before m3
16:14:32 gibi I'm back on the 5th of Jan
16:14:55 sean-k-mooney so we coudl proably do one on the 10th of january
16:15:01 sean-k-mooney most will be around by then
16:15:09 bauzas sean-k-mooney: I don't disagree, I'm just advocating that some folks couldn't be able to have two review days on the same week
16:15:15 sean-k-mooney if we want ot keep it aligned to the meetign days
16:15:28 gibi 10th works for me
16:16:17 bauzas gibi: we don't really need to align those review days to our meeting
16:16:26 bauzas gibi: but this is nice as a reminder
16:17:02 gibi so I think we are converging on Dec 14th as spec and Jan 10th as a code review day
16:17:36 bauzas I think this works for me
16:17:53 bauzas and we can have another implementation review day later after Jan 10th
16:18:15 sean-k-mooney ya sure that sound workable
16:18:39 bauzas as a reminder, Antelope-3 (FF) is Feb 16th
16:18:55 bauzas more than 5 weeks after Jan 10th
16:19:09 sean-k-mooney there are still a few bits i would hope we can merge by the end of the year however. namely i would liek to see us make progress on the pci in placement serises
16:19:20 bauzas sure
16:19:52 sean-k-mooney ok so i think we can move on for now
16:19:56 bauzas what we can do is to tell we can review some changes by Dec 15th if we want so
16:20:23 bauzas that shouldn't be a specific review day, but people would know that *some* folks can review their changes by this day
16:20:39 bauzas anyway, I think we found a way
16:21:08 gibi yepp
16:21:11 bauzas #agreed Dec-14th will be a spec review day and Jan-10th will be an implementation review day, mark your calendars
16:21:41 bauzas #action bauzas to send an email about it
16:22:16 bauzas #agreed Some nova-cores can review some features changes around Dec 15th, you now know about it
16:22:27 gibi :)
16:22:28 bauzas OK, that's it
16:22:43 bauzas moving on
16:22:50 bauzas (sorry, that was a long discussion)
16:22:54 bauzas #topic Review priorities
16:23:00 bauzas #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2)
16:23:05 bauzas #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review
16:23:30 bauzas I'm happy to see people using it
16:23:56 bauzas that's it for that topic
16:24:00 bauzas next one
16:24:07 bauzas #topic Stable Branches
16:24:13 bauzas elodilles: your turn
16:24:16 elodilles ack
16:24:20 elodilles this will be short
16:24:23 elodilles #info stable branches seem to be unblocked / OK
16:24:27 elodilles #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci
16:24:30 elodilles that's it
16:25:58 gibi nice
16:26:14 bauzas was quick and awesome
16:26:36 bauzas last topic but not the least in theory,
16:26:45 bauzas #topic Open discussion
16:26:55 bauzas nothing in the wikipage
16:26:58 bauzas so
16:27:04 bauzas anything to discuss here by now ?
16:27:08 gibi -
16:27:17 sean-k-mooney did you merge skipign the failing nova-lvm tests yet
16:27:26 sean-k-mooney or is the master gate still explodingon that
16:27:30 bauzas I think yesterday we said we could discuss during this meeting about the test skips
16:27:46 bauzas but given we merged gmann's patch, the ship has sailed
16:27:56 sean-k-mooney ack
16:28:02 sean-k-mooney so they are disabeled currently
16:28:05 bauzas sean-k-mooney: see my ML thread above ^
16:28:06 sean-k-mooney the failing detach tests
16:28:15 sean-k-mooney ah ok will check after meeting
16:28:19 bauzas sean-k-mooney: you'll get the link to the gerrit change
16:28:20 sean-k-mooney nothing else form me
16:28:29 auniyal hand-raise: zuul frequent timeout issue/fails - this seems to be resource issue, is it possible zuull resource can be increased ?
16:29:09 bauzas sean-k-mooney: tl;dr: yes we skipped the related tests but maybe they are actually not needed as you said
16:29:16 sean-k-mooney auniyal: not really timeout are not that common in our jobs
16:29:24 bauzas auniyal: see what I said above, we had problems with the gate very recently
16:29:26 sean-k-mooney auniyal: do you have an example
16:29:31 auniyal in morning when there are less number of jobs running if we run same, job gets passed
16:29:40 auniyal like less then 20
16:29:47 auniyal right now 60 jobs are running
16:29:52 sean-k-mooney that should not really be a thing
16:30:03 sean-k-mooney unless we have issues with our ci providers
16:30:17 bauzas auniyal: if you speak about job results telling timeouts, agreed with sean-k-mooney, you should tell which ones so we could investigate
16:30:24 sean-k-mooney we ocationally have issues with slow providers but its not normally coralated with the number of runnign jobs
16:30:29 bauzas yup
16:30:35 auniyal ack
16:30:38 bauzas timeouts are generally an infra issue
16:30:43 bauzas from a ci provider
16:30:50 bauzas but "generally"
16:31:04 bauzas which means sometimes we may have a larger problem
16:31:07 sean-k-mooney auniyal: do you have a gerrit link to a change where it happend
16:31:12 dansmith are they fips jobs?
16:31:31 clarkb bauzas: I'm not sure I agree with that statement
16:31:31 sean-k-mooney oh ya it could be that did we add the extra 30 mins ot the job yet
16:31:38 clarkb we have significant amounts of very inefficient test payload
16:31:55 clarkb yes slow providers make that worse, but we have lots of ability to improve things in the jobs just about every time I look
16:32:15 sean-k-mooney clarkb: we dont often see timeouts in the jobs that run on the nova gate
16:32:29 sean-k-mooney we tent to be well within the job timeout interval
16:32:45 sean-k-mooney that is not nessialy the same for other projects
16:32:46 clarkb (it is common for tempets jobs to dig into swap which slows everything down, devstack uses osc which is super slow because it gets a new token for every request and has python spin up time, ansible loops are costly with large numbers of entries and so on)
16:32:58 auniyal sean, I am trying to find a link but its time taking
16:33:04 clarkb sean-k-mooney: yes swap is a common cause for the difference in behaviors and that isn't an infra issue
16:33:15 clarkb sean-k-mooney: and devstack runtime could be ~halved if we stopped using osc
16:33:25 clarkb or improved osc's startup and token acquisition time
16:33:31 sean-k-mooney clarkb: ack
16:33:36 clarkb I just want to avoid the idea its an infra issue so ignore it
16:33:39 sean-k-mooney ya the osc thing is a long runing known issue
16:33:49 clarkb this assertion gets made often then I go looking and there is plenty of job payload that is just slow

Earlier   Later