| opendevreview | Kaifeng Wang proposed openstack/ironic master: Direct return of vmedia action during in power failure https://review.opendev.org/c/openstack/ironic/+/958147 | 02:14 |
|---|---|---|
| opendevreview | Kaifeng Wang proposed openstack/ironic master: Direct return of vmedia action during in power failure https://review.opendev.org/c/openstack/ironic/+/958147 | 08:37 |
| *** jroll06 is now known as jroll0 | 09:03 | |
| opendevreview | cid proposed openstack/ironic-python-agent master: WIP: Type annotations and checking https://review.opendev.org/c/openstack/ironic-python-agent/+/958333 | 14:34 |
| cardoe | TheJulia: Yeah I'm a BIG -1 on that change to add physical_network to a PortGroup. I think that field needs to be inherited from the Port. | 15:30 |
| opendevreview | Verification of a change to openstack/ironic master failed: No admin-set maintenance override on power sync https://review.opendev.org/c/openstack/ironic/+/956993 | 15:40 |
| opendevreview | Doug Goldstein proposed openstack/ironic master: redfish: change inspection to behave like out of band https://review.opendev.org/c/openstack/ironic/+/957609 | 16:14 |
| JayF | cardoe: that is not what was reflected in the spec. If we need to make it inherited, we should publish an update to that spec to make sure we're all on the same page about where we're going. I don't want Clif to have to rewrite more patches because we didn't pay close enough attention to the spec | 16:23 |
| cardoe | Well we've already deviated from the spec in a few places. | 16:27 |
| cardoe | So I agree the spec needs an update already. | 16:27 |
| cardoe | e.g. the names of all the fields are different and the data that can be stored in one field is slightly different | 16:28 |
| cardoe | That was actually a question I had on a previous patch that I couldn't find how this change related to the spec. | 16:30 |
| cardoe | Definitely interested in seeing this happen. Cause dynamically creating a portgroup is something I have requests for today. Cause some users don't want LACP and some users do. But I've got to tag physical_network on our ports to make sure the right ones get used for the right traffic. So I need that to bubble up to the PortGroup as well so the correct scheduling happens. | 16:34 |
| JayF | I just wanna make sure we are on the same page for something this important | 16:41 |
| cardoe | So let's walk through it. | 16:43 |
| cardoe | The physical_network needs to match for the attach_vif flow with the Neutron network. | 16:43 |
| cardoe | So since they're independent fields, we need to have API to let you update the physical_network field on the PortGroup and on the Port. | 16:44 |
| JayF | Not on a Saturday morning at 9:45 | 16:44 |
| JayF | I'm happy to process this async later if you want to put it in now, but I'm not in the right headspace to think through it to that level | 16:44 |
| cardoe | I attempt to use the trait based scheduling and one Port is physical_network bob_net and one Port is physical_network alice_net but then I want a dynamic PortGroup created. So are we doing a constraint to ensure that the dynamically created PortGroup only contains ports with a matching physical_network? Where's the value for the PortGroup set from? | 16:46 |
| cardoe | 100% async. 110% async when its the weekend. ;) | 16:46 |
| cardoe | So now we're not doing dynamic PortGroups let's say and I create a PortGroup and set physical_network to the Port with physical_network bob_net but then I'm allowed to set the PortGroup's physical_network to alice_net. | 16:47 |
| cardoe | How is attach_vif gonna do the right thing in those cases? | 16:47 |
| TheJulia | I think the intent is sort of the same, but to dual use it. I'm sort of also okay with that, but I think we need to lean *hard* towards defaulting based upon composited ports | 17:02 |
| TheJulia | OR it needs to be "fabric" and freeform, or something. Same basic idea as a physical network but yeah | 17:03 |
| TheJulia | and maybe its all okay if the end intent is identical. I can't keep that all in my head right now, but async + maybe chatting on monday might make me feel way better :) | 17:03 |
| JayF | I think really we're not talking about architectural differences so much as maybe needing more guardrails than we explicitly laid out | 17:08 |
| JayF | I also am not 100% sure it would be a correct reflection of the real world if we said that a port group always exists in the same physical Network the individual ports do. | 17:11 |
| cardoe | Agreed on the guardrails. I'd be curious to hear the case when the physical_network constraint isn't true. | 18:56 |
| cardoe | Cause I'd like to add that example to the spec for our future selves. | 19:04 |
| opendevreview | Merged openstack/ironic master: No admin-set maintenance override on power sync https://review.opendev.org/c/openstack/ironic/+/956993 | 19:04 |
| cardoe | ^ that test hit a funky race condition. it said the node was locked and failed but a recheck worked. | 19:05 |
| TheJulia | JayF: I concur, although I'd really like to understand the cases where physical networks could be different then the ports themselves. It all goes back to the meaning of "physical_network" and do we want it to be the same, or different or is it an entirely different context with a similar name for humans to map to | 19:24 |
| JayF | yeah, if physical_network *100% of the time* means "I'm plugged into switch lol123ab" then it wouldn't make sense; I just thought there might be some edge somewhere around "this PORT when used as a port is in 'storage-slow'" "this PORTGROUP is in 'storage-fast' when a portgroup" | 19:32 |
| JayF | my todo around this for monday starts with shoring up my mental model of that; I just need to reabsorb more of the context | 19:33 |
| TheJulia | JayF: more like, switch fabric lol123ab | 19:52 |
| TheJulia | I'd expect the physnets to be delineated in general for that, but yeah | 19:52 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!