Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-03-21
14:24:51 bauzas sean-k-mooney: have you seen my ping about https://bugs.launchpad.net/nova/+bug/1964995 ?
14:24:57 bauzas sean-k-mooney: not sure it's a regression
14:26:39 erlon no, let me see
14:27:22 bauzas I just added the tag to make sure we don't forget about it
14:27:29 bauzas for the moment, we don't have any needs for a RC2
14:27:44 bauzas https://review.opendev.org/q/project:openstack/nova+branch:stable/yoga is super empty
14:27:58 sean-k-mooney bauzas: am so vpd was added this cycle and it intoduced the bug
14:28:03 bauzas elodilles: ^ for your knowledge
14:28:07 sean-k-mooney however nothing uses the network capablities
14:28:19 sean-k-mooney so to me its a regression but it wont break anything
14:28:55 sean-k-mooney we only merged half of the network capablities feature e.g. the reportign into the db we did not merge the other half that consumes that info
14:30:17 sean-k-mooney bauzas: so i think that should be fixed but im not conviced we need an RC2 for it
14:30:41 sean-k-mooney its more tech debth then somethign that will break any user of nova
14:30:50 bauzas sean-k-mooney: if nothing was used in Xena, it's not a regression
14:31:08 bauzas sean-k-mooney: ok, so I'll remove the tag and I'll change the title
14:31:37 sean-k-mooney i was orginaly hoping to get that in rc1 by the way now that that has shiped i think it can just be a normal bugfix after the release
14:37:07 bauzas sean-k-mooney: yeah, we can merge any bugfix before RC1 but after, the ship has sailed
14:37:21 bauzas like erlon's bugfix
14:37:42 bauzas those are just policies for distro vendors and ops, which I can understand
14:46:26 elodilles bauzas: sean-k-mooney: yepp, GA is always Wednesday (compared to milestone and other deadlines, which are on Thursdays)
14:47:48 elodilles bauzas: ack, so we have one bug that does not need an RC2, as it seems now
15:10:53 sean-k-mooney bauzas: can we retarget https://blueprints.launchpad.net/nova/+spec/cpu-selection-with-hypervisor-consideration to zed yet or do we need to wait
15:11:22 sean-k-mooney it looks like yoga is still set as the current branch in launchpad
15:11:41 sean-k-mooney i assume you are waitign till the actual release to swap it over
15:13:23 sean-k-mooney should we add that blueprint to the meeting adgenda or wait untill after the release
15:22:17 sean-k-mooney elodilles: could you take a look at https://review.opendev.org/c/openstack/nova/+/828413/2 the follow up has +2+w and is waiting on the job being enabled
15:29:31 elodilles sean-k-mooney: hmmm, jobs aren't backported usually, and as I see it's non-voting
15:31:14 sean-k-mooney well we dont currently have coverage for hybrid plug in xena
15:31:25 sean-k-mooney it was the default before xena
15:31:44 sean-k-mooney but we did not readd it when we changed the devstack default
15:32:22 sean-k-mooney so this is really just add back coverage we had for wallaby to xena
15:32:40 sean-k-mooney which we now have on yoga again
15:33:15 elodilles (at least the new job nicely shows that the bug fix works)
15:33:20 sean-k-mooney it is non voting but it actully should get fliped to voting at some point
15:33:31 sean-k-mooney i think that is in the follow up patch
15:33:32 elodilles yes, i see now
15:34:02 sean-k-mooney yep so we were using that like a regression test to demonstrate the issue
15:54:41 elodilles sean-k-mooney: +2+W'd, thanks for the details about the fix
15:56:59 sean-k-mooney :)
16:00:19 bauzas sean-k-mooney: I prepared the zed cycle
16:00:33 bauzas sean-k-mooney: but actually I forgot to update the launchpad main branch
16:15:00 artom bauzas, sean-k-mooney, https://review.opendev.org/c/openstack/nova/+/806049/
16:17:54 sean-k-mooney thanks :)
16:52:56 bauzas fwiw, I'm about to give a go to https://review.opendev.org/c/openstack/nova/+/833440 as it won't harm our future tick-tock cadence
16:53:20 bauzas this is about removing Xena computes support for Zed
16:53:34 bauzas but we definitely need to discuss this at the PTG
17:30:55 gibi_pto bauzas: correct, we have to change that limitation in the future to support N-2 -> N upgrades
17:31:29 bauzas I'll leave this change open until tomorrow and we'll discuss at the nova meeting
17:31:34 sean-k-mooney gibi_pto: well that is the topic to discuss at the PTG apprently we dont actully have too but likely should
17:32:12 sean-k-mooney gibi_pto: just repeating what i have heard but appretly live rolling upgrade supprot for n-2 is left to the projects to opt in too
17:33:08 sean-k-mooney so if we elect to supprot n-2 rolling upgrades upstream then we shoudl alter that check and add a job to validate it if we dont then we could keep it at n-1
17:33:27 gibi_pto ahh, OK, lets talk that through on the PTHG
17:33:29 gibi_pto PTG
17:33:57 gibi_pto bauzas: that change fails in grenade on the service version check
17:34:11 gibi_pto https://zuul.opendev.org/t/openstack/build/a24b974ae9fd487694724da795bfcd2a/log/controller/logs/screen-n-cond.txt#1140
17:34:12 dansmith bauzas: I think we should have something like this for nova: https://docs.openstack.org/cinder/latest/contributor/gerrit.html#ci-job-rechecks
17:34:36 dansmith some discussion of late in the tc about how most people just do blind rechecks all the time
17:35:09 dansmith probably don't need that much detail for nova given that we don't have all the drivers, but still, I see a lot of "recheck" with no explanation, which I think often means no inspection
17:35:40 dansmith I'm hoping we'll have some general direction out of the tc about this, but would be nice to jumpstart in the nova community with reminders and constructive peer pressure :)
17:36:50 gibi_pto dansmith: I suppor that idea!
17:37:11 dansmith gibi_pto: I support your support :)
17:37:21 sean-k-mooney we used to have a section that said you should file a bug and add an elastic recheck query i think
17:37:23 dansmith however, I do not support you spending pto hanging out in irc :P
17:37:24 gmann like neutron, we can monitor how many recheck for this week we had
17:38:05 dansmith sean-k-mooney: yeah, but we need more constructive peer pressure regardless.. clear documentation to point to would be helpful when doing that
17:38:16 gmann s/gibi_pto/gibi_pto_but_work_on_irc :)
17:38:24 dansmith sean-k-mooney: if we've got it, then cool, but a concerted team-wide effort is needed I think
17:38:40 dansmith gmann: paid time on work is just work :P
17:38:40 gibi_pto nah, I just randomly hanging around :)
17:38:41 sean-k-mooney dansmith: i think we removed it at som epoint im checking to see if we still do
17:38:53 sean-k-mooney i tought it was in https://github.com/openstack/nova/blob/master/doc/source/contributor/code-review.rst but not seeign it
17:40:21 dansmith I can certainly write up some stuff
17:40:23 sean-k-mooney its also not in our testing doc https://github.com/openstack/nova/blob/master/doc/source/contributor/testing.rst so ya i think we remved it
17:47:49 sean-k-mooney dansmith: this is proably where it need to be updated https://opendev.org/openstack/nova/src/branch/master/doc/source/contributor/process.rst#how-can-i-get-my-code-merged-faster
17:48:23 sean-k-mooney we currently say """If you're fixing something that only occasionally failed before, maybe recheck a few times to prove the tests stay passing."""
17:48:41 sean-k-mooney but we dont give guidnce on when its appropate to recheck in general
17:48:51 gmann dansmith: or may be to writeup in project-team-guide and point projects doc to that ?
17:49:45 sean-k-mooney gmann: we do link to this https://docs.opendev.org/opendev/infra-manual/latest/developers.html#automated-testing
17:50:12 sean-k-mooney we used to have a version fo that in nova
17:50:48 gmann I mean to tell "no blind recheck" and 'best way to check logs and find issue' explicitly
17:50:51 sean-k-mooney step 2 """Examine the console log or other relevant log files to determine the cause of the error. If it is related to your change, you should fix the problem and upload a new patchset. Do not use “recheck”."""
17:52:45 sean-k-mooney we do link to that form our testing.rst doc
17:53:13 gmann yeah, I think due length of this doc it got hidden and people ignore to read the complete doc. we can add link to this doc for details but have a explicit section about recheck and how to use it in best way
17:53:21 gmann dur to
17:53:52 sean-k-mooney if we had a centralised one we coudl have zuul link top it when it fails
17:54:00 sean-k-mooney by updating the failure message
17:55:04 sean-k-mooney in any case it took me 5 mins to find that and i more or less know what im looking for so a new contibutor is likely not going to find it
17:56:02 gmann true
18:44:13 stephenfin sean-k-mooney: https://review.opendev.org/c/openstack/os-traits/+/833826 easy patch
18:47:01 sean-k-mooney stephenfin: ah has the discussion on that been resovled
18:47:25 sean-k-mooney i saw the thread you started but did not keep track of it while i was off
18:49:14 sean-k-mooney oh its just the reference syntax in zuul. that keeps duplicaiton down at least.
18:49:29 sean-k-mooney the zuul change that is https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286/2/zuul.d/project-templates.yaml
18:54:34 sean-k-mooney stephenfin: ok done.#
18:54:43 stephenfin spot on, thanks!
18:57:42 sean-k-mooney did you also do os-resource classes
18:59:01 sean-k-mooney stephenfin: dont see it here https://review.opendev.org/q/topic:add-python3-unversioned-jobs but i think its independent too https://github.com/openstack/releases/blob/master/deliverables/_independent/os-resource-classes.yaml
18:59:21 stephenfin Oh, my hacky script probably just missed that
19:00:16 sean-k-mooney i need to add a PTG topic about this by the way
19:00:32 sean-k-mooney we might want to merge those back into placment

Earlier   Later