| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-28 | |||
| 17:32:32 | gibi | :D | |
| 17:32:33 | gibi | yeah | |
| 17:32:35 | gibi | sort of | |
| 17:33:15 | gibi | I hope it is good now as I have to run | |
| 17:33:18 | gibi | talk to you tomorrow | |
| 17:33:26 | mriedem | it's not, but i'll fix it :) | |
| 17:33:47 | gibi | mriedem: OK, thanks :) | |
| 17:33:58 | melwitt | fore | |
| 17:34:08 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_counts() to InstanceMappingList https://review.openstack.org/638072 | |
| 17:34:08 | openstackgerrit | melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351 | |
| 17:34:09 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | |
| 17:34:10 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | |
| 17:34:34 | mriedem | i laugh at your measly 4 patches | |
| 17:35:11 | melwitt | hmph! | |
| 17:35:33 | mriedem | need i remind you https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/cross-cell-resize | |
| 17:35:47 | melwitt | no, I know I can't compete | |
| 17:48:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Record requester in the InstancePCIRequest https://review.openstack.org/625310 | |
| 18:09:34 | mriedem | for people to think about prior to the nova meeting http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003356.html | |
| 18:18:48 | openstackgerrit | Merged openstack/nova master: ironic: partition compute services by conductor group https://review.openstack.org/635006 | |
| 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 | efried | But knowing the full list of things in that space is... hard. | |
| 18:33:01 | aspiers | ah no, stuff outside yellow bubbles is unspecified other stuff, or nothing at all | |
| 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 | 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 | |