| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 18:44:33 | aspiers | ok, let me try to tweak the diagram based on all this | |
| 18:44:35 | aspiers | give me a few mins | |
| 18:46:07 | efried | I think a different angle on your venn diagram would be for everything in the bubbles to be traits; then a bubble within that would be compute-owned traits; then a bubble that overlaps the border of compute-owned would be "traits that are switched on". | |
| 18:46:38 | aspiers | originally it was all traits | |
| 18:46:53 | aspiers | but then I wanted to put capabilities on there to show that not all capabilities get mapped to traits | |
| 18:47:05 | efried | yeah, that can be done. | |
| 18:47:19 | efried | I don't have a drawing program handy, gr. | |
| 18:47:40 | aspiers | this is in google drawings, so you do | |
| 18:47:49 | aspiers | in fact you can even help me fix it in real-time :) | |
| 18:49:29 | aspiers | there's not much to learn :) | |
| 18:51:25 | efried | I started drawing circles and can't figure out how to get them to be transparent. Off to a good start. | |
| 18:52:28 | mriedem | jroll: rebase? https://review.openstack.org/#/c/636326/1 | |
| 18:55:13 | aspiers | haha | |
| 18:55:24 | efried | aspiers: combine top two middle bubbles? | |
| 18:55:46 | aspiers | oh yeah, could do | |
| 18:56:08 | aspiers | well | |
| 18:56:13 | efried | "Compute-owned custom/standard traits" | |
| 18:56:23 | aspiers | the point was to emphasise that there can be standard traits not from capabilities | |
| 18:56:31 | aspiers | If we combine them, this point is not nearly as clear | |
| 18:56:48 | efried | okay. | |
| 18:57:10 | aspiers | I'll export to pasteboard.ca and update the commit message | |
| 18:57:13 | efried | what this diagram still lacks is the concept of *unsetting*. | |
| 18:57:23 | aspiers | hrm | |
| 18:57:57 | efried | So a yellow bubble is a set of traits, but incorporates them being set or unset on the provider. | |
| 18:57:57 | aspiers | True, it also conflates providing traits with owning them, which is the other side of the same coin | |
| 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 | 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 | |