| opendevreview | Jacob Anders proposed openstack/ironic master: Refactor firmware update SimpleUpdate submission and error dispatch https://review.opendev.org/c/openstack/ironic/+/999230 | 00:33 |
|---|---|---|
| opendevreview | Jacob Anders proposed openstack/ironic master: Unify non-BMC firmware updates under batched state machine https://review.opendev.org/c/openstack/ironic/+/999720 | 00:33 |
| opendevreview | Jacob Anders proposed openstack/ironic master: Document batched firmware updates and add release note https://review.opendev.org/c/openstack/ironic/+/999721 | 00:33 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: Add Cisco NDFC REST API driver for VXLAN L2VNI https://review.opendev.org/c/openstack/networking-generic-switch/+/968484 | 00:55 |
| opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: Add multicast BUM replication support to NDFC driver https://review.opendev.org/c/openstack/networking-generic-switch/+/984815 | 00:55 |
| opendevreview | Steve Baker proposed openstack/ironic master: Start Xvfb and pass running display to x11vnc https://review.opendev.org/c/openstack/ironic/+/1001274 | 03:01 |
| opendevreview | Merged openstack/virtualbmc master: bindep: Remove stale marker https://review.opendev.org/c/openstack/virtualbmc/+/999517 | 07:52 |
| opendevreview | Takashi Kajinami proposed openstack/networking-baremetal master: ruff: Fix outdated target-version https://review.opendev.org/c/openstack/networking-baremetal/+/1001464 | 08:09 |
| kubajj | Good morning Ironic! o/ | 08:29 |
| rpittau | hey kubajj :0 | 08:33 |
| opendevreview | Esther Domfeh proposed openstack/ironic master: Expose new node history fields in API v1.115 https://review.opendev.org/c/openstack/ironic/+/1001182 | 10:39 |
| opendevreview | Esther Domfeh proposed openstack/ironic master: Expose new node history fields in API v1.115 https://review.opendev.org/c/openstack/ironic/+/1001182 | 10:51 |
| opendevreview | Jacob Anders proposed openstack/sushy master: Fix virtual media boot on Quanta QuantaEdge EGN77C-2U https://review.opendev.org/c/openstack/sushy/+/1000408 | 11:42 |
| opendevreview | Jacob Anders proposed openstack/sushy master: Fix virtual media boot on Quanta QuantaEdge EGN77C-2U https://review.opendev.org/c/openstack/sushy/+/1000408 | 11:56 |
| TheJulia | good morning | 13:29 |
| cardoe | TheJulia: don't assume how my morning is going! | 13:32 |
| TheJulia | cardoe: I have a sinus infection, can I guess?! | 13:32 |
| cardoe | well that's less than fun | 13:42 |
| TheJulia | Yeah, I need to see if I can get a dr appt | 13:43 |
| TheJulia | or something :( | 13:43 |
| dtantsur | Oh, get better TheJulia! | 14:42 |
| opendevreview | Esther Domfeh proposed openstack/ironic master: Expose new node history fields in API v1.115 https://review.opendev.org/c/openstack/ironic/+/1001182 | 15:30 |
| frickler | there are people here who enjoy fancy workarounds for broken hardware, right? ;) https://review.opendev.org/c/openstack/ironic-python-agent/+/1001323 | 15:45 |
| cardoe | dtantsur: if ya get a sec... https://review.opendev.org/c/openstack/ironic/+/986702 | 16:00 |
| TheJulia | I'm not sure I'd call it broken hardware, if the firmware is seeking to enforce a security freeze of the device :\. It sure is an interesting door to drive functionality through | 16:04 |
| TheJulia | security freeze and semi-functional is also... "weird" to me | 16:05 |
| dtantsur | cardoe: W+1 with comments, nice job! | 16:15 |
| dtantsur | Folks, is it fair to say that ironic-networking JSON RPC is another integration point for, say, proprietary networking solutions? Or do we want to steer folks away from this path? | 16:16 |
| cardoe | if ya got better wording on the scale piece lemme know... I really don't want to talk about scaling in this doc and want to link out to the scaling doc ultimately. | 16:16 |
| dtantsur | I don't really, this is why I still approved it.. getting the words right is not my strength | 16:16 |
| JayF | dtantsur: I suspect any such integration would be more cleanly done directly into a network_interface | 16:18 |
| JayF | dtantsur: I would default to -0.5 for any misdirection using the ironic-networking defined API | 16:18 |
| dtantsur | JayF: kind of my gut feeling. Except that Python may be a bit of an issue there, and I don't know to which extent I want random people writing Ironic plugins that I later have to maintain... | 16:19 |
| TheJulia | I'd almost prefer a more formalized driver interface if someone wants another backend, mainly from the standpoint of having known/modeled flows and exception handling if there are issues. That feels like we should discourage people trying to write parallel json-rpc endpoints for networking, but I guess I can sort of see a why in there, but it would still be best to tease apart. | 16:21 |
| dtantsur | And what about "bring your own shell scripts" interfaces? or "poke operator-provided URL" ones? | 16:22 |
| JayF | I have proposed "external" interface implementations elsewhere before | 16:22 |
| JayF | it's a good idea but we just have to be able to close the loop (e.g. it can't be fire and forget; it needs to be fire-and-verify) | 16:23 |
| cardoe | Doesn't ironic-networking already use NGS? | 16:23 |
| dtantsur | Yeah, I feel like we've been discussing this topic | 16:23 |
| dtantsur | cardoe: that's the only thing that it actually supports | 16:23 |
| dtantsur | some downstream folks want netris... | 16:23 |
| JayF | cardoe: dtantsur is suggesting having ironic-networking have a backend to $otherNetworkManagementSystem | 16:23 |
| cardoe | There's many companies / orgs that have written their own NGS replacement. | 16:23 |
| * dtantsur nods | 16:24 | |
| cardoe | Yeah and TheJulia even has patches to use that same API surface to talk to Cisco network management system | 16:24 |
| cardoe | Replace NGS with your own backend | 16:24 |
| TheJulia | That i do! | 16:24 |
| TheJulia | I think the bottom line is *everyone* does their own thing and we can't expect people to lock in to any given path | 16:25 |
| cardoe | You're gonna have to do integration work somewhere. Just use an existing tested API surface that has multiple implementers both upstream and downstream. | 16:25 |
| TheJulia | options/capabilities/models is the key | 16:25 |
| cardoe | Let's not try and write another API surface that we have to conform to. | 16:25 |
| TheJulia | Which takes me back to the "would you guys have an issue" discussion last week and dmitry's response was "as the author of the model, I approve" | 16:25 |
| TheJulia | cardoe: yeah, and sort of do the needful that makes the most sense in each case | 16:26 |
| JayF | cardoe: that's what I think saying "ironic-networking is the API surface" does | 16:26 |
| JayF | cardoe: we have an API surface we support with deprecation: network_interface | 16:26 |
| cardoe | We're deprecating network_interface? | 16:27 |
| TheJulia | I don't think so | 16:27 |
| JayF | No, but if we promote use if ironic-networking's JSON RPC API as an integration point | 16:27 |
| JayF | we've now got *two* places where we are doing API support with deprecation rules in place | 16:27 |
| TheJulia | So here is the crux of the problem | 16:27 |
| TheJulia | every model is opinionated | 16:28 |
| TheJulia | so, at some level it is "flow of management" | 16:28 |
| TheJulia | and what do the style of plugs look like | 16:28 |
| TheJulia | Are we using C13, or C14, or Is the EU style Plugs, or is it Japanese style plugs? | 16:28 |
| TheJulia | same basic challenge, the plugs are also disjointed from the flow/model | 16:29 |
| JayF | I just don't want one of those interfaces where the plugs fit, but there's mismatched voltage ;) | 16:29 |
| TheJulia | so neutron has a distinct model, two network interfaces, ironic-networking is more authoritative and might work in some cases with factors, but not others, so the question is teasing out the higher level | 16:29 |
| TheJulia | JayF: exactly, we have to ensure the voltage is matched or is able to be handled | 16:29 |
| TheJulia | also, frequency, but yeah, same basic concept | 16:30 |
| cardoe | I'd like to propose another standard... metal prongs sticking out of the wall which are always live... https://xkcd.com/927/ | 16:30 |
| JayF | maintaining more interfaces hertz more and more over time | 16:30 |
| TheJulia | (Japan wins flexability, 50hz and 60hz dependin gon what part of japan your in) | 16:30 |
| JayF | we need to make sure we stay grounded | 16:30 |
| * TheJulia is glad electrical analogies have taken hold | 16:30 | |
| dtantsur | lol | 16:31 |
| JayF | I just don't think we need to direct current users of networking_interface to something that's still being baked ;) | 16:32 |
| dtantsur | What I'm hearing is that people should rather plug into NetworkInterface or SwitchDriver, but not in the RPC layer | 16:32 |
| JayF | dtantsur: I am speaking 100% from the standpoint of: I don't want to maintain more API integration points for networking. I do think it's possible/likely that we could do something like AgentBaseMixin for network_interface though | 16:32 |
| TheJulia | I'd sort of prefer that, but we're open to dialog and ensureing there is a solid reference ground | 16:33 |
| JayF | dtantsur: saying the integration point is at *_interface doesn't preclude them sharing schemas or approaches, we have history for that in deploy_interface | 16:33 |
| dtantsur | Yeah, I don't insist on anything. I'm exploring the ground to be able to provide an opinion that is not solely based on my gut feelings. | 16:33 |
| TheJulia | dtantsur: that is very wise | 16:33 |
| JayF | yeah like I think if there's value in ironic-networking's schemas/api models/etc that it might be cleaner to make those reusable at network_interface level rather than making it pluggable at a second level | 16:34 |
| JayF | then you could have like, ironic-networking and otherbs-networking side by side, and maybe even with compatible local_link_connection schemas | 16:34 |
| dtantsur | I mean, we already have a SwitchDriver, that could be a way forward | 16:35 |
| TheJulia | yup | 16:35 |
| TheJulia | I think the answer is to ensure there is model alignment and not to jump to conclusion | 16:35 |
| cardoe | fwiw, our NGS replacement is effectively doing JSON-RPC... I've toyed with the idea of nailing down the receiver side API and publishing it. | 16:35 |
| TheJulia | because... you can assume your ground is solid, but your ground may be lower resistance than the neighboring building's ground. | 16:35 |
| dtantsur | I suspect it won't be realistic to ask these particular people to write a NetworkInterface. Too much of internals that need understandings, and I don't want to be the one hand-holding them. | 16:35 |
| * TheJulia has quite literally had a 40-45 ohm resistance difference between two buildings which were next to each other. | 16:36 | |
| cardoe | There's a lot of complicated cases here dtantsur that I don't think you've gotten into yet. | 16:36 |
| * TheJulia can keep talking about grounding if needed | 16:37 | |
| cardoe | like trunk ports and bonding | 16:37 |
| dtantsur | cardoe: I'm afraid you're very right... | 16:37 |
| cardoe | and DHCP handling | 16:37 |
| cardoe | So a simple update_port_postcommit() handler that NGS does today is too naive for our case right now. | 16:37 |
| TheJulia | and if the operator cares about those, or not | 16:37 |
| cardoe | Well yes exactly. | 16:37 |
| TheJulia | and some of that needs to be understood by ironic itself | 16:37 |
| TheJulia | Super hard to model one way to model it *all* | 16:38 |
| TheJulia | Anyway, that discard RFE! | 16:39 |
| TheJulia | I sort of like it | 16:39 |
| TheJulia | (considering, we pondered doing that before there was a CLI command to do exactly that | 16:39 |
| TheJulia | ) | 16:39 |
| cardoe | dtantsur: I'll throw out a fun one... neutron calls it routed networks... but type-5 connectivity where your provisioning network for example isn't in a flat broadcast domain... now you've gotta touch something else to have DHCP working for IPA | 16:40 |
| opendevreview | Merged openstack/ironic master: docs: add deployment scenarios and user personas guide https://review.opendev.org/c/openstack/ironic/+/986702 | 16:40 |
| cardoe | So we cannot just use NGS because it only cares about that ONE port for the server being touched. It's not gonna emit context about the DHCP config necessary. | 16:41 |
| cardoe | But our $otherNetworkManagementSystem needs to receive that context to wire that up. | 16:42 |
| dtantsur | Ugh. Do you think any of this can be moved upstream? | 16:42 |
| cardoe | Maybe? I've got it on my TODO (along with a lot of other stuff) to evaluate others and see if we could come up with a generic JSON-RPC NGS like thing. | 16:44 |
| cardoe | I've floated it out before as NGS 2.0 | 16:44 |
| cardoe | Where there's an NGS agent which implements a defined API for JSON-RPC and the NGS 2.0 plugin sends that. | 16:44 |
| cardoe | And folks can implement their own agent that conforms to that JSON-RPC contract. | 16:45 |
| cardoe | Much like what JayF's calling the AgentBaseMixin | 16:45 |
| cardoe | But it's not much more than a scribble on the corner of my dry erase board. | 16:45 |
| JayF | I like a lot of the side effects of that: separate [config_categories] per driver, preserve existing dynamic behavior around network_interface (no hidden static config telling ironic-networking what to network) | 16:46 |
| cardoe | TheJulia: discard RFE... for the IPA for disk erase? | 16:46 |
| JayF | it's one of those cases where you want *code* to be DRY but you want *config* to be enumerated per-each-variant | 16:46 |
| cardoe | Exactly | 16:46 |
| cardoe | It needs smart folks that are interested and have free cycles to brain through it and do it. | 16:47 |
| TheJulia | cardoe: yeah, basically if we can't secure erase it tries to fallback to discard, but its a bit of a limited case in the code pattern | 16:49 |
| JayF | I am not sure I love the idea of automatically circumventing a security locked drive | 16:49 |
| JayF | for that IPA erase | 16:49 |
| TheJulia | The interesting thing is it is a controller driven locked device | 16:49 |
| TheJulia | so no way to unlock it, but its still usable | 16:49 |
| JayF | I'm thinking 100% from a perspective of "is this safe as default behavior" | 16:50 |
| JayF | I agree it's useful in some cases, seemingly, but I'm just unsure if it should be a default-enabled behavior | 16:50 |
| TheJulia | I could see a knob being super reasonable | 16:50 |
| TheJulia | fwiw, I do like the general approach as an additive fallback to attempt a blkdiscard | 16:52 |
| dtantsur | It sounds like at some point we need something like accepted_erase_methods to replace all these knobs | 16:56 |
| JayF | the only current knobs we have are if you change the steps you run by default, yeah? | 17:00 |
| JayF | e.g. erase_devices_metadata -> erase_devices_for_realsies :D | 17:00 |
| TheJulia | yeah, this is all under the hood of erase_devices and the default flow | 17:01 |
| TheJulia | and to be honest, discard *can* work for non-SATA devices as well, its in the later SCSI/SAS/FC revisions. | 17:03 |
| opendevreview | Esther Domfeh proposed openstack/python-ironicclient master: Add new fields to node history detailed view https://review.opendev.org/c/openstack/python-ironicclient/+/1000705 | 17:05 |
| TheJulia | it would be cleaner in the end to also stepwise iterate through the list in order as well, nvme erase being the big oddity | 17:07 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: Make AutoDetectDeploy act more consistently https://review.opendev.org/c/openstack/ironic/+/1000074 | 19:47 |
| cardoe | JayF: you had my +1 at consistency | 20:20 |
| TheJulia | heh | 20:25 |
| JayF | if your +1 is based on the commit message alone then we're all in trouble | 20:25 |
| JayF | you can assume an implied (trying to) at the head of all my commit titles lol | 20:25 |
| cardoe | I was making the joke off the commit message alone but I will review it. | 20:30 |
| JayF | I was making the joke off the fact I know I'm operating at the edges of my context in that change lol | 20:32 |
| JayF | sometimes those changes feel like you're trying to plug up 14 holes with 10 fingers lol | 20:32 |
| opendevreview | Merged openstack/ironic master: Deprecate list-style args for inspection rule operations https://review.opendev.org/c/openstack/ironic/+/1000007 | 21:15 |
| opendevreview | Merged openstack/ironic master: Document inspection rule operation arguments explicitly https://review.opendev.org/c/openstack/ironic/+/1000008 | 21:15 |
| opendevreview | Julia Kreger proposed openstack/ironic master: devstack: Fix multinode CI failures with unreachable API endpoint https://review.opendev.org/c/openstack/ironic/+/1001575 | 21:17 |
| TheJulia | claude and I are thinking the above should fix "fix" the sporatic standalone job failures | 21:18 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!