Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-05-02
12:50:37 openstackgerrit Sean McGinnis proposed openstack/nova master: Add py38 package metadata https://review.opendev.org/724990
17:32:36 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Validate a BDMs disk_bus when provided https://review.opendev.org/724842
23:28:21 openstackgerrit Thomas Goirand proposed openstack/nova master: Add a /healthcheck URL https://review.opendev.org/724684
#openstack-nova - 2020-05-04
00:27:23 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/ussuri: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/725146
00:57:10 openstackgerrit Ghanshyam Mann proposed openstack/nova stable/train: DNM: testing what all grenade jobs running https://review.opendev.org/725147
02:33:07 alex_xu sean-k-mooney: gibi fyi, we will have someone working on provider config xml.
05:08:03 openstackgerrit Takashi Natsume proposed openstack/python-novaclient master: [WIP] Switch legacy Zuul jobs to native Zuul v3 jobs https://review.opendev.org/725163
06:55:55 gibi alex_xu: ack, thanks
08:33:14 gibi stephenfin: hi! Do you have an idea why the reno job fails on this backport to stable/ussuri? https://review.opendev.org/#/c/725146/1 It is green for me locally but locally the releasenotes tox target does not try to generate stable/ussuri notes
08:56:25 bauzas gibi: me looks
08:59:31 bauzas gibi: I don't see any problems with the reno file itself, just testing it locally
08:59:59 bauzas Warning, treated as error: <reno.sphinxext stable/ussuri>:115:Duplicate target name, cannot be used as a unique reference: "upgrade notes".
09:00:07 bauzas that's why we get -1 ^
09:03:11 bauzas ahah I think we probably have something missing https://docs.openstack.org/reno/latest/user/usage.html#updating-stable-branch-release-notes
09:03:53 bauzas "Occasionally it is necessary to update release notes for past releases due to URLs changing or errors not being noticed until after they have been released. In cases like these, it is important to note that any updates to these release notes should be proposed directly to the stable branch where they were introduced."
09:11:20 bauzas ok, so, relnotes are correctly written against master, but cherry-picking the change to my local stable/ussuri branch and retesting
09:11:43 bauzas I think I found the problem
09:12:31 bauzas gibi: we don't have *yet* ussuri release notes so reno writes the patch note against master twice
09:12:34 bauzas hence the duplicate
09:12:48 bauzas against 'unreleased' rather
09:13:03 bauzas lemme see if creating a ussuri.rst file would help
09:14:21 gibi bauzas: thanks for helping, I'm sitting on a meeting
09:14:31 bauzas ok, we have https://github.com/openstack/nova/blob/master/releasenotes/source/ussuri.rst
09:14:34 bauzas in master
09:14:43 bauzas which is normal
09:14:53 bauzas gibi: np
09:15:09 bauzas gibi: i think I have some potential findings but I need to test
09:15:25 bauzas and it takes a while to generate the relnotes locally as it scans all my branches
09:16:10 gibi yeah it is slow
09:16:46 bauzas interesting
09:16:53 bauzas it did worked fine on my box
09:18:05 bauzas interestingly, my current branch is ussuri when i'm testing on a local stable/ussuro
09:18:19 bauzas which is not the case with the job https://zuul.opendev.org/t/openstack/build/9c4f698044dc4af2b5bcb326b6a3e823/log/job-output.txt
09:20:12 gibi yeah, I also cannot reproduce the problem locally
09:35:16 bauzas gibi: maybe a job issue
09:36:55 gibi bauzas: interestingly the job tries to generate reno for stable/ussuri the local tox target does not try that for me
09:38:51 gibi locally I get
09:38:51 gibi scanning /home/gibizer/upstream/git/nova/releasenotes/notes for current branch release notes
09:38:54 gibi got versions []
09:39:06 gibi in the job
09:39:07 gibi 2020-05-04 07:58:23.877287 | ubuntu-bionic | scanning /home/zuul/src/opendev.org/openstack/nova/releasenotes/notes for current branch release notes
09:39:11 gibi 2020-05-04 07:59:02.632023 | ubuntu-bionic | got versions ['21.0.0.0rc1-16']
09:39:14 gibi 2020-05-04 07:59:02.664924 | ubuntu-bionic | reading sources... [100%] ussuri
09:39:17 gibi 2020-05-04 07:59:02.670555 | ubuntu-bionic | scanning /home/zuul/src/opendev.org/openstack/nova/releasenotes/notes for stable/ussuri release notes
09:39:20 gibi 2020-05-04 08:00:13.350874 | ubuntu-bionic | got versions ['21.0.0.0rc1-5', '21.0.0.0rc1']
09:41:22 bauzas lemme doublecheck mine
09:41:42 gibi are these versions '21.0.0.0rc1-5' are git tags?
09:41:46 gibi I only have 21.0.0.0rc1 tag
09:42:13 bauzas gibi: that's my env http://paste.openstack.org/show/793033/
09:42:34 bauzas gibi: I branched stable/ussuri and cherry-picked the change into it
09:43:10 bauzas gibi: yup, AFAIR, reno works with git commits and tags
09:43:12 gibi it is pretty similar to mine except you have got versions ['21.0.0.0rc1-5']
09:43:47 bauzas which is expected
09:44:04 bauzas gibi: if I tag my branch as 21.0.1 per se
09:44:10 bauzas gibi: then you'll be seeing it
09:44:40 bauzas gibi: see https://docs.openstack.org/project-team-guide/release-management.html#how-to-preview-release-notes-at-rc-time
09:45:10 bauzas gibi: remember that reno tries to see which tags are related to which releasenotes
09:45:40 bauzas once you tag a .z version, then you'll see it
09:46:57 gibi bauzas: does it mean that the gate job temporarly tag the repo and then generate the notes?
09:47:09 bauzas I don't think so
09:47:27 gibi OK. I'm lost :)
09:48:03 bauzas and see whether reno finds it
09:48:08 gibi ok
09:48:44 bauzas we need dhellmann or someone else from the reno team IMHO
09:49:37 bauzas gibi: what's not normal is that we scan both the current branch and the stable/ussuri one
09:50:01 bauzas (against a stable/ussuri change)
09:50:07 bauzas because both are identical
09:50:26 bauzas gibi: you understand this ?
09:50:54 gibi I accept this as a probable problem. I just blocked by the fact that I cannot reproduce the result locally
09:50:57 bauzas https://zuul.opendev.org/t/openstack/build/9c4f698044dc4af2b5bcb326b6a3e823/log/job-output.txt#1415 and https://zuul.opendev.org/t/openstack/build/9c4f698044dc4af2b5bcb326b6a3e823/log/job-output.txt#1418 generate the same
09:51:05 bauzas gibi: yeah, me too
09:54:47 bauzas gibi: what we could do is trying to avoid to present the upgrade note in master
09:54:58 bauzas gibi: I can try to provide a DNM for testing
09:55:30 bauzas gibi: actually, the upgrade note is invalid for Victoria, right ?
09:56:27 bauzas gibi: see what happens when you tag locally : http://paste.openstack.org/show/793034/
09:57:27 bauzas gibi: and by looking at my html build, I see the note, yeepee
09:57:39 bauzas (marked against my fake 21.0.1)
09:57:42 gibi so locally it is still not generate notes for stable/ussuri
09:57:50 bauzas it does
09:58:00 bauzas but as 'unreleased'
09:58:23 bauzas see https://docs.openstack.org/releasenotes/nova/unreleased.html
09:58:39 bauzas gibi: this is bad ^
09:58:56 bauzas because the upgrade issue is when you upgrade from Train to Ussuri, right?
09:58:59 gibi bauzas: so we have to remove the reno from master (V)?
09:59:08 bauzas gibi: we'll ignore it
09:59:33 bauzas https://docs.openstack.org/project-team-guide/release-management.html#updating-stable-branch-release-notes
10:00:12 bauzas gibi: I'm just forging a :ignore-notes: directive
10:00:22 gibi ahh
10:00:23 gibi thanks
10:01:08 gibi so we need the ignore-notes patch on master?
10:01:16 bauzas I *think*
10:01:33 bauzas gibi: we wrote it for the T->U upgrade, right?
10:01:38 gibi right
10:01:52 bauzas ok, so let's ignore it or it will appear in the 22.0.0 relnotes
10:01:54 gibi we just merged it first on master
10:02:02 gibi and then backport
10:02:06 bauzas gibi: sure, i understood but reno files are different
10:02:14 gibi yeah, I get to feel that
10:02:15 gibi :)
10:02:17 bauzas gibi: see the warnings in the reno docs :)

Earlier   Later