)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"76ce1213b183b7ce8772ffcb3a941e2c7da1bc5c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"99c6eac0_125780fb","updated":"2025-09-15 17:55:34.000000000","message":"Again, I\u0027m really confused about how this fits into the full picture -- none of this functionality is described in https://opendev.org/openstack/ironic-specs/commit/aaa37c0fc3ab920dfa8ae2bfe61c3a2de0066f7d\n\nWe don\u0027t usually enforce specs being fully detailed, but in general of the two patches I\u0027ve reviewed so far, it\u0027s difficult to see how they fit into the spec/bug it\u0027s related to. I can see a story developing, but it\u0027s a lot more than just standalone networking.\n\nAm I missing something? Is there a design doc somewhere that I haven\u0027t read, or some additional context?","commit_id":"5c5a55526805df43a2ed90ade9cfe6f0c51db7d5"},{"author":{"_account_id":25437,"name":"Allain Legacy","email":"alegacy@redhat.com","username":"alegacy"},"change_message_id":"1f6fd1376f9d8b36f80bff22a297f253324507eb","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5a3dd09d_049e8521","in_reply_to":"4a1177dd_e092cbce","updated":"2025-09-15 18:26:02.000000000","message":"I hope the spec change clarifies this change.","commit_id":"5c5a55526805df43a2ed90ade9cfe6f0c51db7d5"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"3e50cd65c7dfc388a7c12889aa1377924b629e97","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"4a1177dd_e092cbce","in_reply_to":"99c6eac0_125780fb","updated":"2025-09-15 17:57:47.000000000","message":"Hey, I found review.opendev.org/c/openstack/ironic-specs/+/960550/2/specs/backlog/standalone-networking.rst -- reviewing now","commit_id":"5c5a55526805df43a2ed90ade9cfe6f0c51db7d5"},{"author":{"_account_id":10342,"name":"Jay Faulkner","display_name":"JayF","email":"jay@jvf.cc","username":"JayF","status":"youtube.com/@oss-gr / podcast.gr-oss.io"},"change_message_id":"473a7ce631fb3a3e3c60b5b0b64c89f4396a10e6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"cffbb40f_29f97cec","updated":"2025-09-26 18:10:33.000000000","message":"JFYI going to leave my -1 in place until the spec is merged or has a clear consensus on behavior. Feel free to merge over it if those cases are met and I haven\u0027t removed it.","commit_id":"096f7e658969a5c6c401a6ff0d59aafbea126851"},{"author":{"_account_id":25437,"name":"Allain Legacy","email":"alegacy@redhat.com","username":"alegacy"},"change_message_id":"0b33c0c296735da64b1a10d05f60419fe9acbe6e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"7064cf41_5b9e62ed","updated":"2025-09-26 17:13:59.000000000","message":"recheck","commit_id":"096f7e658969a5c6c401a6ff0d59aafbea126851"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a19a4d702478580b0e4fc36b4569aa0979170b0d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"c9e54f00_a76df712","in_reply_to":"cffbb40f_29f97cec","updated":"2025-09-29 18:56:23.000000000","message":"I think the attempt here is to, overall, institute a model of a default port vlan which is called in this context the introspection network. I think that is fundamentally well meaning, and also misleading naming. I think the base idea is what exists in NGS is \"ngs_port_default_vlan\", which is to explicitly move to back to introspection network.","commit_id":"096f7e658969a5c6c401a6ff0d59aafbea126851"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a19a4d702478580b0e4fc36b4569aa0979170b0d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"37d7399e_5835eadc","updated":"2025-09-29 18:56:23.000000000","message":"I think bringing more clarity here is needed given NGS has a similar idea, but its different, and special casing around introspetion just feels \"weird\".","commit_id":"cddf2ee1993b8f1063f051081d972116f1bb914f"}],"ironic/conductor/cleaning.py":[{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a19a4d702478580b0e4fc36b4569aa0979170b0d","unresolved":true,"context_lines":[{"line_number":317,"context_line":"    task.process_event(event)"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"    # Add inspection network for re-enrollment if configured"},{"line_number":320,"context_line":"    _restore_inspection_network_after_cleaning(task, event)"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"def _restore_inspection_network_after_cleaning(task, event):"}],"source_content_type":"text/x-python","patch_set":6,"id":"3f91a547_e4094671","line":320,"updated":"2025-09-29 18:56:23.000000000","message":"We really need to understand the motivation here, since ideally either introspection always exists as a thing on the default vlan, or the introspection mechanism needs to move the host to the dedicated introspection network.\n\nThis just feels, awkward, at present since it sort of competes to ensure a node may not be on the default vlan out of the box which the node is hopefully restored to upon port detachment.","commit_id":"cddf2ee1993b8f1063f051081d972116f1bb914f"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"31c465f470c9b0c3763dda9a598077fb04d4f353","unresolved":true,"context_lines":[{"line_number":317,"context_line":"    task.process_event(event)"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"    # Add inspection network for re-enrollment if configured"},{"line_number":320,"context_line":"    _restore_inspection_network_after_cleaning(task, event)"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"def _restore_inspection_network_after_cleaning(task, event):"}],"source_content_type":"text/x-python","patch_set":6,"id":"1b52ad41_042dd133","line":320,"in_reply_to":"0d679a45_21c667d0","updated":"2025-09-30 16:57:06.000000000","message":"So we have long known of the chicken and egg problem. We\u0027ve generally taken an approach \"you need to enroll, then inspect, with the starting network or default network being the network used for introspection.\n\nReading this, your wanting to actively assert an attachment when I\u0027d take it as a incorrect/misconfiguration of NGS\u0027s logic to return the node to a default vlan.\n\nI think your assuming that the default vlan configuration related to NGS is akin to just setting it back to \"use vlan 1\", but the logic is to restore the port to an access port of any defined vlan which may be entirely separate from the switch wide configured default/native vlan. Am I interpreting your impression correctly?\n\nI could see a need for it to vary, but that likely should be a more uniform mechanism than just in this spot around introspection. That just feels super awkward to me.","commit_id":"cddf2ee1993b8f1063f051081d972116f1bb914f"},{"author":{"_account_id":25437,"name":"Allain Legacy","email":"alegacy@redhat.com","username":"alegacy"},"change_message_id":"831d00bad73c1e3082f4aa1e3e3807e993b4ff93","unresolved":true,"context_lines":[{"line_number":317,"context_line":"    task.process_event(event)"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"    # Add inspection network for re-enrollment if configured"},{"line_number":320,"context_line":"    _restore_inspection_network_after_cleaning(task, event)"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"def _restore_inspection_network_after_cleaning(task, event):"}],"source_content_type":"text/x-python","patch_set":6,"id":"0cbfda53_e768c54b","line":320,"in_reply_to":"1b52ad41_042dd133","updated":"2025-09-30 17:24:03.000000000","message":"Yes, I understand that the NGS mechanism isn\u0027t /just/ for setting it back to the switch-wide \"default vlan\".  My primary concern with relying on the NGS driver-wide config attribute to do this is that it is driver-specfic logic and other drivers may or may not have a similar option.  My secondary concern is that it doesn\u0027t allow the possibility to change this value on a per-node basis if needed.\n\nIf we want to push that logic down to a driver action... how would you feel if I added an attribute to the reset_port() method on the driver API that I created so that the standalone network driver can pass down the inspection network vlan each and every time a network is removed.  That way the main state machine would not be affected and this would be hidden/buried inside of the standalone network driver?\n\nI think that would work.  I can\u0027t think of a path thru the state machine that would see a node get deleted without a final call to \"remove_*_network(...)\" on the network driver.","commit_id":"cddf2ee1993b8f1063f051081d972116f1bb914f"},{"author":{"_account_id":25437,"name":"Allain Legacy","email":"alegacy@redhat.com","username":"alegacy"},"change_message_id":"3911a0c17cdd12243c8302fe6f7551219954cdac","unresolved":true,"context_lines":[{"line_number":317,"context_line":"    task.process_event(event)"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"    # Add inspection network for re-enrollment if configured"},{"line_number":320,"context_line":"    _restore_inspection_network_after_cleaning(task, event)"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":""},{"line_number":323,"context_line":"def _restore_inspection_network_after_cleaning(task, event):"}],"source_content_type":"text/x-python","patch_set":6,"id":"0d679a45_21c667d0","line":320,"in_reply_to":"3f91a547_e4094671","updated":"2025-09-29 20:10:05.000000000","message":"The motivation is this... To use this feature the node needs ports that have both switch port configuration details (e.g., mode, vlan, etc...) AND switch port identification details (e.g., LLDP info).  The configuration data comes from the user in the form of port.extra.switchport \u003d {...}.  The identification data comes from LLDP (this is better than expecting users to input that 100% correctly). \n\nThis implies that the first thing that needs to happen after a node is enrolled is to inspect it to make sure that we have its LLDP information.  For that to succeed it means that the node\u0027s switch ports must be configured and enabled ahead of time.  That is, we cannot do the initial configuration of those switch ports because it introduces a chicken-and-egg type scenario.  The ports need to be on some VLAN that is routable back to the API for inspection to succeed.\n\nThis also implies that regardless of the path a node takes thru the state machine that it always returns to this initial VLAN when it is deleted so that we have a reasonable expectation a subsequent enrollment + inspection works at some future time.\n\nYes, NGS has a concept of \"default VLAN\", but I don\u0027t like the idea of relying on a driver-specific feature to satisfy a fundamental behavior of the system.  \n\n  1) Other drivers may not have this same notion.\n  2) There may be a need to customize this on a per-node or per-group of nodes basis.  That wouldn\u0027t be possible with a driver feature. \n\nYes, switches themselves do have a concept of default VLAN and if we do nothing and the switch is configured to set the port back to the default VLAN when the port\u0027s native VLAN is removed things will work as long as that default VLAN is routable back to the API.  I don\u0027t think this is ideal because it assumes that the switch is dedicated to this function and that it\u0027s default VLAN will be routable back to the API.  Switch operators may not want to enable this feature and/or may want their actual default VLAN to be locked down and not be routable or switchable outside of the switch.  \n\nI think the best way to deal with this is by explicitly dealing with it in the state machine.  Yes, it is a bit \u0027awkward\u0027, but I believe it to be necessary.   \n\nIf this doesn\u0027t satisfy your concern let\u0027s have a quick call to hash it out.","commit_id":"cddf2ee1993b8f1063f051081d972116f1bb914f"}]}