)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":35233,"name":"Adam Rozman","email":"adam.rozman@est.tech","username":"rozzix"},"change_message_id":"5c336a3956888c94b576b3db9d34afa988ab08f1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"46fd8777_99a9e606","updated":"2025-10-16 06:49:01.000000000","message":"I think the original request:\n\n\"As an ironic operator, I don\u0027t want to be forced for the ramdisk to DHCP all my interfaces, I only want a specific interface DHCP\u0027ed and I want to do that in my ramdisk using BOOTIF kernel parameter.\"\n\nis totally valid but I think the implementation https://review.opendev.org/c/openstack/ironic/+/964168 involves to many unrelated subsystems. In the end the user would like to have \"BOOTIF\u003d\u003cvalue\u003e\" in the kernel cmdline params which is fine but instead of mixing pxe control logic with the vmedia control logic I think it would be cleaner if the user would just add the \"BOOTIF\u003d\u003cvalue\u003e\" value to the kernel_append_params field of the specific node\u0027s driver_info.\n\nIf the goal is to provide a general approach to optimize what interfaces are \"DHCP\u0027d\" then IMO dhcpless scenarios has to be taken into consideration especially when it comes to redfish vmedia where injecting the \"BOOTIF\u003d\u003cvalue\u003e\" would be not desired.\n\nWhen it comes to Metal3 there is already a feature in progress that would allow setting kernel_append_params on a per BMH/ironic node bases.\nRefs:\n - https://github.com/metal3-io/metal3-docs/pull/552\n - https://github.com/metal3-io/baremetal-operator/pull/2576","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":37442,"name":"Serhii Ivanov","email":"evasive.gyron@gmail.com","username":"s3rj1k"},"change_message_id":"8297da2e9b820457bda8aab3c31032aca034cf6b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a14bad5e_bef69fb4","updated":"2025-10-15 15:29:30.000000000","message":"Thank you for picking this up and implementing actual fix!","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":35233,"name":"Adam Rozman","email":"adam.rozman@est.tech","username":"rozzix"},"change_message_id":"0f9d0eaba78a594245aa9b09ea399ff2e93846a5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bbf4b063_56dbd838","in_reply_to":"330af8fb_6936ac24","updated":"2025-10-17 07:12:54.000000000","message":"FYI\u003e Just for reference the issue on the BMO side: https://github.com/metal3-io/baremetal-operator/issues/2712 . I will keep updating the BMO issue with my responses and the progress, so far I don\u0027t see any action needed from Ironic side.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"79de35e920707ca31d69165ad849f214f2e3ad3c","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8cfd72ec_4dfd9311","in_reply_to":"35c4d9dc_662fa85f","updated":"2025-10-16 08:15:13.000000000","message":"Follow-up: So, it\u0027s already possible to set kernel_append_params with a value like \"BOOTIF\u003d\u003cvalue\u003e\" in the node\u0027s driver_info, so when no vifs, this is automatically handled by Ironic. Operator just needs to set the BOOTIF value in the driver_info(?); which makes this change and the related bug not needed.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"acf7604b94b8356e9a91939c81c95672a4c0a79b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"35c4d9dc_662fa85f","in_reply_to":"46fd8777_99a9e606","updated":"2025-10-16 07:38:54.000000000","message":"I think this makes a ton of sense. I also thought about how a change like this might change how things worked. I will update this in a moment. Tks!","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"af9fb80654a8f73cb238f51c25be82235690f458","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"330af8fb_6936ac24","in_reply_to":"7c391f71_6c127878","updated":"2025-10-16 09:03:59.000000000","message":"/me only seeing this reply now.\n\nI think the BMO is the best place to solve it as well. However, if we have to glue things up on the ironic side, I think having a config might be the best approach.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":37442,"name":"Serhii Ivanov","email":"evasive.gyron@gmail.com","username":"s3rj1k"},"change_message_id":"2ff38be509a4db3d2ce0c9d0aabf4299fc036051","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d61264ef_3de55818","in_reply_to":"8cfd72ec_4dfd9311","updated":"2025-10-16 08:18:46.000000000","message":"This is not true, firstly mentioned change is not merged to BMO, secondly as an operator I don\u0027t want to set another field manually in BMH spec to make things happpen.\n\nSo if this is going to be solved by purely BMO, introduced feature should pickup bootMAC value and populate kernel_append_params by itself","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"acf7604b94b8356e9a91939c81c95672a4c0a79b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0ea42d03_1a5cf460","in_reply_to":"a14bad5e_bef69fb4","updated":"2025-10-16 07:38:54.000000000","message":"++","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":35233,"name":"Adam Rozman","email":"adam.rozman@est.tech","username":"rozzix"},"change_message_id":"462c3ff342516f5f8694ff09292534b7ad9bd339","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d95ee9a8_576a088a","in_reply_to":"d61264ef_3de55818","updated":"2025-10-16 08:47:48.000000000","message":"\u003e This is not true, firstly mentioned change is not merged to BMO, secondly as an operator I don\u0027t want to set another field manually in BMH spec to make things happpen.\n\u003e \n\u003e So if this is going to be solved by purely BMO, introduced feature should pickup bootMAC value and populate kernel_append_params by itself\n\nI didn\u0027t say that: \" it\u0027s already possible to set kernel_append_params with a value like \"BOOTIF\u003d\u003cvalue\u003e\" in the node\u0027s driver_info, so when no vifs, this is automatically handled by Ironic. Operator just needs to set the BOOTIF value in the driver_info\"\n\nI said that an custom value can be passed to kernel_append_params via driver_info.\nAnd taking that logic further the BOOTIF issue can be solved also without mixing pxe specific Ironic automation with VMEDIA and other type of provisioning that could cause issues in e.g. DHCPLess environments, standalone ironic environments (not Metal3) etc.\n\n--- Side note:\nThere is a way to set this already and that is called the preprovisioningImage in BMO, that is a CR that can be reconciled by custom controllers one example is https://github.com/openshift/machine-config-operator, I heard other users who mentioned they just have a very simple controller that fills out the preprovisioningImage with kernel params and that is all they have, so technically with this approach it is already doable in BMO.\n\n--- My proposal:\n\nThe WIP feature I have linked will improve on the existing preprovisioningImage functionality so I think that it will be simpler to add a boolean optional spec field to the BMH to auto populate the kernel params with BOOTIF\u003d\u003cbootMacaddress\u003e using the functionality of  https://github.com/metal3-io/metal3-docs/pull/552. \n\nSo IMO we can solve this on BMO side alone.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"35f20d595ff6d568004ea18432bd806f609e33a9","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7c391f71_6c127878","in_reply_to":"d61264ef_3de55818","updated":"2025-10-16 08:58:41.000000000","message":"Yeah.\n\nWell, it would appear that all Ironic-based solutions require manual intervention, which sort of defeats the purpose of the original request for automatic behavior.\n\nI think the best solution on the Ironic side, that does not mix concerns and minimal input will be adding a config option which which explicitly tells Ironic to automatically set BOOTIF based on pxe_enabled ports. This way, we get to error on cases of multiple pxe_enabled ports.\n\nDo you think this works for your use case.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"}],"ironic/drivers/modules/deploy_utils.py":[{"author":{"_account_id":35233,"name":"Adam Rozman","email":"adam.rozman@est.tech","username":"rozzix"},"change_message_id":"5c26f9c68fe55de73315c9bd72b9c55f568f80ab","unresolved":true,"context_lines":[{"line_number":315,"context_line":"    # interface."},{"line_number":316,"context_line":"    pxe_enabled_ports \u003d [p for p in task.ports if p.pxe_enabled]"},{"line_number":317,"context_line":"    if len(pxe_enabled_ports) \u003e 1:"},{"line_number":318,"context_line":"        LOG.warning(\"Multiple pxe_enabled ports found for node %s, \""},{"line_number":319,"context_line":"                    \"using first one: %s\", task.node.uuid,"},{"line_number":320,"context_line":"                    pxe_enabled_ports[0].address)"},{"line_number":321,"context_line":"    return pxe_enabled_ports[0].address if pxe_enabled_ports else None"}],"source_content_type":"text/x-python","patch_set":1,"id":"354af7ef_573bea98","line":318,"updated":"2025-10-16 07:10:53.000000000","message":"What if user would like to DHCP only the 56th interface/prot in a virtmedia booted env? I don\u0027t think putting the first port/interface as value of \"BOOTIF\u003d\" is a general solution. I would prefer to let the user manually set this via \"append_kernel_params\" of the driver_info.\n\nMixing pxe and dhcp together is also messy, pxe does need dhcp but not the other way around.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"},{"author":{"_account_id":36770,"name":"cid","display_name":"cid","email":"cid@gr-oss.io","username":"cidelight","status":"@gr-oss upstream: Doing good IRONIC things..."},"change_message_id":"acf7604b94b8356e9a91939c81c95672a4c0a79b","unresolved":true,"context_lines":[{"line_number":315,"context_line":"    # interface."},{"line_number":316,"context_line":"    pxe_enabled_ports \u003d [p for p in task.ports if p.pxe_enabled]"},{"line_number":317,"context_line":"    if len(pxe_enabled_ports) \u003e 1:"},{"line_number":318,"context_line":"        LOG.warning(\"Multiple pxe_enabled ports found for node %s, \""},{"line_number":319,"context_line":"                    \"using first one: %s\", task.node.uuid,"},{"line_number":320,"context_line":"                    pxe_enabled_ports[0].address)"},{"line_number":321,"context_line":"    return pxe_enabled_ports[0].address if pxe_enabled_ports else None"}],"source_content_type":"text/x-python","patch_set":1,"id":"ce6ef854_a639c0c3","line":318,"in_reply_to":"354af7ef_573bea98","updated":"2025-10-16 07:38:54.000000000","message":"Noted.","commit_id":"8f067f2ab74e96402c6b97f8d831cf2e1c00e3ed"}]}