| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 18:24:29 | aspiers | efried, mriedem: is this the new understanding? https://pasteboard.co/I3hSwZ5.jpg | |
| 18:25:31 | efried | aspiers: couple things... | |
| 18:26:40 | efried | CUSTOM_ traits owned by drivers are not deprecated (did you mean "discouraged"?). There will always be custom traits for things that are dynamic in nature. To use an example that some people hate, CUSTOM_<PCI_ADDRESS> | |
| 18:27:02 | aspiers | gotcha, I didn't know about those | |
| 18:29:07 | efried | aspiers: When you include the bottom middle bubble in the "things manipulated by admin", you mean that it's *possible* for them to muck with it, but they shouldn't, and we'll "heal" it, per your note at the top. | |
| 18:29:23 | aspiers | right | |
| 18:29:34 | aspiers | I'll clarify that | |
| 18:31:07 | efried | Cool. | |
| 18:31:08 | efried | The only other note is use of the word "never" on the right hand side. The top two middle bubbles are supposed to be "exclusive" - i.e. traits that are owned by the driver are a *subset* of the traits the driver will actually *set*. | |
| 18:31:38 | efried | aspiers: So like, I'm not sure if you did this on purpose, but the space in the intersection of the big bubbles, but outside of the three middle bubbles, is that set. | |
| 18:32:26 | efried | ...assuming that yellow bubbles are things that are set, and stuff outside of yellow bubbles is things that are unset. | |
| 18:32:43 | efried | Now in theory, the driver will "always" know what's in that set, and "always" switch off a trait from that set if the admin switches it on. | |
| 18:33:01 | aspiers | ah no, stuff outside yellow bubbles is unspecified other stuff, or nothing at all | |
| 18:33:01 | efried | But knowing the full list of things in that space is... hard. | |
| 18:33:13 | efried | okay, then does what I'm saying above make sense? | |
| 18:33:21 | aspiers | my brain hasn't grokked it yet | |
| 18:33:25 | aspiers | give me a few secs :) | |
| 18:34:09 | efried | There's a set of traits the driver owns. A subset of that will be turned on (by the driver). Anything in there that's turned on by the driver, and turned off by the admin, will get turned back on. Conversely, anything in there that's *not* turned on by the driver, but turned on by the admin, is *supposed* to be switched back off by the driver. | |
| 18:34:13 | aspiers | hrm, you are saying the driver will set traits which it *doesn't* own? | |
| 18:34:46 | efried | no, I'm saying it will switch *off* traits that it *does* own but doesn't think *should* be on. I.e. same logic as for the capability traits. | |
| 18:35:26 | efried | but I have low confidence that drivers will succeed in doing that with 100% accuracy. | |
| 18:37:51 | aspiers | Still not sure I understand. Is your point that outside of the new caps->traits code, there are other driver-owned traits for which the driver *should* override admin changes, but currently might not? | |
| 18:37:58 | efried | What we really ought to do is come up with a namespacing convention so that this ^ can be done more accurately. E.g. compute is allowed to switch off anything set by the admin that's [CUSTOM_]COMPUTE_*. And conversely, compute has to leave alone anything not in that namespace that the admin sets. | |
| 18:38:17 | efried | aspiers: Well, yes, "currently might not" because bug, not by design. | |
| 18:39:57 | efried | A pedantic example: Let's say compute decorates a pGPU provider with CUSTOM_PCI_ADDRESS_00_01_02_03. Obviously it should be nonsensical for the admin to decorate the same RP with a trait like CUSTOM_PCI_ADDRESS_FF_AA_BB_CC. So compute should notice that second one and switch it off. | |
| 18:40:09 | efried | but how will it know? | |
| 18:40:24 | aspiers | right, that makes a lot more sense with a concrete example | |
| 18:40:43 | efried | namespacing on every possible infix like _PCI_ADDRESS_ would be craziness. Hence the need for namespacing of some kind. But we don't have that convention in place yet. | |
| 18:40:56 | efried | I guess we'll burn that bridge when we cross it. | |
| 18:41:16 | aspiers | so technically my note with the arrow currently only refers to some of the things in the intersection of the two big bubbles, not all of them | |
| 18:41:49 | aspiers | so not the top middle yellow bubble for a start | |
| 18:42:06 | efried | but it's a correct theory :) | |
| 18:42:28 | aspiers | right, it's describing what *should* happen but not what the patch achieves | |
| 18:42:51 | efried | What this patch achieves is the above philosophy for capability-based standard traits only | |
| 18:43:06 | efried | ...which, by the way, are namespaced COMPUTE_* :) | |
| 18:43:27 | efried | (though probably not with as much intent as I've described) | |
| 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 | 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 | |