| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 19:14:55 | aspiers | 1. admin sets a trait | |
| 19:15:03 | efried | uh, except I think those are backwards. | |
| 19:15:24 | efried | ugh, I guess it depends how you're looking at it. | |
| 19:15:45 | aspiers | 2. operator upgrades nova to introduce this patch to the deployment | |
| 19:15:57 | aspiers | 3. nova-compute restarts | |
| 19:16:09 | aspiers | 4. driver does not unset the trait, because it was supposed to be there | |
| 19:16:46 | efried | okay, sure, that's getting off into the weeds and not the point. | |
| 19:16:56 | aspiers | the "will be" statements on this diagram make it span a period of time | |
| 19:17:39 | aspiers | yeah sorry, that wasn't a good illustration | |
| 19:17:43 | efried | Words like "unsupported" and "by the admin" can't be expected to encompass every possible nuance. | |
| 19:18:08 | aspiers | the point is, the values in the capabilities dict are booleans representing whether the capability is supported | |
| 19:18:22 | aspiers | and whether the driver will set or unset the traits depends on those booleans | |
| 19:18:26 | efried | correct | |
| 19:18:44 | aspiers | whereas your text makes it sound like it only depends on whether the traits were previously set by the admin or by the driver | |
| 19:19:05 | aspiers | "if (un)set by admin" is not the correct condition | |
| 19:19:22 | aspiers | "if deemed (un)supported by the driver" is the correct condition | |
| 19:19:28 | efried | Right, this diagram is coming from the assumption that we started in a steady state of capability supported-ness and code level. | |
| 19:19:38 | aspiers | the driver doesn't care who previously set or unset the trait | |
| 19:19:52 | aspiers | whereas the text suggests it does | |
| 19:20:12 | efried | works for me. | |
| 19:20:20 | efried | I feel we've reached the point of diminishing returns here. It has been a useful exercise. Feel free to tweak this diagram/text and paste it off somewhere and use it, or not. | |
| 19:20:35 | aspiers | Agreed | |
| 19:20:43 | aspiers | I think I finally understand what you mean about steady state | |
| 19:20:54 | efried | but for heaven's sake, if you're going to use this diagram, make it pretty with colors like yours. | |
| 19:20:58 | aspiers | LOL | |
| 19:23:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Adds the server group info into show server detail API. https://review.openstack.org/621474 | |
| 19:23:29 | mriedem | alex_xu: i'm +2 on this now ^ | |
| 19:24:25 | openstackgerrit | Chris Friesen proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files https://review.openstack.org/639934 | |
| 19:24:25 | openstackgerrit | Chris Friesen proposed openstack/nova master: Add emulated TPM support to Nova https://review.openstack.org/631363 | |
| 19:30:40 | cfriesen | speaking of runways...could I get another look at https://review.openstack.org/#/c/620706/ ? Alex was supposed to review it again last night but didn't get around to it. | |
| 19:47:51 | cfriesen | mdbooth: you around? not sure what you meant by your comment in https://review.openstack.org/#/c/616692/20/nova/tests/unit/virt/libvirt/test_utils.py | |
| 19:48:11 | aspiers | efried, mriedem: new version https://pasteboard.co/I3iqqNm.jpg | |
| 19:48:32 | aspiers | jaypipes, artom: you might care too | |
| 19:49:00 | aspiers | now I have to make the code actually match the diagram :) | |
| 19:49:51 | artom | aspiers, is that a Venn diagram? It looks like one, but if I try to parse it like it makes no sense | |
| 19:50:00 | aspiers | artom: yes it is | |
| 19:50:57 | artom | aspiers, ah, ok, on second pass it makes more sense | |
| 19:51:34 | jaypipes | aspiers: that is venntastic. | |
| 19:51:43 | aspiers | :) | |
| 19:51:59 | aspiers | almost as venntastic as that pun | |
| 19:52:37 | mriedem | yowser | |
| 19:52:47 | mriedem | if this code ever lands we should probably have that in the docs somewhere | |
| 19:52:52 | openstackgerrit | Chris Friesen proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692 | |
| 19:53:02 | artom | aspiers, how are some COMPUTE_* traits *not* set on RPs? | |
| 19:53:13 | artom | Or did you mean "set on RPs by the admin"? | |
| 19:53:26 | aspiers | artom: if they don't apply? not all traits are set on everything all the time :) | |
| 19:54:04 | artom | Oh, you're using "set" as in actually set, not "capable of being set" | |
| 19:54:09 | aspiers | yes | |
| 19:54:26 | artom | I swear, I dunno what is it about placement | |
| 19:54:28 | aspiers | mriedem: don't scare me with conditional clauses like "if this code ever lands" :-p | |
| 19:54:40 | artom | Every time it's a rabbithole of endless taxonomy and modelling debate | |
| 19:54:56 | melwitt | that diagram is art. and agreed please add it to docs along with patch | |
| 19:55:12 | aspiers | melwitt: where would it belong? | |
| 19:55:19 | artom | aspiers, anyways, yeah, seems to make sense, I'll wait for the code :) | |
| 19:56:27 | melwitt | aspiers: do we have any existing driver capability doc? if so, there. if not, maybe we could make a new doc. and in that case, it could be a follow on patch | |
| 19:56:34 | jaypipes | artom: yes. Nova's NUMA code is much clearer than placement's modeling. | |
| 19:57:23 | aspiers | Now I'm wondering why this diagram attracted so much attention, vs. silence for my other two diagrams in the commit message :) | |
| 19:57:38 | melwitt | would just be nice to capture helpful diagrams like that somewhere | |
| 19:57:50 | aspiers | melwitt: I didn't notice any on a brief scan the other day | |
| 19:57:56 | artom | jaypipes, hah, I'm not saying the code is bad | |
| 19:57:57 | melwitt | well, I happened to click on this one and haven't read your commit message yet | |
| 19:58:07 | aspiers | melwitt: I also made https://pasteboard.co/I25qICd.png | |
| 19:58:17 | artom | jaypipes, I'm observing that placement monopolizes discussions every time it's brought up | |
| 19:58:29 | artom | Even in our RH team call this morning | |
| 19:59:20 | aspiers | melwitt: yeah, I was wondering more about the people who *have* already reviewed it ;-) | |
| 20:00:56 | melwitt | aspiers: heh. well, it's not _that_ important about the diagrams, just a general sentiment of, it would be nice if we had more pictures in our docs for features we have. and since you already made those. another thing to throw on the TODO list | |
| 20:01:35 | aspiers | melwitt: agreed, happy to add to docs. I would have already included in the review if I had found a good place for them | |
| 20:01:51 | jaypipes | aspiers: I haven't reviewed the patch yet. | |
| 20:02:06 | jaypipes | aspiers: been languishing in my endless review queue... | |
| 20:02:07 | efried | aspiers: You still have another rev forthcoming, though, right? | |
| 20:02:10 | jaypipes | apologies. | |
| 20:02:28 | melwitt | aspiers: yeah. don't worry much about it, just another TODO for the pile of neverending TODOs :) | |
| 20:02:46 | aspiers | jaypipes: no worries ;) | |
| 20:02:51 | aspiers | efried: yes, working on it right now | |
| 20:03:15 | efried | cool | |
| 20:03:23 | aspiers | efried: I was planning to fix the issues, then submit, and only then rebase and submit again, to keep rebase changes in a separate patchset | |
| 20:03:26 | aspiers | makes sense? | |
| 20:03:45 | efried | aspiers: ++, hate having to review rebase+updates in same PS. | |
| 20:04:02 | aspiers | efried: one day we will not have to worry about that any more | |
| 20:04:14 | aspiers | o/~ one day ... o/~ | |
| 20:04:18 | efried | yeah, it wasn't long ago that the rebase PS would include all the files from the rebase. | |
| 20:04:30 | efried | ...from all the intervening commits | |
| 20:04:37 | efried | so where we are now is at least an improvement on that. | |
| 20:05:12 | aspiers | well, "long ago" depends very much on whether you are using the timeline of our Gerrit deployments, or the upstream Gerrit releases ;-) | |
| 20:05:31 | aspiers | but yeah, I know you meant the former | |
| 20:05:52 | aspiers | I kinda want to volunteer for the infra team *just* to get us on 2.16 | |
| 20:05:57 | aspiers | but I don't have time :-( | |
| 20:07:21 | aspiers | melwitt: would it go under "Nova Major Subsystems"? https://docs.openstack.org/nova/latest/contributor/index.html | |
| 20:07:52 | aspiers | a new doc called "resource provider trees" or something like that? | |
| 20:12:21 | melwitt | aspiers: yeah, AFAIK, we don't have any nova docs about traits yet. is it only useful to nova contributors or to more ppl? if it's more, then it wouldn't be under contributor/ | |
| 20:12:58 | aspiers | melwitt: I think some would, some wouldn't - depends on whether it's internals | |
| 20:13:31 | aspiers | IMHO this Venn diagram is borderline either way | |
| 20:13:52 | aspiers | I could do a more user-facing version | |
| 20:14:20 | melwitt | no, I think it's ok, was just sanity checking. I think a new subsystem doc would make sense, like you suggested | |
| 20:15:59 | aspiers | melwitt: any ideas about the title? | |
| 20:16:22 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640181 | |
| 20:16:23 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-grenade-live-migration voting and gate https://review.openstack.org/640182 | |
| 20:17:05 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make nova-grenade-live-migration voting and gating https://review.openstack.org/640182 | |
| 20:17:54 | mriedem | flavors docs talked about traits https://docs.openstack.org/nova/latest/user/flavors.html | |
| 20:18:09 | mriedem | so you'd likely want some reference to how system-driven traits and user-driven traits overlap | |