| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 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 | 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. | |