)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a3533127319dd031f00cb1ab5525639dc35f17bd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e67b051e_2bad7a15","updated":"2025-01-09 17:26:44.000000000","message":"i think this need wider discussion with the neutron team and other nova cores but this does not feel like it shoudl be in the scope of the nova api.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"f72caff86c595292ed8418d2d1696ab1ec85c73d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"1790a870_1fadf38e","updated":"2025-06-05 21:18:44.000000000","message":"I don\u0027t see any issues with this. We should definitely get sign-off from the neutron DFG but it seems a good UX improvement.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"906f0bf5_2a9067a1","updated":"2025-07-03 18:27:28.000000000","message":"Thanks for the comment. Updated the spec it\u0027s too late for the Flamingo spec freeze, though.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"349fabd9d8c1a6a7f5ed6237ac576c6524567798","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0b35ebe0_6d833ded","updated":"2025-06-03 08:24:30.000000000","message":"Thanks for the feedback.  I updated this spec following Flamingo PTG discussion.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"3603aac428e83a08278b5e8a27e3b930ac9f6196","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2197c40e_3a2b6bec","updated":"2025-06-23 19:58:56.000000000","message":"agree with DB comments given by gibi and sean but I added one more comment about returning network_id in server response.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5733b617f6a6c69f83c6f6b8de3725fc9f3e43a6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2cc695c4_67f87e7d","updated":"2025-06-20 11:58:31.000000000","message":"lets update this with the db schema changes required to do this effeicently","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"}],"specs/2025.1/approved/network-id-query.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a3533127319dd031f00cb1ab5525639dc35f17bd","unresolved":true,"context_lines":[{"line_number":28,"context_line":"The problem of this operation is when the target network has lots of ports"},{"line_number":29,"context_line":"due to its wide IP range, for example 2,000 IP address by 10.0.0.0/8 subnet,"},{"line_number":30,"context_line":"cloud users must call 2,000 API call at the step2. This lots of API call"},{"line_number":31,"context_line":"causes high workload at Nova API side, too."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":2,"id":"8b5f4ea2_a6525488","line":31,"updated":"2025-01-09 17:26:44.000000000","message":"this is very close to running afoul of https://docs.openstack.org/nova/latest/contributor/project-scope.html#no-more-api-proxies\n\nif we were to enable this we would eventually be asked to allow filtering\nby neutron subnet or network segment, or qos policy or physnet.\nIf we do this for neutron, we would then have to do the same for other services, like listing all services with a given cinder volume type designated domain.\n\ni understand the performance issue your raising with the need to make many sperate rest calls, im not personaly convencie that we shoudl add this type of filtering to the nova api based on atribute of resouce in other serices that just happen to be attached to a nova instace.\n\n\nfor exmple we just add suppropt in nova for attahcing a manilla share to an instnace. but in doing that we did not add the ablity to list instance by manilla share.  we also did not add that capablity when we intoroduces supprot for multi attached volumes in cidner/nova.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"349fabd9d8c1a6a7f5ed6237ac576c6524567798","unresolved":false,"context_lines":[{"line_number":28,"context_line":"The problem of this operation is when the target network has lots of ports"},{"line_number":29,"context_line":"due to its wide IP range, for example 2,000 IP address by 10.0.0.0/8 subnet,"},{"line_number":30,"context_line":"cloud users must call 2,000 API call at the step2. This lots of API call"},{"line_number":31,"context_line":"causes high workload at Nova API side, too."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":2,"id":"051f3b4d_dce6d4f8","line":31,"in_reply_to":"86505aab_cc98a021","updated":"2025-06-03 08:24:30.000000000","message":"Updated the spec following Flamingo PTG discussion result.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"72c71fc47fdbbf6f1efc3ef37fc423390937d827","unresolved":true,"context_lines":[{"line_number":28,"context_line":"The problem of this operation is when the target network has lots of ports"},{"line_number":29,"context_line":"due to its wide IP range, for example 2,000 IP address by 10.0.0.0/8 subnet,"},{"line_number":30,"context_line":"cloud users must call 2,000 API call at the step2. This lots of API call"},{"line_number":31,"context_line":"causes high workload at Nova API side, too."},{"line_number":32,"context_line":""},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":2,"id":"86505aab_cc98a021","line":31,"in_reply_to":"8b5f4ea2_a6525488","updated":"2025-02-22 02:13:09.000000000","message":"\u003e if we were to enable this we would eventually be asked to allow filtering\n\u003e by neutron subnet or network segment, or qos policy or physnet.\n\u003e If we do this for neutron, we would then have to do the same for other services, like listing all services with a given cinder volume type designated domain.\n\nI really understand the concern. The network_id is just one of many attributes comes from other services.  If time is allowed, I\u0027d like to put this topic on the next ptg table the nova doesn\u0027t proxy any other service\u0027s attributes in Nova\u0027s API layer.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a3533127319dd031f00cb1ab5525639dc35f17bd","unresolved":true,"context_lines":[{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a request, nova-api calls network API"},{"line_number":55,"context_line":"to fetch instance id list which are connected to the specified network id."},{"line_number":56,"context_line":"Then the instance id list is added to the filters for the instance list"},{"line_number":57,"context_line":"query."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"In case of neutron network api, nova-api calls the list port API with"},{"line_number":60,"context_line":"network_id query and required response is ``device_id``.  The ``device_id``"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dedca1cf_11fcc4d0","line":57,"range":{"start_line":54,"start_character":0,"end_line":57,"end_character":6},"updated":"2025-01-09 17:26:44.000000000","message":"that is one option, the other would have been to use the network info cache in the cell db, or the requested network in the request spec perhaps.\n\nthe api call is simpler i guess although it obviouly means the server list could fail if neuton was temperoaly unaviablie.\n\n\nthe other factor here is if we were to call the neutron rest API we need to ensure that we do so with the users token so that rbac is enfoced properly.\n\nthat raises the question of how this shoudl work if you also pass all_tenants\n\n\nas a n admin if you passed both a neutron network uuid and all_tenants we would need to ensure we could see all port on a network even if it shared between multiple projects using neutron RBAC or is marked external or globally shared.\n\ni dont know if the neutorn port list api can supprot a cross tenant list the way nova does.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"349fabd9d8c1a6a7f5ed6237ac576c6524567798","unresolved":false,"context_lines":[{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a request, nova-api calls network API"},{"line_number":55,"context_line":"to fetch instance id list which are connected to the specified network id."},{"line_number":56,"context_line":"Then the instance id list is added to the filters for the instance list"},{"line_number":57,"context_line":"query."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"In case of neutron network api, nova-api calls the list port API with"},{"line_number":60,"context_line":"network_id query and required response is ``device_id``.  The ``device_id``"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ca3b0373_932e458e","line":57,"range":{"start_line":54,"start_character":0,"end_line":57,"end_character":6},"in_reply_to":"cf4ebf6a_328d4cd3","updated":"2025-06-03 08:24:30.000000000","message":"Update to use virtual_interfaces table which is Nova internal information instead of Neutron API information.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"72c71fc47fdbbf6f1efc3ef37fc423390937d827","unresolved":true,"context_lines":[{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a request, nova-api calls network API"},{"line_number":55,"context_line":"to fetch instance id list which are connected to the specified network id."},{"line_number":56,"context_line":"Then the instance id list is added to the filters for the instance list"},{"line_number":57,"context_line":"query."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"In case of neutron network api, nova-api calls the list port API with"},{"line_number":60,"context_line":"network_id query and required response is ``device_id``.  The ``device_id``"}],"source_content_type":"text/x-rst","patch_set":2,"id":"cf4ebf6a_328d4cd3","line":57,"range":{"start_line":54,"start_character":0,"end_line":57,"end_character":6},"in_reply_to":"dedca1cf_11fcc4d0","updated":"2025-02-22 02:13:09.000000000","message":"Thanks for the feedback. Let me dive into the network info cache contents if the info cache has alternative key data for the querying.  I completely agree the Neutron API down situation problem, and I guess it\u0027s one of technical reason Nova api is no more api proxy to another service.","commit_id":"853889409450b89bfee9a932b740d70c5b1de0c2"}],"specs/2025.2/approved/network-id-query.rst":[{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"3603aac428e83a08278b5e8a27e3b930ac9f6196","unresolved":true,"context_lines":[{"line_number":34,"context_line":"Use Cases"},{"line_number":35,"context_line":"---------"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"- As a cloud user, I want to filter my project\u0027s servers basing on attached"},{"line_number":38,"context_line":"  network."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"- As a cloud admin, I want to check server details attached to a specific"},{"line_number":41,"context_line":"  network."}],"source_content_type":"text/x-rst","patch_set":3,"id":"6100ed67_bcec31dd","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":10},"updated":"2025-06-23 19:58:56.000000000","message":"will new filter network_id be available to non-admin user also? if so it will be good to mention the same in spec.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":false,"context_lines":[{"line_number":34,"context_line":"Use Cases"},{"line_number":35,"context_line":"---------"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"- As a cloud user, I want to filter my project\u0027s servers basing on attached"},{"line_number":38,"context_line":"  network."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"- As a cloud admin, I want to check server details attached to a specific"},{"line_number":41,"context_line":"  network."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e7e4f73f_2fa01762","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":10},"in_reply_to":"6100ed67_bcec31dd","updated":"2025-07-03 18:27:28.000000000","message":"Done","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"3603aac428e83a08278b5e8a27e3b930ac9f6196","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Code changes"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This change introduces a new query parameter, ``network_id`` query, to the"},{"line_number":50,"context_line":"``GET /servers`` API and the ``GET /servers/detail`` API. If the"},{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a API request, nova-api uses ``network_id``"},{"line_number":55,"context_line":"column and ``instance_uuid`` column of the ``virtual_interfaces`` table to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"68ea1a74_60e27367","line":52,"range":{"start_line":49,"start_character":0,"end_line":52,"end_character":34},"updated":"2025-06-23 19:58:56.000000000","message":"As Nova will allow filter servers by network_id, I am wondering if GET server should show the network_id in server response also?\n\nAs per current proposed change, if user want to list all servers attached to network of their server they still need to get the network_ids from neutron and search nova for all network_ids (until they find their server attached to that network). If we want to make this use case also easy, what if nova return network_id in server response and user can simply search servers in nova with that network_id filter?\n\nI am just thinking about making the workflow easy for users but no strong opinion on this. Let\u0027s see other\u0027s opinion on this.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a30027fe78997ed2989b052e02dc62fa208b572","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Code changes"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This change introduces a new query parameter, ``network_id`` query, to the"},{"line_number":50,"context_line":"``GET /servers`` API and the ``GET /servers/detail`` API. If the"},{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a API request, nova-api uses ``network_id``"},{"line_number":55,"context_line":"column and ``instance_uuid`` column of the ``virtual_interfaces`` table to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8e41b1ce_784b7bef","line":52,"range":{"start_line":49,"start_character":0,"end_line":52,"end_character":34},"in_reply_to":"68ea1a74_60e27367","updated":"2025-06-30 19:51:40.000000000","message":"i think it shoudl and specificly i think we shoudl be using the netwrok uuid not the netwrok name in the adresses filed as the key.\n\nbut i dont know if we need to do that in this spec.\n\ni was ok with only adding it as a query arge for now and not modifying the server show responce.\n\nideally i woudl like to upstede server show and detail list so that the adress dict\n\nis nolovner \n\n```\n \"addresses\": {\n            \"private\": [\n                {\n                    \"addr\": \"192.168.1.30\",\n                    \"OS-EXT-IPS-MAC:mac_addr\": \"00:0c:29:0d:11:74\",\n                    \"OS-EXT-IPS:type\": \"fixed\",\n                    \"version\": 4\n                }\n            ]\n        },\n        \n```\n\nbut rather\n```\n \"addresses\": {\n            \"\u003cnetwork uuid\u003e\": [\n                {\n                    \"addr\": \"192.168.1.30\",\n                    \"OS-EXT-IPS-MAC:mac_addr\": \"00:0c:29:0d:11:74\",\n                    \"OS-EXT-IPS:type\": \"fixed\",\n                    \"version\": 4\n                    \"port_uuid\": \u003cport uuid\u003e\n                    \"network_name\": \"private\"\n                }\n            ]\n        },\n```\n\nthat or remove that feild entirlly adn do this instead\n```\n \"ports\": {\n            \"\u003cport uuid\u003e\": [\n                {\n                    \"addr\": \"192.168.1.30\",\n                    \"OS-EXT-IPS-MAC:mac_addr\": \"00:0c:29:0d:11:74\",\n                    \"OS-EXT-IPS:type\": \"fixed\",\n                    \"version\": 4\n                    \"network_uuid\": \u003cport uuid\u003e\n                    \"network_name\": \"private\"\n                }\n            ]\n        },\n\n\n```\n\nso each ports woudl be a map of port uuid to adress info which is a list of adres with the network uuid/name embeded wioth the type of adress adn teh adress ectra.\n\n\nthat way we keep the existing info available, add the network and port uuids and overall make this api more usable\n\nThat woudl need a new microversion, and it changes the scope fo this spec enough that I\u0027m not sure its reasonabel to ask for that to be included in this spec.\n\ni think either impovemnt woudl be a major ux win and i prefer the ports approhc because really that is the api resouce we are adding/removing not addresses.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":true,"context_lines":[{"line_number":46,"context_line":"Code changes"},{"line_number":47,"context_line":"------------"},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"This change introduces a new query parameter, ``network_id`` query, to the"},{"line_number":50,"context_line":"``GET /servers`` API and the ``GET /servers/detail`` API. If the"},{"line_number":51,"context_line":"``network_id`` query param is specified, the two APIs return server list"},{"line_number":52,"context_line":"attached to the requested network."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"When the ``network_id`` query is in a API request, nova-api uses ``network_id``"},{"line_number":55,"context_line":"column and ``instance_uuid`` column of the ``virtual_interfaces`` table to"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b3be2f7b_92048592","line":52,"range":{"start_line":49,"start_character":0,"end_line":52,"end_character":34},"in_reply_to":"8e41b1ce_784b7bef","updated":"2025-07-03 18:27:28.000000000","message":"Updating server show response body seems to be too much change for this spec. If it\u0027s okay I want to skip the response body change. As I commented the use case, user of this query knows the network_id already.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"443b8954065aaba5d6470c79d1e5406780673372","unresolved":true,"context_lines":[{"line_number":56,"context_line":"make DB query getting all instances connected to the requested ``network_id``"},{"line_number":57,"context_line":"by the API query. The ``instance_get_all_by_filters_sort`` method in"},{"line_number":58,"context_line":"nova.db.main.api adds extra filters to db query to filter instances attaching"},{"line_number":59,"context_line":"to a specific network."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The ``virtual_interfaces`` table has ``network_id`` column but it\u0027s not"},{"line_number":62,"context_line":"updated. This change also updates"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baf70007_ca443457","line":59,"updated":"2025-06-03 08:30:25.000000000","message":"For the query implementation, I\u0027m wondering which is better because of performance reason.  I need nova team\u0027s opinion, but let me implement first poc code using either of following.\n\n1. using table join using instance_uuid: `query_prefix.join(models.VirtualInterfaces.instance_uuid)\n query_prefix.filter(models.VirtualInterfaces.network_id \u003d\u003d network_id`)\n2. using uuid list filtering: `query_prefix \u003d query_prefix.filter(~models.Instance.uuid.in_(subq))`","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7c3a6b8df297d65a7c78b2b2478244fa92e27583","unresolved":true,"context_lines":[{"line_number":56,"context_line":"make DB query getting all instances connected to the requested ``network_id``"},{"line_number":57,"context_line":"by the API query. The ``instance_get_all_by_filters_sort`` method in"},{"line_number":58,"context_line":"nova.db.main.api adds extra filters to db query to filter instances attaching"},{"line_number":59,"context_line":"to a specific network."},{"line_number":60,"context_line":""},{"line_number":61,"context_line":"The ``virtual_interfaces`` table has ``network_id`` column but it\u0027s not"},{"line_number":62,"context_line":"updated. This change also updates"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0d39617a_51b39938","line":59,"in_reply_to":"baf70007_ca443457","updated":"2025-06-03 11:29:15.000000000","message":"We use an ORM and in most cases the actual query plan for a join vs subquery will be optimised to the same execution plan in MySQL if it\u0027s a simple join of 2 tables.\n\nthis level of detail can be adressed in the actual implemation review.\n\nwe use sqlachemy 2.0 + now so following ther join on example \n\nhttps://docs.sqlalchemy.org/en/20/orm/queryguide/select.html#joins-to-a-target-with-an-on-clause\n\n```\nquery_prefix.join(models.VirtualInterfaces.instance_uuid, models.VirtualInterfaces.network_id \u003d\u003d network_id)\n```\n\nto ensure the the on  considtion rather then where condition is used to expres the join constraint.\n\nalthough sqlachmey can sometime just infer the on condtion fro you if the correct releationship are express in teh model \n\nhttps://docs.sqlalchemy.org/en/20/orm/queryguide/select.html#joins-to-a-target-entity\n\nto do a subquery  which is your option 2 you woudl generally expres that as a join_from statement rather then a join.\n\nhttps://docs.sqlalchemy.org/en/20/core/selectable.html#sqlalchemy.sql.expression.Select.join_from\n\nas i said above the exact query and be left to the implementation review.\n\n\n\nin this speciifc case the virtual_intefaces table is defied as follwos\n```\nclass VirtualInterface(BASE, NovaBase, models.SoftDeleteMixin):\n    \"\"\"Represents a virtual interface on an instance.\"\"\"\n    __tablename__ \u003d \u0027virtual_interfaces\u0027\n    __table_args__ \u003d (\n        schema.UniqueConstraint(\"address\", \"deleted\",\n                        name\u003d\"uniq_virtual_interfaces0address0deleted\"),\n        sa.Index(\u0027virtual_interfaces_network_id_idx\u0027, \u0027network_id\u0027),\n        sa.Index(\u0027virtual_interfaces_instance_uuid_fkey\u0027, \u0027instance_uuid\u0027),\n        sa.Index(\u0027virtual_interfaces_uuid_idx\u0027, \u0027uuid\u0027),\n    )\n    id \u003d sa.Column(sa.Integer, primary_key\u003dTrue, nullable\u003dFalse)\n    address \u003d sa.Column(sa.String(255))\n    network_id \u003d sa.Column(sa.Integer)\n    instance_uuid \u003d sa.Column(sa.String(36), sa.ForeignKey(\u0027instances.uuid\u0027))\n    uuid \u003d sa.Column(sa.String(36))\n    tag \u003d sa.Column(sa.String(255))\n\n```\n\nhttps://github.com/openstack/nova/blob/master/nova/db/main/models.py#L942-L957\n\nso the actual query we will want is somting like this\n\n```\nselect i.* from instances as i join virtual_interfaces as vi on i.uuid \u003d\u003d vi.instance_uuid where vi.network_id \u003d \"relevent netowrk id\"\n```\n\nso this shoudl really be implemented as a new method on the instance object\n\nrather then an extesion fo instance_get_all_by_filters_sort sice we can and shoud do all the filterign in the db.\n\nwe also should make sure to implement scatter gather to run this over all cell dbs concurrently.\n\ni.e. like instance_get_all_uuids_by_hosts i think it make sense to add a optimised query for this rhather then builcing on the very generic instance_get_all_by_filters_sort.\nhttps://github.com/openstack/nova/blob/master/nova/db/main/api.py#L2175-L2198\n\nalthough other might perfer that you resue that.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"845a97653335df9877eb3ffe46b1b5bb0d594a77","unresolved":true,"context_lines":[{"line_number":62,"context_line":"updated. This change also updates"},{"line_number":63,"context_line":"``nova.network.neutron.API._update_port_for_instance`` method to store"},{"line_number":64,"context_line":"VIF network id information to ``virtual_interface`` table through"},{"line_number":65,"context_line":"``VirtualInterface`` object."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Both openstack client and openstack sdk is also updated to support the new"},{"line_number":68,"context_line":"query parameter."}],"source_content_type":"text/x-rst","patch_set":3,"id":"88f46d12_dc4872f6","line":65,"updated":"2025-06-20 10:35:17.000000000","message":"What will happen with the already existing VMs. How do you plan to populate the missing data for them?","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":true,"context_lines":[{"line_number":62,"context_line":"updated. This change also updates"},{"line_number":63,"context_line":"``nova.network.neutron.API._update_port_for_instance`` method to store"},{"line_number":64,"context_line":"VIF network id information to ``virtual_interface`` table through"},{"line_number":65,"context_line":"``VirtualInterface`` object."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Both openstack client and openstack sdk is also updated to support the new"},{"line_number":68,"context_line":"query parameter."}],"source_content_type":"text/x-rst","patch_set":3,"id":"2fd06c47_f185358f","line":65,"in_reply_to":"88f46d12_dc4872f6","updated":"2025-07-03 18:27:28.000000000","message":"Yeah, I also hit the same question while I\u0027m implementing a PoC commit.  I have following 3 options in my mind and option 1 seems to be Nova-ish approach because it supports compute\u0027s upgrading and it doesn\u0027t need any extra upgrade efforts. The new revision mentions option1.\n\nWhat do you think?\n\n- option1: Keep updating the virtual_interface objects in `update_instance_cache_with_nw_info` or `get_network_info` in neutron.py because it\u0027s called by nova-compute\u0027s `_heal_instance_info_cache` periodic task.\n- option2: Set network_id information in alembic upgrade by getting network id from neutron API.\n- option3: Implement 1 nova-manage CLI only to add network id to DB.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"845a97653335df9877eb3ffe46b1b5bb0d594a77","unresolved":true,"context_lines":[{"line_number":85,"context_line":"This change needs network_id column type change from Integer to String(36) at"},{"line_number":86,"context_line":"``network_id`` column in virtual_interfaces table. As described in the"},{"line_number":87,"context_line":"proposed change section, the ``network_id`` column is not used. This change"},{"line_number":88,"context_line":"is not supposed to have any impact for upgrade."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"88131605_7020342c","line":88,"updated":"2025-06-20 10:35:17.000000000","message":"This is still a database schema migration isn\u0027t it? We just don\u0027t need to do data migration along with it.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"5733b617f6a6c69f83c6f6b8de3725fc9f3e43a6","unresolved":true,"context_lines":[{"line_number":85,"context_line":"This change needs network_id column type change from Integer to String(36) at"},{"line_number":86,"context_line":"``network_id`` column in virtual_interfaces table. As described in the"},{"line_number":87,"context_line":"proposed change section, the ``network_id`` column is not used. This change"},{"line_number":88,"context_line":"is not supposed to have any impact for upgrade."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"cb1a6993_cb7d4adf","line":88,"in_reply_to":"88131605_7020342c","updated":"2025-06-20 11:58:31.000000000","message":"we are not normally allowed to change colume data types in place.\n\nwe can only do that by addign a new column migrating the data and then droping the old column. that also need to happen over multiple upstream releases.\n\nit might be ok to cheat and do that this time only because this field is currently never written and never used in the code out side of tests.\n\n\nSo if we wanted to do this, we would have to add a network_uuid field.\n\nI\u0027m honestly surprised this is an int index \nThat means wherever we intened to use this  we would need to combine it with a different data structure. \n\nwhich would have needed to be the network info object but that is sotred in a json blob and means that combintion woudl have to be doen in python which would suck for perfroamnce.\n\n\nif we look at fill_virtual_interface_list\n\n https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L156\n\nwe try to use the network info cache.\n\nbut we dont set the network_id at all https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L169-L178\n\nnetwork id is used in one place\n\nget_by_instance_and_network\n\nhttps://github.com/openstack/nova/blob/41773f8c6515021eb037e6d9d385b34e89191c8c/nova/objects/virtual_interface.py#L91C9-L91C37\n\nbut that is only used in test code\n\nhttps://github.com/search?q\u003drepo%3Aopenstack/nova%20get_by_instance_and_network\u0026type\u003dcode\n\nso as far as i can tell the network_id is currently never populated and not used by any real code\n\nso the best path forward would be to add a new colum and a db migration to back file it form the vif object in the network info cache.\n\n\nthe network info cache is just a list of vif objects\nhttps://github.com/openstack/nova/blob/master/nova/network/model.py#L521-L538\neach vif object has a netowrk object\nhttps://github.com/openstack/nova/blob/master/nova/network/model.py#L421\nand that has an id field with is the neutron network uuid\nhttps://github.com/openstack/nova/blob/master/nova/network/model.py#L360\n\nso like the orginal fill_virtual_interface_list migration you can extract the netowrk id form teh json blob in the network info cace and add it to the virtual interfaces tabel in a new network_uuid field.\n\nwe could also drop the exisitng network_id via an optional contraction migration","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":false,"context_lines":[{"line_number":85,"context_line":"This change needs network_id column type change from Integer to String(36) at"},{"line_number":86,"context_line":"``network_id`` column in virtual_interfaces table. As described in the"},{"line_number":87,"context_line":"proposed change section, the ``network_id`` column is not used. This change"},{"line_number":88,"context_line":"is not supposed to have any impact for upgrade."},{"line_number":89,"context_line":""},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"REST API impact"}],"source_content_type":"text/x-rst","patch_set":3,"id":"30f565d5_c822125f","line":88,"in_reply_to":"cb1a6993_cb7d4adf","updated":"2025-07-03 18:27:28.000000000","message":"I see. I didn\u0027t know the common schema update approach.\n\nLet me revise it to add new column instead of updating column definition.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"3603aac428e83a08278b5e8a27e3b930ac9f6196","unresolved":true,"context_lines":[{"line_number":208,"context_line":""},{"line_number":209,"context_line":"   * - Release Name"},{"line_number":210,"context_line":"     - Description"},{"line_number":211,"context_line":"   * - 2025.1 Epoxy"},{"line_number":212,"context_line":"     - Introduced"},{"line_number":213,"context_line":"   * - 2025.2 Flamingo"},{"line_number":214,"context_line":"     - Re-proposed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"6a22c78f_eb8fe359","line":212,"range":{"start_line":211,"start_character":0,"end_line":212,"end_character":17},"updated":"2025-06-23 19:58:56.000000000","message":"is this typo as I could not find this spec merged in Epoxy https://specs.openstack.org/openstack/nova-specs/specs/2025.1/index.html\n\nJust to clarify, we consider spec \u0027Introduced\u0027 when it is merged.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"3a30027fe78997ed2989b052e02dc62fa208b572","unresolved":true,"context_lines":[{"line_number":208,"context_line":""},{"line_number":209,"context_line":"   * - Release Name"},{"line_number":210,"context_line":"     - Description"},{"line_number":211,"context_line":"   * - 2025.1 Epoxy"},{"line_number":212,"context_line":"     - Introduced"},{"line_number":213,"context_line":"   * - 2025.2 Flamingo"},{"line_number":214,"context_line":"     - Re-proposed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f3ad2616_37ec0043","line":212,"range":{"start_line":211,"start_character":0,"end_line":212,"end_character":17},"in_reply_to":"6a22c78f_eb8fe359","updated":"2025-06-30 19:51:40.000000000","message":"we also used Introduced even if its has not been merged but we dont enforce that either way.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3fdb5936a678a09b8958834104591a86e63da541","unresolved":false,"context_lines":[{"line_number":208,"context_line":""},{"line_number":209,"context_line":"   * - Release Name"},{"line_number":210,"context_line":"     - Description"},{"line_number":211,"context_line":"   * - 2025.1 Epoxy"},{"line_number":212,"context_line":"     - Introduced"},{"line_number":213,"context_line":"   * - 2025.2 Flamingo"},{"line_number":214,"context_line":"     - Re-proposed"}],"source_content_type":"text/x-rst","patch_set":3,"id":"85d1d131_1521d416","line":212,"range":{"start_line":211,"start_character":0,"end_line":212,"end_character":17},"in_reply_to":"f3ad2616_37ec0043","updated":"2025-07-03 18:27:28.000000000","message":"It may confuse anyone who read the spec after getting merged. Let me remove the Epoxy part. Due to the spec freeze, I need to submit this again to G. haha.","commit_id":"3fab7d808be8ceed92c6e6be9d04d1b31d56b85f"}]}