Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-05-04
15:05:58 bauzas okay, I *think* I understand
15:06:14 bauzas by merging gmann's patch, we're creating a new section
15:06:19 dhellmann right
15:06:45 dansmith jsuchome: I had feedback, so addressing that is necessary in addition to just rebasing it
15:07:13 dhellmann sheesh, there are a lot of changes in nova :-) generating the release notes takes ages
15:10:18 gmann dhellmann: should not merge section happen when it is release say rc2 version relese? and till then anything new goes into unreleased section instead of ussuri release section ?
15:10:31 dhellmann I think I have a fix, give me a sec to rebase
15:11:38 gmann dhellmann: ok, thanks
15:12:59 gmann bauzas: dhellmann may be i could have edited the existing reno instead of new so that it would conflict but that just hides this issue does not solve.
15:13:31 gmann bauzas: gibi i was searching and could not find any such issue (where new reno added in rc) for train and stein rc.
15:17:11 gibi honestly I can only agree what you found with the reno problem but I cannot give to that discussion. I hope dhellmann's fix will help
15:19:41 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/725146
15:19:41 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: use more distinct link references in release notes https://review.opendev.org/725301
15:19:52 dhellmann let's see if ^ helps
15:22:33 jsuchome dansmith: well, yeah, I'm not sure how to address it. Are you suggesting some different path then using this formerly deprecated entry point? As I'm not the creator of the original code I would rather not rework it completely...
15:22:44 dhellmann gibi : sphinx is like a compiler & linker for docs instead of for code. If there are 2 sections on a page with the same name, that's like having 2 functions in a module with the same name. Sphinx can't figure out which one you want to link to.
15:23:07 gibi dhellmann: thanks. and also thanks for fixing it
15:23:28 dansmith jsuchome: yes, I'm not okay with undeprecating that hook mechanism just to add something in-tree for it
15:23:51 dhellmann this is only related to reno because it's assembling the notes files into rst for sphinx. the same error could have happened if the text had been written by hand
15:30:58 gibi dhellmann: so your patch can fix it as it changes the references current pointing to the ambiguous title to point to some specific title that is not duplicated by gmann's recent patch
15:31:13 dhellmann that's right
15:31:16 gmann dhellmann: thanks for fixing. and that did not complain in original change because Sphinx already merged the Upgrade Section - https://review.opendev.org/#/c/725301/1/releasenotes/notes/ussuri-prelude-4b96f1244cefcdf4.yaml
15:31:25 dhellmann the patch isn't quite right (it failed locally) but it's a different error
15:31:45 bauzas sorry was in a meeting
15:32:30 gmann dhellmann: any way Sphinx can error or warning for using implicit links at least for same link in same page? just for future so that it can be fixed in original change itself.
15:33:04 dhellmann good question. I don't know.
15:33:21 dhellmann there's a `reno lint` command, maybe that's a check it could do?
15:33:49 bauzas I'm a bit afraid of https://review.opendev.org/#/c/725301/ because it would be a bit more difficult for people to provide their own reno notes
15:34:01 gmann dhellmann: ok. let me try sometime later.
15:34:16 bauzas but we're close to RC2 so I wouldn't be picky
15:34:47 dhellmann another possible improvement for reno is to have it automatically add unique anchors for each file so that the prelude could have used those anchor names
15:35:12 dhellmann the problem with that is that the same note can appear in multiple series (backports) so you can't just use the filename
15:36:05 bauzas dhellmann: gmann: gibi: if you wanna get MHO, I'd just prefer to https://review.opendev.org/#/c/725146/2/releasenotes/notes/bug-1875418-0df3198e36530ec7.yaml to just amend an existing upgrade note instead of creating this YAML file
15:36:13 gmann dhellmann: yeah, asking for explicit anchor is much safe in case of backporting things.
15:36:34 bauzas we could leave some placeholder YAML file for backports
15:36:56 bauzas this would be simplier to manage rather than explicit sphinx targets
15:36:59 dhellmann bauzas : the whole point of reno is you don't have to do that sort of thing
15:37:03 bauzas I know :(
15:37:06 gmann bauzas: but that does not solve the whole things, same issue can occur for any new reno while backport
15:37:26 dhellmann another fix would be to remove the links in the prelude entirely
15:37:49 gibi bauzas: would you like to do that change on master first to keep the reno (even if it is ignored) in sync between branches?
15:38:10 bauzas gibi: which change ?N
15:38:41 gibi bauzas: ammending the existing upgrade reno instead of adding a new one
15:38:52 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: use more distinct link references in release notes https://review.opendev.org/725301
15:38:53 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/725146
15:39:02 dhellmann ok, I think ^ solves it
15:39:44 dhellmann the 2nd problem was that the text of the links was the same, too, so `title <url1>`_ and `title <url2>`_ was causing a conflict. The fix was to use double underscore so sphinx doesn't try to "define" a link with the title
15:39:59 bauzas sorry, still in a meeting :/
15:40:17 gmann i think, the idea of not have link in prelude make sense as there is only one 'Upgrade section' in merged releasenotes .
15:40:27 dhellmann I have to go do some other stuff, so I'll leave the bots to run and let you decide how you want to fix it.
15:40:35 gibi dhellmann: thanks
15:40:45 gmann dhellmann: sure, thanks again.
15:40:55 dhellmann gmann : for projects with 2 real releases in one stable branch there could be multiple upgrade sections
15:41:15 dhellmann so if there are upgrade notes from 21.0.0 to 21.0.1 then you'll have the same thing again
15:41:17 gibi gmann, bauzas: I have to drop for today. I would go with the current proposed solution just because it is already proposed and we have limited time
15:41:28 gmann dhellmann: i see.
15:41:34 bauzas gibi: fair enough
15:41:38 gmann ok
15:41:42 bauzas and I'm on the same tangency
15:41:52 gibi bauzas: but we can talk about rules for the future to avoid this
15:42:06 bauzas I also have very limited brain now to understand all the issues
15:42:34 bauzas gibi: worth +2ing both dhellmann's changes and then I +W them ?
15:42:42 gmann bauzas: gibi this is good things to note down for rc backport somewhere to handle in master side itself, any good place you recommend. wiki/doc ?
15:42:49 jsuchome dansmith: what are my options? Would it be acceptable just to extend load_transfer_modules to explicitly load rbd download mechanism?
15:43:07 bauzas gmann: we have the contributor docs
15:43:08 gibi bauzas: I'm not a stable core
15:43:09 gmann review guide ?
15:43:25 gibi gmann: review guide is a good place yes
15:43:40 bauzas gmann: we have the contributor docs https://docs.openstack.org/nova/latest/contributor/releasenotes.html
15:43:41 gmann let me add something there and we can find common way whatever we agree on.
15:43:47 gibi gmann: thanks!
15:43:50 bauzas gibi: you are for ussuri
15:44:04 dansmith jsuchome: I have to look at it in more detail to figure out what the right thing to do is, but using the external plug point (and changing the behavior of that in the process) isn't the best plan, IMHO
15:44:05 gibi bauzas: I tried I only have +1 right
15:44:10 bauzas gibi: waaaaaat ?
15:44:31 gibi elod: If you have time there is stable/ussuri reno fix to merge before RC2 https://review.opendev.org/#/c/725301
15:44:35 dansmith jsuchome: I'm guessing that the rbd image module can probably pass a download routine to glance but I'd need to go look
15:44:37 jsuchome dansmith: it was written in some release notes that in case some users are already using it, it might be the way to un-deprecate it. That's exactly the case here
15:44:54 dansmith jsuchome: I don't want to un-deprecate it
15:46:26 bauzas gibi: okay, the ship halfly-sailed, we need +W
15:46:42 gibi bauzas: I've pinged elod, he will chekck it
15:46:48 bauzas leave it for now, I'll chase up another stable-core
15:47:04 bauzas gibi: but this isn't normal you can't +2 on stable/ussuri
15:47:15 gibi and I have to leave so talk to you tomorrow
15:47:22 bauzas gibi: np, \o
15:47:27 gibi o/
15:51:18 gmann bauzas: gibi thanks. ttyt
15:57:49 kashyap bauzas: Here's the 'nova-next' in-progress job :) -- https://review.opendev.org/#/c/708701/
15:58:01 kashyap Need to dig into the Ubuntu-based failures
16:00:05 dansmith jsuchome: I'll put up some code as an example of a path forward in a bit
16:00:47 jsuchome dansmith: thanks!
16:13:25 kashyap gibi: When you get time tomm, please have a gander at point-166 here: https://etherpad.opendev.org/p/nova-victoria-ptg (Cc: bauzas)
16:34:31 dansmith jsuchome: do you want me to mangle the existing patch a bit to show what I think needs to happen? it'll take it into WIP state, but should be able to form a basis for moving forward
16:58:39 openstackgerrit Dan Smith proposed openstack/nova master: Remove deprecated nova.image.download hook https://review.opendev.org/725338
17:07:40 elod bauzas dhellmann : the releasenotes job works now, but the links seem incorrect in the generated docs: https://review.opendev.org/#/c/725301/ ... or do I miss something?
17:10:04 dhellmann elod : you're right
17:10:15 dhellmann I probably messed up the link syntax
17:11:31 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: use more distinct link references in release notes https://review.opendev.org/725301
17:11:32 openstackgerrit Doug Hellmann proposed openstack/nova stable/ussuri: Add nova-status upgrade check and reno for policy new defaults https://review.opendev.org/725146
17:11:38 dhellmann elod : let's try ^

Earlier   Later