)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"77e6ed44569ac2494aaa9c265af45c78f08996f2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"a35f818c_86c4d5df","updated":"2024-04-24 09:00:37.000000000","message":"I\u0027m definitely not an Ironic expert but it looks good for me generally. One question: will this new feature be able to work together with Neutron or if this will be enabled, Ironic will not use Neutron at all?","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"de7b84aa058704bd1aa2da4837860fbc5b150d76","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"d7f5aff1_9ad99d0e","in_reply_to":"465e94b2_e79c502f","updated":"2024-04-25 08:09:47.000000000","message":"yes, thx a lot","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"6630159e52ae08d8d5c69e5fcfebac2cef8c4362","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"465e94b2_e79c502f","in_reply_to":"a35f818c_86c4d5df","updated":"2024-04-24 13:38:53.000000000","message":"With ironic\u0027s plugin model, each node\u0027s network_interface would govern the pattern of behavior. Today we have \"flat\" and \"neutron\" network_interfaces which use neutron.  We would likely end up with an additional interface \"mercury\" in an MVP and those could be selected independently based upon the user. Users are also able to presently select \"noop\" which means \"do nothing with networking and Neutron\".\n\nI hope that answers your question, please let me know if you have any others.\n\nThanks!","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"7b0da8a6d8f895121a66c25f7d4c2cd289b90e79","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"2092b4c6_1c9b9914","updated":"2024-05-15 20:16:21.000000000","message":"It\u0027s clear that there\u0027s a need in the field to run ml2 drivers in a stripped down mode with no IPAM/FW/L3/... crust of traditional neutron.\n\nThe spec recommends to implement a new stateless runner. I wonder if there\u0027s a path for neutron to be stripped down to the bones to the point where ironic would be satisfied by a shim translator from \u0027attach/detach semantics\u0027 to \u0027basic neutron port / binding rest apis\u0027. Assuming the shim translator is written and other non-essential features and dependencies of neutron are stripped down, which other roadblocks are there on neutron side to accommodate for ironic? Is database a core problem or a mere nuance?","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"feedf1a85a2ec26800d7acd02092e20f4a4938d5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"6ecdd248_da4b94b0","in_reply_to":"1cb2ae68_4dbdec75","updated":"2024-05-18 16:43:02.000000000","message":"Maybe not directly run in the ML2 model as it is today, but access portions of the code in the drivers (which yes, means new pure binding action interfaces).\n\nBased on the current model, I think we would have to strip neutron down to the point it was basically database-less and keystone-less (but with some sort of authentication mechanism) to really be of use in this entirely separate networking model.\n\nThe core problem is really an access control and separation of duties issue. State in database is just extra overhead to track/manage/interact with and increases complexity.\n\nFor example, if your the \"cloud infra\" group, and your basically software/virtualization folks, and separation of duties requires a telecom/network group. In most larger organizations, there is not trust between groups because the separation of duties demands delineation. They may be even unwilling to provide you with a copy of switch configuration details, much less let you change configuration. To build appeal-ability to a integration, the shim has to be very clean/simple and log a *LOT* so they can figure out who/what/where.\n\nWhich means they likely won\u0027t be willing to really, entirely, trust your own authentication system, which means an entirely disjointed  \"system\".\n\nIn order to build trust and get a network team to be comfortable with a service talking to their hardware, it really needs to do one thing well in a moderately constrained scope. Needing a database also adds additional complexity and additional points of failure. If they just need a copy of a stateless service running somewhere, that is far easier to build trust around. Another item with the database is what value would the database really bring? If we already know the switchport which needs configuration changed, and the target network, what really is the purpose of the database at that point?\n\nOne of the *key* aspects to also keep in mind is Ironic has multiple models of use.\n\n* Day-0 cloud installation\n* Bare metal management entirely unrelated to a \"cloud\", for example from users \n like Metal3 or even users doing it entirely in a disjointed fashion.\n* Bare metal instances via Nova \n\nIf we had really good usage metrics, we would likely see 2/3rd of our usage pattern as being of the disjointed from the cloud integrated pattern where someone knows the addressing they need/want or they already have the IPAM infrastructure in place, and they just need the network attach/detach signaling to take place.\n\nOne thing which kind of lead me on the current path is a desire not to lock out usage patterns. I know there are operators out there who just face the separation of duties issue, and slimmed down neutron in the same form would also be a higher increased complexity which means neutron would need to be able to talk to neutron for slimmed down port binding, or Ironic would need to be able to talk to two distinct neutrons based upon the area of activity. I\u0027m not sure that really is the right path given we really just need the lower level actions and have a driver interface in Ironic to support entirely separate modes of operation on a per-baremetal node level.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"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":"ba7edc987f6b8c6d07ed9f60dc9bf19ec7248998","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"1cb2ae68_4dbdec75","in_reply_to":"2092b4c6_1c9b9914","updated":"2024-05-15 20:52:51.000000000","message":"I\u0027m going to answer at a high level from an ops perspective, talking about my use cases. I suspect Julia has different use cases and more insight into the Ironic/Neutron borders so I\u0027ll leave the in-depth response to here.\n\nWhile operating openstack, much of the pushback I\u0027ve seen for deploying Neutron -- or more accurately, allowing it to have control over physical networks -- is that there\u0027s a base assumption that Neutron is the source of truth for networking -- it knows what IPs are where, and the like. Many Ironic users, especially in existing environments, have extreme difficulties getting Neutron installed and configured due to this level of scope.\n\nIt\u0027s my hope that we can find a way to support basic network tasks -- e.g. swapping what VLAN is exposed on a nodes\u0027 port as it travels through provisioning/cleaning and eventually into an instance -- without needing additional information about the network other than basic directive information.\n\nI don\u0027t know neutron well enough to know if this is possible in that model.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"cd23a98f95ba72b7c09f70a0b64c5fe41befe972","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"85f47443_3e0f85f9","updated":"2024-06-09 08:13:18.000000000","message":"I think the general idea is great, and anything unclear would be clarified during implementation, also this can\u0027t be a one step work, I think several iterations are accepted.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"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":"4b1c6656ae8c9d4804d6d8c5a536b13d0bc46193","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"4d65d8a1_f50950e9","updated":"2024-06-12 14:43:11.000000000","message":"If this needs to be revised later, it can be, but at this point I think we should get this into the repo.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"9ce3f531af3ebef89e66b7b961dc333e8a3099f6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"5af8dfc0_5073430b","updated":"2024-05-29 15:03:29.000000000","message":"Thanks for clarifications folks! I understand the rationale (a very slim stateless interface), and neutron can\u0027t deliver it without bending over while risking code stability too much (for which the team doesn\u0027t have capacity or motivation anyway). Let\u0027s just keep an eye on code reuse through neutron-lib or elsewhere, wherever it makes sense.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"31e16475_3551a464","updated":"2024-06-01 15:05:32.000000000","message":"looks good, just some nits","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"}],"specs/approved/asylumn.rst":[{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"2bd4f713ba7636a6b991005fdc733a9b67a427ba","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Project Asylumn"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":".. TODO::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c1d9fb79_76499008","line":8,"updated":"2024-04-17 18:01:36.000000000","message":"So a few possible names have already been surfaced:\n\nAnvil, other uses in the universe appear to be a Job Batch scheduling system from Purdue University, and an National Institute of Health Open Genetics Data Set Project.\n\nSo... it might be viable.\n\nAnother possibility is Mercury. It is metal, it is liquid at room temperature!","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"dcf3be9ca118c97ea96e4530fc2531bd9b131170","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Project Asylumn"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":".. TODO::"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fc238310_e87ddf26","line":8,"in_reply_to":"c1d9fb79_76499008","updated":"2024-04-18 15:27:07.000000000","message":"Done","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"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":"9cb3840c11fad25d84ce44468b907e77c770dae8","unresolved":true,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":".. TODO::"},{"line_number":12,"context_line":"   Is there a better name? Julia likes the name since it might be necessary"},{"line_number":13,"context_line":"   to have an Asylumn for contributors to this."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":16,"context_line":"physical network configuration to facilitate orchustration of networking"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f86aaf54_6431a83b","line":13,"updated":"2024-04-17 18:44:00.000000000","message":"I am -1 to the existing name, but like the above suggestions.","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"dcf3be9ca118c97ea96e4530fc2531bd9b131170","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":".. TODO::"},{"line_number":12,"context_line":"   Is there a better name? Julia likes the name since it might be necessary"},{"line_number":13,"context_line":"   to have an Asylumn for contributors to this."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":16,"context_line":"physical network configuration to facilitate orchustration of networking"}],"source_content_type":"text/x-rst","patch_set":2,"id":"97c29ef6_77bc5c4b","line":13,"in_reply_to":"f86aaf54_6431a83b","updated":"2024-04-18 15:27:07.000000000","message":"Done","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"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":"9cb3840c11fad25d84ce44468b907e77c770dae8","unresolved":true,"context_lines":[{"line_number":203,"context_line":"REST API impact"},{"line_number":204,"context_line":"---------------"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"With a MVP, we do not anticipate any REST API changes to Ironic itself."},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Post-MVP may include some sort of /v1/physical_network endpoint to be"},{"line_number":209,"context_line":"designed, but that is anticipated to be designed once we know more."}],"source_content_type":"text/x-rst","patch_set":2,"id":"aa1c96b5_12f451de","line":206,"updated":"2024-04-17 18:44:00.000000000","message":"I think I\u0027m missing something about how we can implement all of this without changing the rest API.\n\nAt a minimum, we\u0027re going to be changing the meaning of some fields on node/port, yeah? Even if we just add a new binding profile type to local_link_connection that still is a new API microversion.\n\nI think I\u0027m missing something...","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"dcf3be9ca118c97ea96e4530fc2531bd9b131170","unresolved":true,"context_lines":[{"line_number":203,"context_line":"REST API impact"},{"line_number":204,"context_line":"---------------"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"With a MVP, we do not anticipate any REST API changes to Ironic itself."},{"line_number":207,"context_line":""},{"line_number":208,"context_line":"Post-MVP may include some sort of /v1/physical_network endpoint to be"},{"line_number":209,"context_line":"designed, but that is anticipated to be designed once we know more."}],"source_content_type":"text/x-rst","patch_set":2,"id":"35694a77_4e9fd7bd","line":206,"in_reply_to":"aa1c96b5_12f451de","updated":"2024-04-18 15:27:07.000000000","message":"so binding profile is inherently a Neutron concept, and the profile in all cases with ironic is \"baremetal\". Augmenting description to provide more clarity here.","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"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":"9cb3840c11fad25d84ce44468b907e77c770dae8","unresolved":true,"context_lines":[{"line_number":252,"context_line":"Security impact"},{"line_number":253,"context_line":"---------------"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Impact for Ironic itself is minimal, although it will require credentials to"},{"line_number":256,"context_line":"be set for the remote service to signal interface attachment/detachments."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"The security risk largely revolves around the new service we\u0027re looking at"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7457cd01_f2de013f","line":255,"updated":"2024-04-17 18:44:00.000000000","message":"So, what about auth between Ironic and this new service? If we don\u0027t have a keystone, we can\u0027t use token based auth.\n\nCertificates?\nShared secret?\nHTTPD basic auth in front of it all?\n\nThis is something we should probably address -- even if saying it\u0027s out of scope is how we address it.","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"dcf3be9ca118c97ea96e4530fc2531bd9b131170","unresolved":false,"context_lines":[{"line_number":252,"context_line":"Security impact"},{"line_number":253,"context_line":"---------------"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Impact for Ironic itself is minimal, although it will require credentials to"},{"line_number":256,"context_line":"be set for the remote service to signal interface attachment/detachments."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"The security risk largely revolves around the new service we\u0027re looking at"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9ea1b7a2_6a563a2e","line":255,"in_reply_to":"7457cd01_f2de013f","updated":"2024-04-18 15:27:07.000000000","message":"Likely something in the client, but putting a basic idea of a starting point and an end point in.","commit_id":"dabdbaad5948f1ab1d24d5f042e004a4e747a90a"}],"specs/approved/mercury.rst":[{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"841c671557bbfc20b2d2f433e3c539e8c11faeb9","unresolved":true,"context_lines":[{"line_number":53,"context_line":"* Intended to provide management of Routing."},{"line_number":54,"context_line":"* Intended to provide management of Security Groups or Firewalling."},{"line_number":55,"context_line":"* Intended to provide a public ReSTful API, nor require a database."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"This project MAY:"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* Provide a means to help enable and deploy advanced tooling to a DPU under"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e47ca181_a98b55dc","line":56,"updated":"2024-04-24 01:14:18.000000000","message":"Hi Julia, it\u0027s an exciting idea!\nIt looks like we will have a new rpc service which is mainly responsible for the switch configuration, I wonder how it relates with the ngs?\nIf it\u0027s not function as an IPAM, do we have other mechanisms to land the network configuration like ip assignment, dhcp service, in case neutron is not available?\nAlso, in the openstack scenario, the \"network\" team may provide ml2 plugin into neutron service so they act as the sole entry to the network complexity from the ironic perspective. I wonder how the new service would cope in 😊","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"6630159e52ae08d8d5c69e5fcfebac2cef8c4362","unresolved":true,"context_lines":[{"line_number":53,"context_line":"* Intended to provide management of Routing."},{"line_number":54,"context_line":"* Intended to provide management of Security Groups or Firewalling."},{"line_number":55,"context_line":"* Intended to provide a public ReSTful API, nor require a database."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"This project MAY:"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* Provide a means to help enable and deploy advanced tooling to a DPU under"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e214d350_ff6c2fec","line":56,"in_reply_to":"e47ca181_a98b55dc","updated":"2024-04-24 13:38:53.000000000","message":"Greetings Kaifeng!\n\nHope your doing well!\n\nAnyway, yes, in the current shape largely relates to being able to take NGS or some *other* ML2 plugin and being able to call it for the physical port operations.\n\nDuring the PTG we didn\u0027t get deep into IPAM issues, but a related discussion was basically that DHCP with dnsmasq is not really a viable path for CI moving forward, Ironic has the ability to directly do some configuration management of that based upon user inputs for the standalone use case. I think the case we vision into the future is more a virutal media based model than a network boot model. Combine with many standalone operators already have these challenges solved, or only need it solved for a provisioning network, largely means the project scope is simplified based on existing model. This might end up being something along the existing network_data field on a node being supersceeded down the road, but only time will tell.\n\nAs for a ML2 plugin *only* being plugged into Neutron, I don\u0027t think that would really change anything for what we\u0027re proposing, just the new resulting network_interface drivers wouldn\u0027t be able to be leveraged.\n\n-Julia","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"f353b56ff4b86af9b8a80d8fbc1b5cad2bac360c","unresolved":true,"context_lines":[{"line_number":141,"context_line":""},{"line_number":142,"context_line":"With initially expected ml2 methods being:"},{"line_number":143,"context_line":""},{"line_number":144,"context_line":"* get_allowed_network_types - Returns a list of allowed types"},{"line_number":145,"context_line":"* bind_port"},{"line_number":146,"context_line":"* update_port_postcommit"},{"line_number":147,"context_line":"* delete_port_postcommit"},{"line_number":148,"context_line":"* create_port_postcommit"},{"line_number":149,"context_line":"* delete_network_postcommit"},{"line_number":150,"context_line":"* create_network_postcommit"},{"line_number":151,"context_line":"* try_to_bind_segment_for_agent - This may not be required outright for an"},{"line_number":152,"context_line":"  MVP, however it does contain additional arguments which needs to influence"},{"line_number":153,"context_line":"  our overall design and we should account for it up front."},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"For the remote RPC service, it is anticipated that logging will need to"},{"line_number":156,"context_line":"be verbose enough that Operators can understand the questions they may raise"}],"source_content_type":"text/x-rst","patch_set":4,"id":"5ee248dd_a4848ef4","line":153,"range":{"start_line":144,"start_character":0,"end_line":153,"end_character":59},"updated":"2024-05-04 13:55:07.000000000","message":"So digging into this, it looks more like the interface would end up with more a distinct attach/detach model, and not a direct proxy-through for ml2.\n\nSpecifically because I\u0027ve uncovered a couple cases where n-g-s does \"remote\" calls. They aren\u0027t actually remote, but the plugin directly calls a method on the provided input context, and in a couple cases interacts with neutron\u0027s DB. In both cases, it is not great.\n\nAn example is bind port, it doesn\u0027t actually engage the switch mechanism driver to do anything, it more so does checks, asks questions like \"is_link_valid\", and \"is_port_supported\", and then updates the DB. This could *entirely* be run client side with the \"is_link_valid\" and \"is_port_supported\" calls being passed through.","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"3d63f221b85424d0f780f7d2479d1473793fa986","unresolved":true,"context_lines":[{"line_number":346,"context_line":"Broadly speaking, the work items would include:"},{"line_number":347,"context_line":""},{"line_number":348,"context_line":"1) Prototyping this new service."},{"line_number":349,"context_line":"2) Prototyping an ironic network_interface driver to utilize this new"},{"line_number":350,"context_line":"   service."},{"line_number":351,"context_line":"3) Loosen (as previously agreed in past Ironic PTGs) the \"vif binding\""},{"line_number":352,"context_line":"   restriction Regular Expression to permit a VLAN id to be provided."}],"source_content_type":"text/x-rst","patch_set":4,"id":"e85c4690_a33c87b2","line":349,"updated":"2024-05-04 00:00:55.000000000","message":"As a practical note, I\u0027d swap these. I started seeing how I\u0027d wire in a genericized interface in, and realize it would just be best to figure out what I need to call  *first* to prototype the mapping for the service.","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"3d63f221b85424d0f780f7d2479d1473793fa986","unresolved":true,"context_lines":[{"line_number":348,"context_line":"1) Prototyping this new service."},{"line_number":349,"context_line":"2) Prototyping an ironic network_interface driver to utilize this new"},{"line_number":350,"context_line":"   service."},{"line_number":351,"context_line":"3) Loosen (as previously agreed in past Ironic PTGs) the \"vif binding\""},{"line_number":352,"context_line":"   restriction Regular Expression to permit a VLAN id to be provided."},{"line_number":353,"context_line":"4) Test!"},{"line_number":354,"context_line":""},{"line_number":355,"context_line":".. note::"}],"source_content_type":"text/x-rst","patch_set":4,"id":"2df37ddb_2b6d9343","line":352,"range":{"start_line":351,"start_character":0,"end_line":352,"end_character":69},"updated":"2024-05-04 00:00:55.000000000","message":"It looks like we may have already done this as a result of refactoring/cleanup in the last few cycles. It *appears* we can just post a id number in and we should be golden regarding this.","commit_id":"6aeec08df09662a289b7ef8a59d79a3c00dd3d8d"},{"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":"6c23b2e17cfdd3295445f131856ded5b8da870ce","unresolved":true,"context_lines":[{"line_number":68,"context_line":"   leave it to the implementer\u0027s progotive with this document being overall"},{"line_number":69,"context_line":"   guard rails."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Problem description"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Essentially, we need a service to facilitate secure and delienated network"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2d046fcf_3f8f29c7","line":71,"updated":"2024-05-15 15:38:27.000000000","message":"It\u0027d be nice to get a concrete use case as to what we enable.\n\nMaybe specifically mention:\n- This enables Ironic to work with a network device without owning the entire network\n- This enables Ironic to serve the most common use cases without needing a full Neutron installation","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a0b0fc7d3b10acdb692fdfdc3f290bf878b1b824","unresolved":true,"context_lines":[{"line_number":68,"context_line":"   leave it to the implementer\u0027s progotive with this document being overall"},{"line_number":69,"context_line":"   guard rails."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Problem description"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Essentially, we need a service to facilitate secure and delienated network"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b7636f7a_14745c8d","line":71,"in_reply_to":"2d046fcf_3f8f29c7","updated":"2024-05-22 22:35:13.000000000","message":"Okay, hopefully the next update sort of provides a bit more concrete in this area.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"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":"90ce756f903d803a1d89fe14c0a94cd1fc5fc49c","unresolved":false,"context_lines":[{"line_number":68,"context_line":"   leave it to the implementer\u0027s progotive with this document being overall"},{"line_number":69,"context_line":"   guard rails."},{"line_number":70,"context_line":""},{"line_number":71,"context_line":"Problem description"},{"line_number":72,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"Essentially, we need a service to facilitate secure and delienated network"}],"source_content_type":"text/x-rst","patch_set":5,"id":"88fcf4e4_aa5305fb","line":71,"in_reply_to":"b7636f7a_14745c8d","updated":"2024-05-29 09:18:34.000000000","message":"Done","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"7b0da8a6d8f895121a66c25f7d4c2cd289b90e79","unresolved":true,"context_lines":[{"line_number":212,"context_line":""},{"line_number":213,"context_line":"The closest alternative would be a ``standalone Neutron`` coupled with some"},{"line_number":214,"context_line":"sort of extended/proxy RPC model, which is fine, but that really does not"},{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."}],"source_content_type":"text/x-rst","patch_set":5,"id":"ec347bc7_e31aafe4","line":216,"range":{"start_line":215,"start_character":8,"end_line":216,"end_character":40},"updated":"2024-05-15 20:16:21.000000000","message":"Is the challenge about no \"stateless\" API for attach/detach available in neutron? Could this be simulated by the new service talking to neutron rest api - port + binding profile - instead of to ml2 drivers directly? what\u0027s the drawback?\n\n(I assume a \u0027standalone neutron\u0027 would not depend on keystone or any other services; but would have a database. Is this a problem?)","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"feedf1a85a2ec26800d7acd02092e20f4a4938d5","unresolved":true,"context_lines":[{"line_number":212,"context_line":""},{"line_number":213,"context_line":"The closest alternative would be a ``standalone Neutron`` coupled with some"},{"line_number":214,"context_line":"sort of extended/proxy RPC model, which is fine, but that really does not"},{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."}],"source_content_type":"text/x-rst","patch_set":5,"id":"cf67b014_54706aa3","line":216,"range":{"start_line":215,"start_character":8,"end_line":216,"end_character":40},"in_reply_to":"ec347bc7_e31aafe4","updated":"2024-05-18 16:43:02.000000000","message":"Part of the challenge is no stateless API surfacing attach/detach exists.\n\nIf it was a thing, we wouldn\u0027t build a new service, but instead build a new driver with a separate Neutron API client which is bound to a different set of rules and flow.\n\nOne thing to keep in mind is a database would be an increased barrier to entry. The people managing this \"standalone\" instance would not be software engineers or systems engineers, they would be network engineers. They likely wouldn\u0027t care at all about OpenStack release cycling or compatibility, they would just need the thing to work with very verbose logging so they can, should an issue arise, be able to answer the questions of auditors. At some point, we would need some sort of request filtering based upon configuration, maybe, but the needs and requirements begin to become completely different at that point.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"7b0da8a6d8f895121a66c25f7d4c2cd289b90e79","unresolved":true,"context_lines":[{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Another possibility would be to directly embed the network attach/detach"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e7b9e519_8e110056","line":218,"range":{"start_line":218,"start_character":36,"end_line":218,"end_character":43},"updated":"2024-05-15 20:16:21.000000000","message":"I think it\u0027s possible to run neutron without l3 plugin enabled.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"7b0da8a6d8f895121a66c25f7d4c2cd289b90e79","unresolved":true,"context_lines":[{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Another possibility would be to directly embed the network attach/detach"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1fc65a3e_f92e6415","line":218,"range":{"start_line":218,"start_character":6,"end_line":218,"end_character":31},"updated":"2024-05-15 20:16:21.000000000","message":"IPAM layer in neutron is pluggable and can probably be a no-op: https://github.com/openstack/neutron/blob/11255ede9715800e2945e0b318c93a5ac9f1e968/setup.cfg#L133","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a0b0fc7d3b10acdb692fdfdc3f290bf878b1b824","unresolved":false,"context_lines":[{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Another possibility would be to directly embed the network attach/detach"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7225b2a7_090778b0","line":218,"range":{"start_line":218,"start_character":6,"end_line":218,"end_character":31},"in_reply_to":"1fc65a3e_f92e6415","updated":"2024-05-22 22:35:13.000000000","message":"Clarifying text to not explicitly call out IPAM.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a0b0fc7d3b10acdb692fdfdc3f290bf878b1b824","unresolved":true,"context_lines":[{"line_number":215,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":216,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":217,"context_line":"might not be suitable for bulk infrastucture operators, as they tend to have"},{"line_number":218,"context_line":"their own IP Address management and routers in place for the physical portion"},{"line_number":219,"context_line":"of their infrastucture."},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"Another possibility would be to directly embed the network attach/detach"}],"source_content_type":"text/x-rst","patch_set":5,"id":"c1297be2_003fb5d1","line":218,"range":{"start_line":218,"start_character":36,"end_line":218,"end_character":43},"in_reply_to":"e7b9e519_8e110056","updated":"2024-05-22 22:35:13.000000000","message":"I think your right about this, but I\u0027m not sure how happy folks will be to have to model their infrastructure in neutron\u0027s model to follow it\u0027s pattern, either. I guess there are pluses and minuses depending on approach.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":9656,"name":"Ihar Hrachyshka","email":"ihrachys@redhat.com","username":"ihrachys","status":"Red Hat Networking Systems Engineer"},"change_message_id":"7b0da8a6d8f895121a66c25f7d4c2cd289b90e79","unresolved":true,"context_lines":[{"line_number":404,"context_line":"* Creation of a common library for Ironic and any other program or tool"},{"line_number":405,"context_line":"  to utilize to compose RPC calls to this service."},{"line_number":406,"context_line":"* Extend support to VXLAN ports, which may require additional details or"},{"line_number":407,"context_line":"  design work to take place and work in any ML2 plugins utilized."},{"line_number":408,"context_line":"* Design an API rest endpoint to facilitate the tracking of physical"},{"line_number":409,"context_line":"  networks to be attached to baremetal nodes."},{"line_number":410,"context_line":"* Add support to networking-baremetal to try and reconcile these"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e5240618_b5fa4700","line":407,"range":{"start_line":407,"start_character":44,"end_line":407,"end_character":55},"updated":"2024-05-15 20:16:21.000000000","message":"this should probably talk about ml2 *drivers*, since there\u0027s a single ml2 *plugin* that is the runner for *drivers*. (We could probably strip the existing ml2 plugin to the bones to support just the base \"port attach/detach\" related codepaths and call it ml2plugin-lite. Then we would have two ml2plugin flavors.)","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"a0b0fc7d3b10acdb692fdfdc3f290bf878b1b824","unresolved":true,"context_lines":[{"line_number":404,"context_line":"* Creation of a common library for Ironic and any other program or tool"},{"line_number":405,"context_line":"  to utilize to compose RPC calls to this service."},{"line_number":406,"context_line":"* Extend support to VXLAN ports, which may require additional details or"},{"line_number":407,"context_line":"  design work to take place and work in any ML2 plugins utilized."},{"line_number":408,"context_line":"* Design an API rest endpoint to facilitate the tracking of physical"},{"line_number":409,"context_line":"  networks to be attached to baremetal nodes."},{"line_number":410,"context_line":"* Add support to networking-baremetal to try and reconcile these"}],"source_content_type":"text/x-rst","patch_set":5,"id":"2be0ef27_9e1d4a7c","line":407,"range":{"start_line":407,"start_character":44,"end_line":407,"end_character":55},"in_reply_to":"28c4b33d_92309095","updated":"2024-05-22 22:35:13.000000000","message":"The thought which presently comes to mind is to build up a model on mercury (or whatever we call this) and just have something like networking-generic-switch register the endpoints so they can be loaded. Neutron itself could pattern a cleaner interface which handles all database activity outside of actions.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"feedf1a85a2ec26800d7acd02092e20f4a4938d5","unresolved":true,"context_lines":[{"line_number":404,"context_line":"* Creation of a common library for Ironic and any other program or tool"},{"line_number":405,"context_line":"  to utilize to compose RPC calls to this service."},{"line_number":406,"context_line":"* Extend support to VXLAN ports, which may require additional details or"},{"line_number":407,"context_line":"  design work to take place and work in any ML2 plugins utilized."},{"line_number":408,"context_line":"* Design an API rest endpoint to facilitate the tracking of physical"},{"line_number":409,"context_line":"  networks to be attached to baremetal nodes."},{"line_number":410,"context_line":"* Add support to networking-baremetal to try and reconcile these"}],"source_content_type":"text/x-rst","patch_set":5,"id":"28c4b33d_92309095","line":407,"range":{"start_line":407,"start_character":44,"end_line":407,"end_character":55},"in_reply_to":"e5240618_b5fa4700","updated":"2024-05-18 16:43:02.000000000","message":"Honestly, given what I\u0027ve recently learned that a pattern in ML2 plugins is to go update database objects to track success, I\u0027m hesitant to just try and map ml2 across directly and sort of make that a higher level problem. The plus of a higher level problem is a ml2 plugin to work in neutron could also exist and call the same backend service.","commit_id":"20602019440a1201bba5165787251ea6c7a3db76"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://bugs.launchpad.net/ironic/+bug/2063169"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":14,"context_line":"physical network configuration to facilitate orchustration of networking"},{"line_number":15,"context_line":"in a delineated way from existing OpenStack Neutron service in a model"},{"line_number":16,"context_line":"which would able to operated effectively by another team which is not"}],"source_content_type":"text/x-rst","patch_set":6,"id":"21055579_2b840c57","line":13,"range":{"start_line":13,"start_character":28,"end_line":13,"end_character":30},"updated":"2024-06-01 15:05:32.000000000","message":"nit: a","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":11,"context_line":"https://bugs.launchpad.net/ironic/+bug/2063169"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":14,"context_line":"physical network configuration to facilitate orchustration of networking"},{"line_number":15,"context_line":"in a delineated way from existing OpenStack Neutron service in a model"},{"line_number":16,"context_line":"which would able to operated effectively by another team which is not"},{"line_number":17,"context_line":"a \"cloud\" team, but a \"network\" team."}],"source_content_type":"text/x-rst","patch_set":6,"id":"fa769229_03d898aa","line":14,"range":{"start_line":14,"start_character":45,"end_line":14,"end_character":58},"updated":"2024-06-01 15:05:32.000000000","message":"nit: orchestration","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":13,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":14,"context_line":"physical network configuration to facilitate orchustration of networking"},{"line_number":15,"context_line":"in a delineated way from existing OpenStack Neutron service in a model"},{"line_number":16,"context_line":"which would able to operated effectively by another team which is not"},{"line_number":17,"context_line":"a \"cloud\" team, but a \"network\" team."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The reasons why are plentiful:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"3570fe9a_d5a42c22","line":16,"updated":"2024-06-01 15:05:32.000000000","message":"nit: be able","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":13,"context_line":"This is a project to create an simplified framework between Ironic and"},{"line_number":14,"context_line":"physical network configuration to facilitate orchustration of networking"},{"line_number":15,"context_line":"in a delineated way from existing OpenStack Neutron service in a model"},{"line_number":16,"context_line":"which would able to operated effectively by another team which is not"},{"line_number":17,"context_line":"a \"cloud\" team, but a \"network\" team."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"The reasons why are plentiful:"}],"source_content_type":"text/x-rst","patch_set":6,"id":"528d17ed_db36c375","line":16,"range":{"start_line":16,"start_character":20,"end_line":16,"end_character":28},"updated":"2024-06-01 15:05:32.000000000","message":"nit: operate","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"e564b701774ae829c7dc03675a5c1fb06a0da31d","unresolved":true,"context_lines":[{"line_number":28,"context_line":"  circumstances."},{"line_number":29,"context_line":"* The introduction of DPUs generally means that we now have potential cases"},{"line_number":30,"context_line":"  where switches need to be programmed to provision a DPU, and then the DPU"},{"line_number":31,"context_line":"  needs to be programmed to provision servers."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"The goals can be summarized as:"},{"line_number":34,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"626aa984_ee1666db","line":31,"updated":"2024-05-29 15:10:32.000000000","message":"There is gap between the openstack solution and standalone ironic, we also see usecases that many deployers want to manage baremetals without openstack for lower resource overhead.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"e564b701774ae829c7dc03675a5c1fb06a0da31d","unresolved":true,"context_lines":[{"line_number":35,"context_line":"* Provide a mechanism to configure L2 networks on Switches, which may be"},{"line_number":36,"context_line":"  facilitated by a modified networking-generic-switch or similar plugin."},{"line_number":37,"context_line":"* Provide a mechanism to configure L2 networks to be provided to a host"},{"line_number":38,"context_line":"  from a DPU."},{"line_number":39,"context_line":"* Provide a mechanism to accomodate highly isolated network management"},{"line_number":40,"context_line":"  interfaces where operators restrict access such that *only* Ironic"},{"line_number":41,"context_line":"  is able to connect to the remote endpoint."}],"source_content_type":"text/x-rst","patch_set":6,"id":"3d514a11_5373f863","line":38,"updated":"2024-05-29 15:10:32.000000000","message":"Do we have support scenarios for the switch configuration? In production we see mclag prevails, but I am not sure ngs can handle this case.\nbtw netconf deprecates ssh for it\u0027s low performance.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"744ad8698766ba23f9442685f52a7089e1b7b4d9","unresolved":true,"context_lines":[{"line_number":35,"context_line":"* Provide a mechanism to configure L2 networks on Switches, which may be"},{"line_number":36,"context_line":"  facilitated by a modified networking-generic-switch or similar plugin."},{"line_number":37,"context_line":"* Provide a mechanism to configure L2 networks to be provided to a host"},{"line_number":38,"context_line":"  from a DPU."},{"line_number":39,"context_line":"* Provide a mechanism to accomodate highly isolated network management"},{"line_number":40,"context_line":"  interfaces where operators restrict access such that *only* Ironic"},{"line_number":41,"context_line":"  is able to connect to the remote endpoint."}],"source_content_type":"text/x-rst","patch_set":6,"id":"1eb0ef93_56c37895","line":38,"in_reply_to":"3d514a11_5373f863","updated":"2024-05-31 23:32:45.000000000","message":"I don\u0027t see why that wouldn\u0027t sort of just work if we attach all interfaces. I guess the key and challenge will be how to navigate that. I guess under current model it would need to be portgroups.\n\nAlso, w/r/t netconf and ssh, good to know.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":60,"context_line":"* Provide a means to help enable and deploy advanced tooling to a DPU under"},{"line_number":61,"context_line":"  Ironic\u0027s control."},{"line_number":62,"context_line":"* Provide a means of offloading some of the layer2 interaction responsibility"},{"line_number":63,"context_line":"  in an environment *with* Neutron and Ironic, espescially."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":".. warning::"},{"line_number":66,"context_line":"   This document is not a precise and thus prescriptive design document, but"}],"source_content_type":"text/x-rst","patch_set":6,"id":"e1e8b40a_d7a7708e","line":63,"range":{"start_line":63,"start_character":47,"end_line":63,"end_character":58},"updated":"2024-06-01 15:05:32.000000000","message":"nit: especially","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":66,"context_line":"   This document is not a precise and thus prescriptive design document, but"},{"line_number":67,"context_line":"   an document to record and surface the ideas in a way that can foster"},{"line_number":68,"context_line":"   communication and consensus building. In this case, we are likely to"},{"line_number":69,"context_line":"   leave it to the implementer\u0027s progotive with this document being overall"},{"line_number":70,"context_line":"   guard rails."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Problem description"}],"source_content_type":"text/x-rst","patch_set":6,"id":"e6767657_4a0806a4","line":69,"range":{"start_line":69,"start_character":33,"end_line":69,"end_character":42},"updated":"2024-06-01 15:05:32.000000000","message":"mmm? prerogative?","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"e564b701774ae829c7dc03675a5c1fb06a0da31d","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Unfortunately, infrastructure operators needing Ironic largely reject this"},{"line_number":78,"context_line":"model because the network is often owned by a separate group."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"As a result we need a service to facilitate secure and delienated network"},{"line_number":81,"context_line":"management which can be owned and operated by separate infrastructure team"},{"line_number":82,"context_line":"in an enterprise organization, which brings together, aspects like simple code"},{"line_number":83,"context_line":"patterns and playbooks such that they can trust the interface layer to apply"}],"source_content_type":"text/x-rst","patch_set":6,"id":"97026ccd_4519b397","line":80,"range":{"start_line":80,"start_character":55,"end_line":80,"end_character":65},"updated":"2024-05-29 15:10:32.000000000","message":"delineated","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"e564b701774ae829c7dc03675a5c1fb06a0da31d","unresolved":true,"context_lines":[{"line_number":100,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"We are proposing an RPC service. Specifically something along the lines of a"},{"line_number":103,"context_line":"JSON-RPC endpoint, which multiple ironic conductors would be able to connect"},{"line_number":104,"context_line":"to in order to request networking changes to be made."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Along side of the RPC service, we would have an appropriately named"}],"source_content_type":"text/x-rst","patch_set":6,"id":"b020eb05_cdd392eb","line":103,"range":{"start_line":103,"start_character":0,"end_line":103,"end_character":17},"updated":"2024-05-29 15:10:32.000000000","message":"maybe make it configurable? As ironic in openstack still uses messaging.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":24828,"name":"Kaifeng Wang","email":"kaifeng.w@gmail.com","username":"wangkf"},"change_message_id":"54279d7fd64cab5c8e5785bba74b1d684a9acd8a","unresolved":true,"context_lines":[{"line_number":100,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"We are proposing an RPC service. Specifically something along the lines of a"},{"line_number":103,"context_line":"JSON-RPC endpoint, which multiple ironic conductors would be able to connect"},{"line_number":104,"context_line":"to in order to request networking changes to be made."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Along side of the RPC service, we would have an appropriately named"}],"source_content_type":"text/x-rst","patch_set":6,"id":"a77f4ee2_9b667d3c","line":103,"range":{"start_line":103,"start_character":0,"end_line":103,"end_character":17},"in_reply_to":"293e647f_f04679a3","updated":"2024-06-01 13:51:22.000000000","message":"There are many use cases out there, we can not satisfy all of them for sure, but we can still establish an abstraction interface by design, so that it\u0027s possible to fulfill the interface contract by different implementations.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"9d0ad5363c6b580c0ea83ba14e8c53a685fb7380","unresolved":true,"context_lines":[{"line_number":100,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"We are proposing an RPC service. Specifically something along the lines of a"},{"line_number":103,"context_line":"JSON-RPC endpoint, which multiple ironic conductors would be able to connect"},{"line_number":104,"context_line":"to in order to request networking changes to be made."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Along side of the RPC service, we would have an appropriately named"}],"source_content_type":"text/x-rst","patch_set":6,"id":"a252087e_246e5ad6","line":103,"range":{"start_line":103,"start_character":0,"end_line":103,"end_character":17},"in_reply_to":"a77f4ee2_9b667d3c","updated":"2024-06-05 20:42:59.000000000","message":"I guess I\u0027m not sure you would actually need one, because the overall attach model is to ship the information for the port for each \"port\" which includes all of the details. The port... should.... unwind the settings and set the desired state.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"744ad8698766ba23f9442685f52a7089e1b7b4d9","unresolved":true,"context_lines":[{"line_number":100,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"We are proposing an RPC service. Specifically something along the lines of a"},{"line_number":103,"context_line":"JSON-RPC endpoint, which multiple ironic conductors would be able to connect"},{"line_number":104,"context_line":"to in order to request networking changes to be made."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"Along side of the RPC service, we would have an appropriately named"}],"source_content_type":"text/x-rst","patch_set":6,"id":"293e647f_f04679a3","line":103,"range":{"start_line":103,"start_character":0,"end_line":103,"end_character":17},"in_reply_to":"b020eb05_cdd392eb","updated":"2024-05-31 23:32:45.000000000","message":"I\u0027m somewhat hesitant to take that path. Maybe past an MVP. I\u0027m really not sure.","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":190,"context_line":"* detach_port - Performs the actual action of \"detaching\""},{"line_number":191,"context_line":"  (removing network access from a port)."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* update_port - Peroforms an attempt to update a port for \"attachment\","},{"line_number":194,"context_line":"  such as if port-channels/bonding properties have changed."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* add_network - Adds a network to the remote device."}],"source_content_type":"text/x-rst","patch_set":6,"id":"ba58e2c1_946bf214","line":193,"range":{"start_line":193,"start_character":16,"end_line":193,"end_character":25},"updated":"2024-06-01 15:05:32.000000000","message":"nit: Performs","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"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":"7a3852ba083ad91a13cbbf6a49e928ab7aab161f","unresolved":true,"context_lines":[{"line_number":190,"context_line":"* detach_port - Performs the actual action of \"detaching\""},{"line_number":191,"context_line":"  (removing network access from a port)."},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"* update_port - Peroforms an attempt to update a port for \"attachment\","},{"line_number":194,"context_line":"  such as if port-channels/bonding properties have changed."},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"* add_network - Adds a network to the remote device."}],"source_content_type":"text/x-rst","patch_set":6,"id":"6108f099_d4be043a","line":193,"range":{"start_line":193,"start_character":16,"end_line":193,"end_character":25},"in_reply_to":"ba58e2c1_946bf214","updated":"2024-06-06 13:08:27.000000000","message":"++\nOr just s/Peroforms an attempt/Attempts","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"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":"90ce756f903d803a1d89fe14c0a94cd1fc5fc49c","unresolved":true,"context_lines":[{"line_number":254,"context_line":" │ the attachment to the requested vlan ID. In the  │"},{"line_number":255,"context_line":" │ event of a failure, the physical switch port     │"},{"line_number":256,"context_line":" │ is detached.                                     │"},{"line_number":257,"context_line":" └──────────────────────────────────────────────────┘"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Alternatives"},{"line_number":260,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"437cb788_3f6d3305","line":257,"updated":"2024-05-29 09:18:34.000000000","message":"aside: what did you use to generate this?","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":11655,"name":"Julia Kreger","email":"juliaashleykreger@gmail.com","username":"jkreger","status":"Flying to the moon with a Jetpack!"},"change_message_id":"744ad8698766ba23f9442685f52a7089e1b7b4d9","unresolved":true,"context_lines":[{"line_number":254,"context_line":" │ the attachment to the requested vlan ID. In the  │"},{"line_number":255,"context_line":" │ event of a failure, the physical switch port     │"},{"line_number":256,"context_line":" │ is detached.                                     │"},{"line_number":257,"context_line":" └──────────────────────────────────────────────────┘"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"Alternatives"},{"line_number":260,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"114a3fc1_73ff1f3d","line":257,"in_reply_to":"437cb788_3f6d3305","updated":"2024-05-31 23:32:45.000000000","message":"asciiflow","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"},{"author":{"_account_id":23851,"name":"Riccardo Pittau","email":"elfosardo@gmail.com","username":"elfosardo"},"change_message_id":"f590d22eae6373b00c65fda010868afe2b5eaf8e","unresolved":true,"context_lines":[{"line_number":264,"context_line":"address the underlying challenge of the attach/detach functionality"},{"line_number":265,"context_line":"being needed by Infrastructure Operators. It also introduces modeling which"},{"line_number":266,"context_line":"might not be suitable for bulk infrastucture operators as they would need"},{"line_number":267,"context_line":"to think and operate a cloud model, as opposed to the physical infrasructure"},{"line_number":268,"context_line":"model. Plus operating Neutron would require a database to be managed,"},{"line_number":269,"context_line":"increasing operational complexity, and state would also need to still"},{"line_number":270,"context_line":"be navigated which increases the configuration and code complexity based upon"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1b29118a_5a73e357","line":267,"range":{"start_line":267,"start_character":63,"end_line":267,"end_character":76},"updated":"2024-06-01 15:05:32.000000000","message":"nit: infrastructure","commit_id":"aa066b4174dc0453a9f16305c3b14653aa6967f3"}]}