)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"c4be81d79c63228fc1cd0fb0dd9f835006a3f541","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a50a5c6b_628a8f74","updated":"2026-07-21 18:36:40.000000000","message":"spec looks straight forward to me, please open BP in LP for trakcing purpose.","commit_id":"c30d6148c6c5ae2c8572afb8d2eeae409e52a7ee"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b8a8fa1b4e673fc87a1fc1d5d4213ac2b940f4db","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ac292244_d7a341bf","updated":"2026-07-22 18:37:24.000000000","message":"this lgtm, though name of spec/BP/commit msg can be changed to avoid confusion over this proxy API.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"222e5ed3523266646343ab4e1edb5b99c4ab8a3b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6ff9c685_bdabacdd","updated":"2026-07-22 13:27:08.000000000","message":"we do not recommend managing security groups via nova, you can suply a default set of security groups to use when nova creates the port but im inclied to say we should not contiue to extend the proxy api capaclites and if you want to use security groups with whitespace you ahould either pqss in neuton port that you have precreated or the security group uuid","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"a5c918d53bddb15ce157428cb9145b8a055b8617","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8b18c891_39cf3deb","in_reply_to":"3a499864_abb1084e","updated":"2026-07-23 17:51:50.000000000","message":"My only counterargument to Sean\u0027s points is that Nova does not manage/own the SG, so we should not add any management or validation layer in Nova itself and should instead rely on Neutron to do it.\n\nI am not against of validating leading/trailing whitespace in resource names, but I am against doing the same for resources managed by other services. For example, bug has a valid concern: a user created an SG with leading whitespace because Neutron allowed it, but Nova says it is not a valid SG; let\u0027s have Neutron tell us whether it is a valid SG or not.\n\nAbout Nova validation, if i can remember, it was added when we had nova-network and SG were managed by Nova but we forgot to remove it when nova-network was gone. Otherwise we would not have such validation for other service resources like volume, images etc.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"647866c644466e00070bcb1d2a2a3758c820f58f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"961289b9_b41c2880","in_reply_to":"46c24e25_f5e494a5","updated":"2026-07-23 15:33:08.000000000","message":"from my perspective we choose to strip trialing/leading whitespace to impvoe the ux of workign with securitgy groups and the stricter valiation done in 2.1 is intentional and not a bug.\n\ni dont think we shoudl reintoduce the ablitity to have security group names with triailing and leadign whitespace into nova. we change the behviro in 2.1 and folks have litrally had decades to adapt.\n\nleading and trailing whitespace is increatly hard to debug and very easy to get wrong when you are using a cli or gui.\n\nefectivly any non programatic usagne and even if you rusing somethin like ansible where you specyifng thisn in yaml files it a bad ux as \n\n`sg_name:  with_prefix` and `sg_name: \u0027 with_prefix\u0027`\nwill generally be parsed the same \n\nthe former with 2 spaces will be reformated by validator\nto remove the extra space since it will not be include din teh value when parsed\nso you are foced to add the quotes\n\n```\n---\nsg_name: \" with_prefix\"\n```\n\nto express this.\n\nwe have the same issue with bash ectra,\n\ni woudl still consider the ablity to decalre default secuity groups to fall under\n\nhttps://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-api-proxies\n\nwe have long held for better or worse that if you need to create a vm with a port that differs form how nova creates it by default that you shoudl pre-create the port and pass it in.\n\nthat why we do not supprot passing vnic types in the networks dict or subnets or qos.\n\nso to me this is exactly in the same boat.\n\nwe had a whole bunhc of pain with the host name filed when we finally started enfoceign the fact that nova never suproted passing fqdn in that filed\n\nhttps://github.com/openstack/nova-specs/blob/master/specs/2023.1/implemented/fqdn-in-hostname.rst\n\ni really dont think we shoudl be changign how process default security groups lightly and this does nto seem to be an impomvemetn form my presepctev but rather weaking validation we have had in place for over a decade.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"7796e935369b50faa5f7af22cdfcf71e8464e426","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"46c24e25_f5e494a5","in_reply_to":"6ef6502d_f8553aea","updated":"2026-07-23 05:59:12.000000000","message":"Acknowledged","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"f780c82c8f1537749e28af5763841ae135b864db","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f9a41c36_eaf7f5c3","in_reply_to":"6ff9c685_bdabacdd","updated":"2026-07-22 14:09:07.000000000","message":"Sean, thanks for the review, but I want to clarify the intent here because I\nthink this is being read as \"extend Nova\u0027s security-group proxy API\ncapabilities\", which isn\u0027t what this is.\n\nI\u0027m not proposing that Nova start managing security groups, and I\u0027m not\nasking to grow the proxy surface. This is a regression fix. Leading/trailing\nwhitespace in security_groups[].name used to be preserved for the legacy\nv2.0 API specifically, via a v2.0-only schema:\n\n  server_create_v20 \u003d copy.deepcopy(server_create)\n  server_create_v20[\u0027security_groups\u0027][\u0027items\u0027][\u0027properties\u0027][\u0027name\u0027] \u003d (\n      parameter_types.name_with_leading_trailing_spaces)\n\n  def get_server_create_schema(version):\n      if version \u003d\u003d \u00272.0\u0027:\n          return schema_security_groups.server_create_v20\n      return schema_security_groups.server_create\n\nThat dispatch (and the v2.0-specific schema) was removed in\n1f677061fa886f52426f5bea04aabac7244fabfa (\"Merge server create schema for\nsecurity group extension\", blueprint https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky). \nNothing in that commit message indicates an intent to change v2.0 compat-mode\nbehavior -- it reads like a side effect of the extension-schema dedup. Since\nthen, requesting X-OpenStack-Nova-API-Version: 2.0 no longer gets the\noriginal v2.0 semantics for this field; it silently gets the stricter v2.1+\nschema instead.\n\nSo the \"current v2.1 behavior\" and \"legacy v2.0 API\" this spec\u0027s own text\nsays match each other only match today because v2.0 compat mode has been\nbroken since 2018, not because that was ever the intended v2.0 contract.\n\nGhanshyam\u0027s earlier point (on 995073) was that a plain bugfix can\u0027t just be\napplied retroactively to v2.0/v2.1 -- if tooling has come to rely on the\ncurrent (broken) rejection behavior, changing it silently is still a\nbehavior change, hence the microversion, per policy. That\u0027s the only reason\nthis went through a spec at all -- not because I want to grow what Nova does\nwith security groups.\n\nI know the UUID and precreated-port paths exist and work today -- I use\nthem myself. That\u0027s not in question and this isn\u0027t proposing an alternative\nto them. It\u0027s specifically about restoring parity between what v2.0 used to\nguarantee for this field and what v2.0 compat mode actually does today,\nwithout silently changing behavior for existing callers on frozen\nmicroversions.\n\nHappy to add this history (with the commit reference) to the spec\u0027s\nProblem description if that makes the scope clearer.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"180f7a72d2e02d244a026a94074231978d031768","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ab992de3_11a39cd9","in_reply_to":"8b18c891_39cf3deb","updated":"2026-07-23 18:52:23.000000000","message":"i added neutron to the bug so they can access if this is really a neutorn api validation but which i think it is.\nunless i have miss it they are just doign a lenght check and allow any valid utf8 behound that includign non breaking whitespcae that you cant see.\n\ni think that is very much incorrect so if we were to change the validationin 2.105 i think we need neutron to agree that that is the only valid set.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"66043c1bf3424f693e645d94258d0e92542de80d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3a499864_abb1084e","in_reply_to":"961289b9_b41c2880","updated":"2026-07-23 16:27:46.000000000","message":"Acknowledged","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b8a8fa1b4e673fc87a1fc1d5d4213ac2b940f4db","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"6ef6502d_f8553aea","in_reply_to":"f9a41c36_eaf7f5c3","updated":"2026-07-22 18:37:24.000000000","message":"True, this is not \"extend Nova\u0027s security-group proxy API capabilities\"; even this is the other way around: \"Removing the extra things from Nova for proxy API and making it a pure proxy API\".\n\nNeutron allows leading/trailing name security groups, and Nova disallows that, which is an extra thing Nova does for SG proxy API and resources Neutron manages. Nova should not do any extra validation or management work for the resources owned/managed by Neutron, and this is what this change fixes.\n\nIf a user can create an SG with leading whitespace in Neutron, Nova should allow that to pass in the server create request and pass it to Neutron as it is.\n\nI think it\u0027s the name which is confusing, or will confuse us, that we improved the proxy API in Nova for doing more things. How about keeping the spec/BP and commit title to \"Match neutron\u0027s security group name as per neutron validation\" or something similar which convey that we are removing the extra things Nova did then adding.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"}],"specs/2027.1/approved/allow-secgroup-name-spaces.rst":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"c4be81d79c63228fc1cd0fb0dd9f835006a3f541","unresolved":true,"context_lines":[{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Allow security group names with leading/trailing spaces"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\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":"https://bugs.launchpad.net/nova/+bug/2158443"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Nova currently rejects requests to boot a server when the requested"},{"line_number":14,"context_line":"security group name has leading or trailing whitespace, even though"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1c11ca7b_44f01a42","line":11,"range":{"start_line":10,"start_character":0,"end_line":11,"end_character":44},"updated":"2026-07-21 18:36:40.000000000","message":"we also need a BP register in LP for tracking purpose, can you pleas open which should be same as the spec file name https://blueprints.launchpad.net/nova","commit_id":"c30d6148c6c5ae2c8572afb8d2eeae409e52a7ee"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"34604fe253ca70e5aa70ce789ccd79cd82c71663","unresolved":false,"context_lines":[{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Allow security group names with leading/trailing spaces"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\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":"https://bugs.launchpad.net/nova/+bug/2158443"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Nova currently rejects requests to boot a server when the requested"},{"line_number":14,"context_line":"security group name has leading or trailing whitespace, even though"}],"source_content_type":"text/x-rst","patch_set":1,"id":"70930366_831e4c39","line":11,"range":{"start_line":10,"start_character":0,"end_line":11,"end_character":44},"in_reply_to":"1c11ca7b_44f01a42","updated":"2026-07-22 07:08:26.000000000","message":"Done","commit_id":"c30d6148c6c5ae2c8572afb8d2eeae409e52a7ee"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b606694c5d917e00c59db76ba4a89371e2724115","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  Neutron to avoid leading/trailing spaces. This is not always possible"},{"line_number":74,"context_line":"  (the security group may be managed by another team or tool), and does"},{"line_number":75,"context_line":"  not address the underlying mismatch between Nova and Neutron"},{"line_number":76,"context_line":"  validation."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Silently strip leading/trailing spaces from the requested name before"},{"line_number":79,"context_line":"  matching against Neutron. This was rejected because it could cause"}],"source_content_type":"text/x-rst","patch_set":2,"id":"db5e3549_45c0aa6a","line":76,"updated":"2026-07-22 13:29:59.000000000","message":"i think this is the correct approch or to just use the neuton security group uuid not its name","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"7c1b95512bae8695fea8eecabc896bbda1d0f310","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  Neutron to avoid leading/trailing spaces. This is not always possible"},{"line_number":74,"context_line":"  (the security group may be managed by another team or tool), and does"},{"line_number":75,"context_line":"  not address the underlying mismatch between Nova and Neutron"},{"line_number":76,"context_line":"  validation."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Silently strip leading/trailing spaces from the requested name before"},{"line_number":79,"context_line":"  matching against Neutron. This was rejected because it could cause"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a94c3f0d_7c12bd9d","line":76,"in_reply_to":"82e8f944_a9238b8d","updated":"2026-07-23 16:23:44.000000000","message":"Understood, and thanks for the detail -- the RBAC/duplicate-name point (bug 2105896) is a good argument I hadn\u0027t considered, and I agree it cuts against widening name-based matching further.\n\nTo be clear on scope: I wasn\u0027t trying to settle the broader Nova/Neutron responsibility split here. The goal was to fix a bug affecting users in production (2158443), not to improve how Nova manages security groups in general.\n\nWhere does that leave 2158443 in practice? What I\u0027m taking from this thread is that the direction isn\u0027t really \"prefer UUID over name\" -- it\u0027s that passing security_groups on POST /servers at all (name or UUID) is a pattern Nova wants to move away from, in favor of always precreating the Neutron port with its security groups already attached, the same way IaC tooling should already be doing this. If that\u0027s the actual direction, then a docs change recommending UUID over name would be solving the wrong problem.\n\nThis has been in review for a few weeks now (995073 since June 26, this spec since July 20), and 2158443 is still open and still affecting users today. Given what you\u0027ve laid out, I want to make sure I land on something you and Ghanshyam will both actually approve, rather than another round-trip. So, concretely:\n\n1. Close 2158443 as won\u0027t-fix / opinion, with the documented guidance\n   being \"don\u0027t use security_groups on server create at all, precreate\n   the port instead\" -- not a UUID-vs-name framing?\n2. Something narrower that still helps people hitting this today without\n   going against the precreated-port direction?\n\nIs that an accurate summary of what you\u0027d want to see, and would that resolve your objection? I\u0027d rather get a concrete answer on that than keep iterating on the architecture question.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":38653,"name":"Sylvain Desgrais","email":"sylvain.desgrais@gmail.com","username":"artpej"},"change_message_id":"7796e935369b50faa5f7af22cdfcf71e8464e426","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  Neutron to avoid leading/trailing spaces. This is not always possible"},{"line_number":74,"context_line":"  (the security group may be managed by another team or tool), and does"},{"line_number":75,"context_line":"  not address the underlying mismatch between Nova and Neutron"},{"line_number":76,"context_line":"  validation."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Silently strip leading/trailing spaces from the requested name before"},{"line_number":79,"context_line":"  matching against Neutron. This was rejected because it could cause"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfee16a6_7567f283","line":76,"in_reply_to":"920684f0_ca08b1a3","updated":"2026-07-23 05:59:12.000000000","message":"Agreed, and glad we\u0027re converging. Two data points that back up \"we should\nfix name too\" rather than just steering everyone to UUID:\n\n1. The published api-ref doesn\u0027t document UUID as a valid value for\n   security_groups[].name at all -- it only documents name:\n\n     \"One or more security groups. Specify the name of the security group\n     in the name attribute. If you omit this attribute, the API creates\n     the server in the default security group.\"\n\n   (api-ref/source/parameters.yaml, security_groups). UUID support is a\n   real code path (parameter_types.name matches it, and\n   _get_security_group_ids() checks the UUID map first), but it\u0027s an\n   undocumented implementation detail, not part of the published contract.\n   Users following the docs have no way to know UUID is an option, let\n   alone \"the recommended\" one.\n\n2. terraform-provider-openstack actively moved the other way. Using UUIDs\n   for openstack_compute_instance_v2 security_groups is a known\n   non-idempotent footgun there (wontfix\u0027d as\n   terraform-provider-openstack#6, originally hashicorp/terraform#2009):\n   GET /servers/{id} always returns security_groups as names, never IDs,\n   so a config declared by UUID can never match the state read back, and\n   every plan/apply removes and re-adds the group. Their guidance ended up\n   being the opposite of \"prefer UUID\": use name, specifically because of\n   this read/write asymmetry in Nova\u0027s own API.\n\nSo \"recommend UUID\" runs into: it\u0027s not documented, and the one major\ntool that tried it hit a real bug caused by Nova only ever reporting\nsecurity groups by name on read. Fixing name (this spec) closes the gap\nwithout asking every caller to work around that asymmetry.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8499812d655b5e197ac029532127ae10b35632d1","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  Neutron to avoid leading/trailing spaces. This is not always possible"},{"line_number":74,"context_line":"  (the security group may be managed by another team or tool), and does"},{"line_number":75,"context_line":"  not address the underlying mismatch between Nova and Neutron"},{"line_number":76,"context_line":"  validation."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Silently strip leading/trailing spaces from the requested name before"},{"line_number":79,"context_line":"  matching against Neutron. This was rejected because it could cause"}],"source_content_type":"text/x-rst","patch_set":2,"id":"82e8f944_a9238b8d","line":76,"in_reply_to":"bfee16a6_7567f283","updated":"2026-07-23 15:18:20.000000000","message":"we are not converging\n\ni wasn not confusitng your propoal with extending the dedicate proxy api\n\nhttps://docs.openstack.org/api-ref/compute/#security-groups-os-security-groups-deprecated\n\ni was also object to extneding the ablity to pass with leadign or trailing whitespace in \n\nhttps://docs.openstack.org/api-ref/compute/#create-server\n\nreally i condier the fact that neutron acpate names with leadign and trailing whitespace to be a neutron api bug and my prefence woudl be fot fix that an dreject that in neutron\n\ni dont think we shoudl extend nova to allow that as it really careate a poor user expecince in may case such as manually passing the names in the cli or even copy pasting the output.\n\n\nUUID is prefered bcause of neutron rbac rules that allwo sharing security groups between project\n\nwhen we have a security group with the same name in two differnt proejct the uuid is the only way to disambiguate \n\nhttps://github.com/openstack/nova/commit/96a0b17c7cdd9e64c558b6f005ff2b260020cbe6\nhttps://bugs.launchpad.net/nova/+bug/2105896\n\nso its not even that UUIDs are recommended it that using the name is activly discourgage and i dont think we shoudl be exending the usage fo name in general.\nwe can fix the api docuemnation.\n\nnot that the securigy group on a server only apply to port created by nova when you pass --network aka when you populsate the network array with a list of netwok uuids. they are not applied to port you pass directly which has often lead to congution and why we do not advise mixing server security groups with neturon ports. \n\ntools like teriform shoudl effectivly never use the network uuid approch and shoudl alwasy create and mange the neutron ports directly as tehre are many other option such as slecting the relevent subent or the port vnic type, mac adress, qos ectra that can only be manged that way. its also the only way to support l3 routed network as an example.\n\nto be clear you shoudl never use nova api ot read security group related to a vm ports\n\nyou shoudl do that by listing the ports assocated with a vm and combining there security groups. in other word you shoudl alwasy use neutron not nova as the socue or truth for security groups.\n\nthe security gorups listed for a sever are only the defautl set that will be applie when nova first create a port but there is no expectation that they will be the same as what the port currently has as you can alwasy change them via neutron.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b8a8fa1b4e673fc87a1fc1d5d4213ac2b940f4db","unresolved":true,"context_lines":[{"line_number":73,"context_line":"  Neutron to avoid leading/trailing spaces. This is not always possible"},{"line_number":74,"context_line":"  (the security group may be managed by another team or tool), and does"},{"line_number":75,"context_line":"  not address the underlying mismatch between Nova and Neutron"},{"line_number":76,"context_line":"  validation."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Silently strip leading/trailing spaces from the requested name before"},{"line_number":79,"context_line":"  matching against Neutron. This was rejected because it could cause"}],"source_content_type":"text/x-rst","patch_set":2,"id":"920684f0_ca08b1a3","line":76,"in_reply_to":"db5e3549_45c0aa6a","updated":"2026-07-22 18:37:24.000000000","message":"using uuid is better (even recommended) way but as we allow using name also we should fix that too.","commit_id":"f7e731eb384d7d3ba5d759e420b5695e66b7ee6d"}]}