| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 18:57:13 | efried | what this diagram still lacks is the concept of *unsetting*. | |
| 18:57:23 | aspiers | hrm | |
| 18:57:57 | aspiers | True, it also conflates providing traits with owning them, which is the other side of the same coin | |
| 18:57:57 | efried | So a yellow bubble is a set of traits, but incorporates them being set or unset on the provider. | |
| 18:58:24 | efried | how did you make your bubbles transparent? | |
| 18:58:40 | aspiers | I don't think they are | |
| 18:58:53 | efried | ah, found it. | |
| 18:58:54 | aspiers | Oh, the big ones | |
| 18:58:59 | aspiers | Yeah, custom colour | |
| 18:59:03 | efried | Well, otherwise you can't see the overlap - yeah | |
| 19:00:38 | aspiers | Urgh, this could get way more complicated if we distinguish set from unset | |
| 19:00:53 | aspiers | we have to double the number of small bubbles | |
| 19:01:06 | aspiers | trait bubbles, at least - not the caps ones | |
| 19:01:29 | aspiers | not sure it's worth the effort | |
| 19:01:35 | aspiers | for an image in a commit message | |
| 19:01:49 | aspiers | this was mainly to check my understanding and ensure we're on the same page | |
| 19:01:57 | aspiers | which I think we are | |
| 19:03:30 | efried | aspiers: Yeah, I don't think we have to get this perfect | |
| 19:03:39 | efried | aspiers: And we don't have to combine all those concepts in the same diagram. | |
| 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 | all capability traits are standard traits | |
| 19:09:13 | efried | all capability traits are owned by compute | |
| 19:09:13 | efried | not all capability traits are set at any given time | |
| 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 emulated TPM support to Nova https://review.openstack.org/631363 | |
| 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: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 | |