)]}'
{"/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":"201367f2868216899d994194cd03d58d166ce5c8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"90e2ca12_74214ef4","updated":"2026-05-11 19:43:35.000000000","message":"We should make sure we cover the Ironic API (RBAC) + Nova API (provisioning) case -- e.g. automated_lessee/node.owner plus use of Nova. The more concerning thing is the 100:1 suggested conductor mapping -- this is massively wrong based on all my operational experience. I\u0027d be interested to hear if this is a typo or really a complete mismatch of our opinions on how far conductors scale.","commit_id":"b7381f00a41df44293ef8d8e44f3a1bcf1ee574c"},{"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":"f42697542aa81b2eae0ad85debc9154a5a52ce27","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"af42e1cd_f0ecd43d","updated":"2026-07-07 17:04:43.000000000","message":"will re-add ironic-week-prio when outstanding comments are addressed","commit_id":"b7381f00a41df44293ef8d8e44f3a1bcf1ee574c"}],"doc/source/install/deployment-scenarios.rst":[{"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":"201367f2868216899d994194cd03d58d166ce5c8","unresolved":true,"context_lines":[{"line_number":35,"context_line":"   * - :ref:`deploy-scenarios-full-openstack`"},{"line_number":36,"context_line":"     - 1 node to multiple datacenters"},{"line_number":37,"context_line":"     - Yes (native)"},{"line_number":38,"context_line":"     - Nova Compute API"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":".. _deploy-scenarios-standalone:"},{"line_number":41,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"01800a48_64f7a5f6","line":38,"updated":"2026-05-11 19:43:35.000000000","message":"This should be broken down into two sections, I suspect:\n\nNova (hidden Ironic API)\n- doesn\u0027t use automatic_lessee\n- treats Ironic as a \"system\" API rather than a user api\n\nNova (public Ironic API)\n- uses automatic_lessee, maybe node.owner to permit some access to ironic API\n- allows self-service administration AND multitenancy","commit_id":"b7381f00a41df44293ef8d8e44f3a1bcf1ee574c"},{"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":"201367f2868216899d994194cd03d58d166ce5c8","unresolved":true,"context_lines":[{"line_number":59,"context_line":"that without pulling in the rest of OpenStack."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The :ref:`recommended target \u003crefarch-conductor-scaling\u003e` is up to 100 bare"},{"line_number":62,"context_line":"metal nodes per conductor for reliability and performance, which makes"},{"line_number":63,"context_line":"standalone a comfortable fit for smaller deployments. Beyond that scale, or"},{"line_number":64,"context_line":"when multi-tenancy becomes a requirement, the OpenStack scenarios below are"},{"line_number":65,"context_line":"the right path."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9088a527_63644f7e","line":62,"updated":"2026-05-11 19:43:35.000000000","message":"This has to be wrong. We scale WAY more than 100 nodes per conductor? I am -1 to documenting to run 1:100 ratio of conductors. My downstream operates more at a 1:400 ratio and we perform more rebuilds/reprovisions than the average cluster. This seems off by maybe an order of magnitude -- 1000:1 makes more sense to me than 100:1.","commit_id":"b7381f00a41df44293ef8d8e44f3a1bcf1ee574c"},{"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":"201367f2868216899d994194cd03d58d166ce5c8","unresolved":true,"context_lines":[{"line_number":109,"context_line":"This configuration scales from a handful of nodes up to a large deployment."},{"line_number":110,"context_line":"It can be installed with any standard OpenStack deployment tool —"},{"line_number":111,"context_line":"Kolla-Ansible, OpenStack-Ansible, and OpenStack Helm all work here. See"},{"line_number":112,"context_line":":doc:`configure-integration` for the OpenStack service integration setup."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"If you need users to provision bare metal without knowing or caring which"},{"line_number":115,"context_line":"specific node they get, read on."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9e71affc_d7382392","line":112,"updated":"2026-05-11 19:43:35.000000000","message":"We should mention you can mix-and-match: have one project exposed via nova, others managed directly via Ironic. I know we\u0027re trying to simplify here but it might be worth having a \"mix and match\" section that covers the weird cases like this one. I think there\u0027s a lot of things where we have this mix (e.g. even mixing up network models: you can have some nodes flat; some using neutron or ironic-networking)","commit_id":"b7381f00a41df44293ef8d8e44f3a1bcf1ee574c"}]}