| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-21 | |||
| 14:25:21 | bauzas | mgoddard: ack, will review it later today | |
| 14:25:28 | mgoddard | thanks! | |
| 14:26:49 | bauzas | stephenfin: can you please help me understand what you mean by https://review.opendev.org/#/c/721548/1/releasenotes/notes/ussuri-prelude-4b96f1244cefcdf4.yaml@12 ? | |
| 14:27:07 | bauzas | stephenfin: looking at https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#hyperlinks I can't find what you mean | |
| 14:27:15 | stephenfin | bauzas: | |
| 14:27:17 | stephenfin | `Hello, world`__ | |
| 14:27:18 | stephenfin | ||
| 14:27:26 | stephenfin | __ https://example.com | |
| 14:27:52 | stephenfin | Or grep for '__' in releasenotes/notes | |
| 14:27:54 | bauzas | okay, but that's not something related to sphinx rST right? | |
| 14:28:13 | stephenfin | It's a general rST thing, not specific to Sphinx | |
| 14:28:46 | stephenfin | bauzas: https://docutils.sourceforge.io/docs/user/rst/quickref.html#indirect-hyperlink-targets | |
| 14:28:51 | bauzas | ok, /me goes looking at https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html | |
| 14:29:01 | bauzas | heh, jinxed | |
| 14:29:10 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP: nova-next: Start testing the 'q35' machine type https://review.opendev.org/708701 | |
| 14:30:37 | bauzas | ah, OK, I understand better : "The reference name of the reference is not used to match the reference to its target. Instead, the order of anonymous hyperlink references and targets within the document is significant: the first anonymous reference will link to the first anonymous target. The number of anonymous hyperlink references in a document must match the number of anonymous targets. " | |
| 14:31:42 | stephenfin | Yup. Named links must be unique in their document so they chance of having conflicts in release notes is reasonably high, given the volume of them we have | |
| 14:32:07 | stephenfin | *so the chance | |
| 14:47:37 | stephenfin | dansmith: Am I wrong, or should this not happen? https://bugs.launchpad.net/nova/+bug/1868033 | |
| 14:47:37 | openstack | Launchpad bug 1868033 in OpenStack Compute (nova) "Booting instance with pci_device fails during rocky->stein live upgrade" [High,Confirmed] - Assigned to Stephen Finucane (stephenfinucane) | |
| 14:47:38 | stephenfin | Because of https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L555-L564 | |
| 14:50:03 | dansmith | stephenfin: well, he's saying that it _is_ trying to backport, but it's not backporting far enough, which makes it sound like the manifest being sent it wrong or something | |
| 14:50:08 | dansmith | which really shouldn't happen | |
| 14:50:31 | dansmith | he's wrong to equate the upgrade_level to anything with objects though -- they are unrelated | |
| 14:50:55 | stephenfin | yeah, that patch isn't a suitable fix | |
| 14:53:21 | dansmith | stephenfin: I wonder if it's because that object isn't calling super() | |
| 14:53:56 | dansmith | and its obj_make_compat() is only handling the sub-object backporting, which shouldn't be needed anymore anyway, so maybe this one got skipped when those were culled? | |
| 14:55:23 | stephenfin | Ah, good spot. That's likely it | |
| 14:55:53 | stephenfin | the superclass handles ListOfObjectField and ObjectField fields explicitly | |
| 14:56:04 | dansmith | right, I'm having to reboot my dev machine, | |
| 14:56:18 | dansmith | but I think you'll find most list objects don't have an explicit backport routine anymore | |
| 14:57:33 | dansmith | yeah, confirmed, but let me look up the culling patch | |
| 14:59:29 | dansmith | ah, I think I see | |
| 15:00:12 | dansmith | we used to use that obj_relationships mapping, and obj_make_compatible was still centralized based on that map for lists | |
| 15:00:35 | dansmith | but this one didn't use that, so it was overriding from the beginning and thus didn't get caught in the grep | |
| 15:02:21 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548 | |
| 15:02:25 | dansmith | stephenfin: I think we need to get sam to test the proper fix..happy to do that unless you've already started | |
| 15:02:43 | stephenfin | dansmith: Nope, go for it | |
| 15:05:40 | bauzas | gibi: stephenfin: if you don't mind, as I said in a comment, I don't want to depend on https://review.opendev.org/#/c/720129/ | |
| 15:06:07 | bauzas | we had a terrible experience once in Newton when we merged the prelude reno file *after* we branched to Ocata (IIRC) | |
| 15:06:28 | bauzas | because the prelude wasn't seen in 14.0.0 then | |
| 15:07:31 | bauzas | yeah, I remembered correctly : https://docs.openstack.org/releasenotes/nova/newton.html#release-notes-14-0-1-stable-newton | |
| 15:08:52 | bauzas | to avoid this, you need to first merge a prelude reno file in the master, then once you branch, you can backport a fix for the file | |
| 15:13:51 | gibi | bauzas: OK, then lets have a preliminary prelude merged soon, and fix it when the doc is available | |
| 15:20:13 | openstackgerrit | Dan Smith proposed openstack/nova master: Remove stale nested backport from InstancePCIRequests https://review.opendev.org/721667 | |
| 15:27:09 | gibi | bauzas: I still not get where we use aggregate metadata for image pre-chacing feature. I think we simply use aggregates but not aggregate metadata | |
| 15:27:27 | bauzas | gibi: okay, that's maybe me | |
| 15:27:46 | bauzas | I may have misunderstood the API version | |
| 15:30:51 | bauzas | gibi: OK, you're right, will respin | |
| 15:31:02 | bauzas | https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/image-precache-support.html#os-aggregates | |
| 15:33:27 | gibi | thanks | |
| 15:36:32 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Ussuri 21.0.0 prelude section https://review.opendev.org/721548 | |
| 15:39:07 | gibi | bauzas: +2 ^^ | |
| 15:39:21 | bauzas | ack, thanks | |
| 15:39:34 | stephenfin | bauzas: think you missed something | |
| 15:39:55 | bauzas | we should hold a bit until a handful of cores and contributors have reviewed it I think | |
| 15:39:59 | bauzas | ahah, see | |
| 15:40:07 | bauzas | stephenfin: probably, tell me what :) | |
| 15:40:16 | stephenfin | I left a comment :) | |
| 15:41:04 | gibi | OK I will only vote +1 until most of the cores leave some feedback on it | |
| 15:41:09 | stephenfin | bauzas: fwiw, because you're not using Sphinx'isms there, you can use a tool like rst.ninjs.org for rendering | |
| 15:41:42 | stephenfin | (so long as you remove the yaml stuff and dedent things, obviously) | |
| 15:44:03 | bauzas | stephenfin: you can test locally with the releasenotes target | |
| 15:44:10 | bauzas | stephenfin: that's what I did and it worked | |
| 15:44:22 | bauzas | stephenfin: also replied | |
| 15:44:37 | bauzas | with the releasenotes tox* target, my bad | |
| 15:45:08 | bauzas | (but remember, you need to commit first your changes in order for reno to work | |
| 15:45:17 | stephenfin | Ah, you're right. My mistake. | |
| 15:45:52 | bauzas | <scratch, scratch> => git commit => tox -ereleasenotes (and take a coffee cup, it'll take a while to generate) | |
| 15:45:59 | stephenfin | I've another point left about putting the URLs between the bullet points too /o\ | |
| 15:46:08 | stephenfin | They render really weirdly | |
| 15:46:55 | stephenfin | Because it's rendering as multiple <ul>s instead of one <ul> with multiple <li>s | |
| 15:47:58 | bauzas | stephenfin: weirdo, look at what the tox target generates : http://paste.openstack.org/raw/792482/ | |
| 15:48:18 | bauzas | (open it as an HTML file) | |
| 15:48:44 | stephenfin | yeah, see how there are multiple <ul> tags? | |
| 15:48:51 | stephenfin | there should only be one | |
| 15:50:21 | bauzas | ok, I can fix this, I see your point | |
| 15:50:36 | stephenfin | bauzas: actually, you can do this | |
| 15:50:40 | stephenfin | http://rst.ninjs.org/#LSBgSGVsbG9gX18KCiAgLi4gX186IFRlc3QKCi0gV29ybGQKLSBUZXN0 | |
| 15:50:44 | stephenfin | just indent the links | |
| 15:50:58 | bauzas | yeah I was thinking on indenting, not dedenting | |
| 15:51:07 | bauzas | hence the <ul> tags | |
| 15:51:20 | stephenfin | cool | |
| 15:51:28 | bauzas | if I wasn't using the bullets but an ordered list, we would get 1. 1. 1. | |
| 15:51:36 | stephenfin | exactly | |
| 15:52:04 | bauzas | just verifying that's the only asked nit besides your rewordings | |
| 15:56:24 | bauzas | stephenfin: b/c I don't wanna get a stylistic -1 again, you okay with me saying : to configure `read-only` access | |
| 15:56:34 | bauzas | and not : to configure "read-only" access | |
| 15:56:45 | bauzas | (using italics instead of brakets) | |
| 15:56:46 | stephenfin | *read-only* would be better | |
| 15:56:56 | bauzas | bold, dude ? | |
| 15:56:59 | bauzas | man, you're gross | |
| 15:57:04 | stephenfin | nope, that's **read-only** | |
| 15:57:20 | stephenfin | this ain't markdown, my man | |
| 15:57:42 | stephenfin | :P | |
| 15:57:44 | stephenfin | single backticks mean default role | |
| 15:57:51 | stephenfin | which is configurable | |
| 15:58:03 | stephenfin | in most environment it defaults to italics | |
| 15:58:28 | bauzas | ah-ha I see | |
| 15:58:55 | bauzas | there is a good reason why it's named **Sphinx** AFAICT | |