Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-19
10:44:11 lyarwood with my downstream hat on an upstream backport just to Wallaby would be awesome
10:44:35 lyarwood additional backports would also be nice but that's something I can take on
10:44:47 lyarwood if it's even possible obviously
10:45:05 gibi OK, lets see if I can have time for finishing up the series today
10:46:40 lyarwood gibi: sorry I thought we had talked ourselves into delaying until X
10:47:16 lyarwood gibi: but I guess if you have time now we can get it ready ahead of that, but don't burn yourself with it if you have other more pressing work.
10:48:47 gibi lyarwood: I lean towards delaying but if I have time I will make progress
11:43:42 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Reject requests to commit intermediary snapshot of an inactive instance https://review.opendev.org/c/openstack/nova/+/781138
13:55:51 gmann gibi: bauzas stephenfin yes, this is changing 400->200 which break interopability and cross cloud migration., hence need microversion bump.
14:11:54 kashyap Gerrit bot is down?
14:12:21 kashyap stephenfin: For later, since you asked so nicely on the original review: https://review.opendev.org/c/openstack/nova/+/781725
14:12:33 stephenfin ack
14:14:04 gibi gmann: ack
14:23:28 stephenfin Oh, this is fun https://review.opendev.org/c/openstack/nova/+/781210
14:23:37 stephenfin So we broke the Aarch64 CI, but I have no idea how
14:23:52 stephenfin Hopefully ricolin will get back to us on that
14:24:21 stephenfin I suspect the metadata files are missing for some reason
14:24:27 stephenfin kashyap: FYI ^
14:25:37 kashyap stephenfin: Yeah, I don't have an AArch64 box; but 'hrw' (not here on IRC right now) did talk about AArch64 failures
14:25:48 kashyap So I hope indeed ricolin gets back w/ more precise details of the nature of the failure
14:28:28 kashyap stephenfin: BTW, aside: upstream libvirt began implementing your RFE. I was reviewing bits of this series: https://listman.redhat.com/archives/libvir-list/2021-March/msg00922.html
14:28:33 kashyap (About firmware auto-selection)
14:28:42 stephenfin aha, very good
14:29:10 stephenfin if you're following that, some WIP patches for nova that implement the libvirt feature would be helpful to make sure we don't forget
14:29:49 kashyap stephenfin: Yeah, but it still needs some more review. And I noticed a potential confusion in my review earlier today: https://listman.redhat.com/archives/libvir-list/2021-March/msg00982.html
14:29:58 jkulik Any idea why `osc-placement` doesn't include versions after 1.28?
14:30:04 kashyap stephenfin: But I agree
14:30:12 stephenfin jkulik: Is there a version after 1.28
14:30:13 stephenfin ?
14:30:20 stephenfin Genuine question :)
14:30:27 stephenfin If there is, I suspect we simply haven't added it
14:31:21 jkulik 1.28 was added for ussuri. 1.29 is supported in rocky ... O.o
14:31:29 jkulik https://github.com/openstack/osc-placement/blob/master/osc_placement/version.py#L41
14:32:20 jkulik I cannot run "os --os-placement-api-version 1.30 allocation candidate list" because it only knows how to do versions 1.28 and below ...
14:32:32 jkulik placement version 1.30 is not in supported versions: 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13, 1.14, 1.15, 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22, 1.28, 1.29
14:33:16 stephenfin In that case, I assume it's just a case that people haven't done it
14:33:17 jkulik so no allocation requests with providers in trees with osc-placement
14:33:30 stephenfin Due to lack of impetus
14:33:48 jkulik hm ... makes sense. no real reason, then :D
14:34:17 jkulik Is there any objection against always supporting the latest version available in placement?
14:34:29 viks____ Hi, When a new instance is created, nova sets a random password. But this password does work. So how to make this work? I know a method where we set with `nova set-password` command and qemu agent running on instances, but then what is the use of the random password generated during instance creation?
14:34:49 gibi jkulik: no objection. If pathces are proposed against osc-placement to add support for the newer versions then please ping me and I will try to review them
14:34:51 viks____ Also if we rescue instance, it asks to set a password, but that also does not work? how to make rescue password work?
14:34:56 stephenfin jkulik: I can't think of one, no
14:35:14 stephenfin We probably have just been forgetting to bump things like we do in novaclient
14:35:34 jkulik ok. I'll propose a patch for the latest versions.
14:35:46 stephenfin jkulik: With that said, adding e.g. 1.29 to that list doesn't really do anything new
14:35:58 stephenfin Unless you implement the functionality of that microversion
14:36:07 jkulik stephenfin: it actually does
14:36:20 jkulik it allows me to query allocation candidates that are in trees
14:36:39 jkulik before, I don't get anything returned. with 1.29, I get the providers like I got on queens btw.
14:36:40 stephenfin Doesn't that require changes to the client?
14:36:50 stephenfin I assume the output from the server is different?
14:37:26 jkulik hm ... looks the same to me. we still have queens around and I compared the output right now.
14:37:49 jkulik having the rocky code-base and an api-version below 1.29 returns nothing anymore.
14:39:42 jkulik https://docs.openstack.org/placement/latest/placement-api-microversion-history.html#support-allocation-candidates-with-nested-resource-providers
14:40:57 jkulik we could™ extend osc-placement to show the new "parent_provider_uuid" and "root_provider_uuid"
14:43:02 gibi jkulik: I think you are correct. the two new things is are those^^ attributesd in the a_c response
14:43:12 gibi the rest is just logic change in the placement server
14:43:24 gibi but no structural change in the input or output
14:51:57 jkulik gibi, stephenfin https://review.opendev.org/c/openstack/osc-placement/+/781749
14:52:52 stephenfin +2 from me
14:55:06 gibi stephenfin: jkulik: gerrit now showed that there is already a patch for 1.29 and it is more widespread change that adds mutliple things that is missing from the client like support for 1.25 adding granular request https://review.opendev.org/c/openstack/osc-placement/+/696251
14:55:46 stephenfin I saw that conflict and skipped over it once I saw 1.25 in the commit message
14:55:49 stephenfin I can review that now
14:56:11 gibi jkulik: do you also need support for 1.25 and so on?
14:57:03 jkulik gibi: 1.26 would be nice, yes
14:58:25 jkulik shall I abandon my request in favor of the exiting one?
15:02:33 gibi I think https://review.opendev.org/c/openstack/osc-placement/+/696251 would be better as it is a more complete solution than just enabling 1.29
15:02:39 stephenfin agreed
15:05:00 jkulik I agree. abandoned my change.
15:23:20 kashyap stephenfin: I blame you for my slow-gaining rST obsession. In my reviews in libvirt rST docs upstream, I began typing out little rST tweaks they could do :D
15:23:42 stephenfin Good :) It's got a learning curve but it is very powerful stuff
15:24:00 stephenfin especially when you introduce extensions
15:24:47 kashyap stephenfin: Yeah, I'm nowhere near your ability to spot all rST problems from a mile away...but still, now I feel like I should tackle this 8000+ line doc
15:24:50 kashyap stephenfin: While you're here:
15:25:23 kashyap stephenfin: Say, a project prefers at most 80 cols of text width. Do you care to adjust pre-formatted and tables which overflow 80 cols?
15:26:20 stephenfin I try to wrap e.g. commands in code-blocks, but only because they don't wrap very well in PDF output
15:26:35 stephenfin but obviously you can't do that for source code snippets
15:26:39 kashyap Right
15:26:54 kashyap stephenfin: A libvirt dev was asking me would you _do_ anything about it
15:26:59 stephenfin Also, you can unusually replace literal tables with e.g. the '.. list-table' directive
15:27:23 kashyap (Where "it" == long code snippets; or other similar pre-formatted stuff)
15:27:24 stephenfin It's not as nice to read in the source, but it's far simpler to prepare and the output is identical
15:27:37 kashyap stephenfin: Ah, nice
15:27:49 stephenfin I'd keep those things as-is, personally
15:27:53 kashyap stephenfin: I didn't know the ".. list-table" directive. Do we have an example of it in our docs?
15:28:02 kashyap stephenfin: Okay, that's what I thought. It's less work too
15:28:20 stephenfin loads of examples, yes
15:28:30 stephenfin doc/source/cli/nova-manage.rst for one
15:29:18 kashyap stephenfin: Thanks. And speaking of extensions, what extensions are recommended? Even if it's your subjective list
15:29:51 stephenfin That's entirely doc specific
15:30:28 stephenfin We use a load of custom ones for things like autodocumenting oslo.policy and oslo.config code that wouldn't make sense outside of OpenStack
15:30:58 kashyap stephenfin: Ah, okay. I'll be modest and fix the obvious stuff for libvirt. I'm just adjusting some secure boot docs in libvirt, hence this chatter here
15:31:01 stephenfin Once you start needing to cross-reference project-unique things or auto-generate some kind of docs, this stuff starts becoming useful
15:31:33 kashyap They recently big-bang convereted HTML to rST an 8000-line file (this one, which we commonly refer to: https://libvirt.org/formatdomain.html)
15:32:00 kashyap With `pandoc`: https://gitlab.com/pipo.sk/libvirt/-/commit/81e494bb5a3c442e875996beaed972904323d3cb
15:32:20 kashyap Ignore the silly GitLab thing in the commit message. It converted :anchor: to ⚓ emoji :D
15:39:33 stephenfin gibi: melwitt: You think we can go ahead with https://review.opendev.org/c/openstack/osc-placement/+/743976 now?
15:39:34 stephenfin I just got asked "why doesn't 'openstack resource provider inventory list' show usage" downstream and was like, aha, I'm not crazy!

Earlier   Later