| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 19:03:50 | efried | I just shared you the one I'm doing that just has the set/unset concept. | |
| 19:03:58 | efried | it's not as pretty as yours. | |
| 19:04:09 | aspiers | checking | |
| 19:04:42 | efried | so the way to read this is: all capability traits are owned by compute; some are set and some are not. | |
| 19:04:58 | efried | Of *all* traits owned by compute, some are set and some are not | |
| 19:05:11 | efried | Of all traits that are set, some are compute-owned and some are not. | |
| 19:06:00 | jroll | mriedem: does it need it? | |
| 19:06:58 | efried | jroll: yah | |
| 19:07:01 | jroll | oh you're right | |
| 19:07:09 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: Ironic: bump minimum API version to 1.38 https://review.openstack.org/636326 | |
| 19:07:23 | jroll | in the future, anyone is welcome to push the rebase button for me :P | |
| 19:08:30 | efried | aspiers: a bit busy with that last addition, but I think it's right | |
| 19:09:13 | efried | not all capability traits are set at any given time | |
| 19:09:13 | efried | all capability traits are owned by compute | |
| 19:09:13 | efried | all capability traits are standard traits | |
| 19:12:16 | aspiers | efried: I disagree with your most recent edit | |
| 19:12:42 | aspiers | efried: if the admin sets a trait, then it becomes supported, the driver will not unset it | |
| 19:12:52 | aspiers | efried: and if the admin unsets a trait, then it becomes unsupported, the driver will not set it | |
| 19:13:03 | aspiers | I think my previous text was more accurate | |
| 19:13:32 | efried | "becomes unsupported" - this is a snapshot | |
| 19:14:02 | efried | things becoming (un)supported or becoming standard etc. simply move the lines; they don't change the semantics. | |
| 19:14:36 | aspiers | I'm not sure you got the point | |
| 19:14:48 | aspiers | there are other scenarios, e.g. | |
| 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? | |