)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"34bc04996cbaed11139bb4bc8ae38f0c5bae636a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"d7d36f2d_01ee2391","updated":"2023-08-16 15:01:04.000000000","message":"Hello Folks,","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"7c421fd4215df77cb4f2246a216ad8635b091c83","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8a79ffaa_6bcb71b2","updated":"2024-01-10 17:38:42.000000000","message":"I totally missed that blueprint when going with pretty much same one: https://review.opendev.org/c/openstack/nova-specs/+/900296\n\nIt feels they\u0027re serving the exact same purpose/idea, so I will abandon mine in favor of this one.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2e7ebb8ea1bc715f6b15f141b58fc127e9e7165d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"bb6161f2_d36eb1b0","in_reply_to":"02fdb45f_47643e52","updated":"2024-07-08 11:01:46.000000000","message":"so both approaches stalled out last time because there was no communication between the two efforts and then the implementations did not progress.\n\nwe are also at spec freeze again this cycle.\n\nDmitriy, it would be ideal if you and the autor of this spec \ncould agree to proceed with i assume this sepc since the other is abandoned and include the  usecase for both so we can have a singel solution to solve both of your problem statements.\n\nthe dalmation schdule has the nova spec freeze on the 18th of july so Thursday week.\nhttps://releases.openstack.org/dalmatian/schedule.html#nova-spec-freeze\n\nwe do potentially still have time to do this cycle but that window is rapidly closeing.\n\n\nboht this spec and https://review.opendev.org/c/openstack/nova-specs/+/900296/5/specs/2024.1/approved/cross-az-instance-scheduling.rst were kind of hand wavey on exactly how the proposed implementation woudl look like.\n\nthe intent of a spec is to capture all the input that go into making an desion on the design of a feature an the usecause it is inteded to support such that if the orgianl author could not implemtent it someone with familariaty with nova could.\nit serves as a contract/specification for the maintainer and operators to know the intent of the change so that we can preserve that and use the feature within that scoep of intent.\n\n\nmy main question is should this really be hard affintiy/antiaffinty implemented in a filter or shoudl it be soft implemeted in a weigher. i feel like if we are adding this we shoudl do it in both.\n\nAZ are much less problematic to implment hard affinity or anti affintiy since it does not genrelaly break move operations  given AZ are typically more then 1 host\n\nas such the need for a weigher is signifcanlty reduced.\n\nif we do not have a usecase for soft affinity i would ike to see the weigher approch listed as an alternitive and state that in the spec. basically capturing that we considerd this but that it was considerd out of scope for the stated usecases.\n\ni bring this up because of the presence of max_server_per_zone which adds partial soft anti-affinity in a slightly more annoying way ux-wise so i want to confirm we do not need the weigher approch.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"5a483d4d7929959c74c2af9629a1186870428ab4","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"02fdb45f_47643e52","in_reply_to":"8a79ffaa_6bcb71b2","updated":"2024-07-08 10:21:19.000000000","message":"Ok, I think I was wrong, and https://review.opendev.org/c/openstack/nova-specs/+/900296 is actually quite complimentary to this one.\n\nAs while here discussion is about scheduler filtering - it does not give any control to the user.\nBut what I would agree, is that having filtering working, should make more trivial to implement server group policies...\n\n\nAlso, I\u0027d say this might be really a good alternative implementation of https://review.opendev.org/c/openstack/octavia/+/923571/ for the Octavia as well","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"68d7512677afda2689f3fb04b140ca4a8abb2b75","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b012aaed_3d7da04d","in_reply_to":"bb6161f2_d36eb1b0","updated":"2024-07-08 13:44:08.000000000","message":"Well, from my perspective, I see higher need for soft-anti-affinity most. As if there\u0027s a place in the same AZ, it might be totally fine to succeed in VM creation rather then fail. As usually you won\u0027t have more then 3-5 AZs, but you totally might have more VMs in the same group. So separating when possible - is better here, imo.\n\nI\u0027ve abandoned mine spec mainly because I realized that precedence of processing is very different now, so you get to filters only when AZ is already passed. So realized I don\u0027t have enough time dedicated by org to this spec for proper further implementation.\n\nThough still pretty much interested and would be happy to collaborate on the topic.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":27339,"name":"Michal Arbet","email":"michal.arbet@ultimum.io","username":"michalarbet"},"change_message_id":"bfb2843c5f878cbb063e45797965e749dfeb6279","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":4,"id":"025abde2_16ea98cb","updated":"2024-07-02 13:59:11.000000000","message":"Viktor, can we re-discuss ? Sean, can be accepted for 2024.2 ?","commit_id":"967b76d2aea9b13bc43eae5713a6f7158ecf7bfc"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"2e7ebb8ea1bc715f6b15f141b58fc127e9e7165d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"694d3bec_b31e9255","updated":"2024-07-08 11:01:46.000000000","message":"not a fully review but some general comments.","commit_id":"729fe3bea8d4f734b47270d677e8d3e160d0cb86"}],"specs/2024.1/approved/availability-zone-affinity-filters.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c1675e9d6d085b7604e1865eaa78ab4fb1ee7b4e","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":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."}],"source_content_type":"text/x-rst","patch_set":3,"id":"e1cd6311_67410017","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":53},"updated":"2023-08-15 17:00:39.000000000","message":"not that AZ are not fault domains they are really just named host aggrates that are intened to model locations like a region (emea vs apac) or as small as a rack or datacenter room.\n\nso in a general sense you cant assume that diffent AZ porovide high aviablity unless the cloud administrator has expressly done that.\n\nim not saying you cant enable this HA usecase wiht Aviablity zone however most other service span all AZ like nenutron so a fiailure of neutron can affect all vms in all AZs.\n\nnova AZs are not the same a aws az where each az is a seperate cloud with federated login.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","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":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."}],"source_content_type":"text/x-rst","patch_set":3,"id":"9412c663_7cc7ddc7","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":53},"in_reply_to":"8a57d0a8_0e5f2164","updated":"2023-08-17 16:11:34.000000000","message":"I was also thinking about something like aggregate-group-filter which will allow users to specify aggregate groups that should only contain one host. This will allow much better modelling of any fault domain, but it won\u0027t be intuitive as AZ. Mostly because the end user typically cannot get a list of aggregation groups.\nBut I still think AZ would be better for this. The alternative is to develop an entirely new entity in API which can model something similar.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","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":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."}],"source_content_type":"text/x-rst","patch_set":3,"id":"8a57d0a8_0e5f2164","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":53},"in_reply_to":"b3ab562b_085fc8ec","updated":"2023-08-16 18:16:41.000000000","message":"right so we both agree that wheher a AZ is a fault domain or not is enitrly depent on the descisions made by the cloud adminsitreator.\n\nso this usecase should be writen form the point of view of the cloud admin since the end user cannot know if usign differnt AZ will help with high avialablity.\n\nAs a user of the openstack API you should not assume they are modelling falut domains. As a project we do not want that to be the preception that is documented or imply that in the api. that is why we document this explcitly \n\"\"\"Availability Zones should not be assumed to map to fault domains and provide no intrinsic HA benefit by themselves.\"\"\"\nhttps://docs.openstack.org/nova/latest/admin/availability-zones.html\n\n\nso this shoudl be somethin liek this\n\nAs a cloud admin i would like to be able to enable fault domain affinity and anti affinity by mapping AZ to my fault domain allowing customrer to expeeress affinity adn anti affintiy requirement when creating instances.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"7c7e197c3482436101b17b7130045f7cc1348f7a","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":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."}],"source_content_type":"text/x-rst","patch_set":3,"id":"b3ab562b_085fc8ec","line":38,"range":{"start_line":37,"start_character":0,"end_line":38,"end_character":53},"in_reply_to":"e1cd6311_67410017","updated":"2023-08-16 15:50:24.000000000","message":"Yes, but it is up to the deployer if the configuration is created this way. So change will create an ability to some higher fault domain. If there is no independent storage, network, power,... it indeed doesn\u0027t make sense. But the same argument can be used for the old anti-affinity-filter. If the deployer decides to have the same storage with a single point of failure, it doesn\u0027t make sense to run VMs on different Hypervisors in case of storage failure.\n\nYes AZ is internally just host aggregates, but API express them as relation 1:N, so it makes sense to use it like this to model a higher fault domain. But what this fault domain exactly is, this is completely on the deployer.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","unresolved":true,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfd158e0_85682584","line":41,"range":{"start_line":39,"start_character":1,"end_line":41,"end_character":59},"updated":"2023-08-16 18:16:41.000000000","message":"unless you set different defacutl az in the api and have mulitpel api this would happen by defualt today both ok.\n\nthis again asusme that the end user has some knowledge of the cloud architechture i.e. that AZ map to datacenters and not containetns or racks but i understand the usecase it not really hte best way to enable this however.\n\nsomething like nuetron l3 routed network would likely be a better solution but they are not mutually exclivive.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","unresolved":true,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* End user wants to create high availability cluster application where each"},{"line_number":38,"context_line":"  backend is placed in a different availability zone."},{"line_number":39,"context_line":"* End user wants to create a cluster application which is sensitive to network"},{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ad90c0c5_649ff4b4","line":41,"range":{"start_line":39,"start_character":1,"end_line":41,"end_character":59},"in_reply_to":"bfd158e0_85682584","updated":"2023-08-17 16:11:34.000000000","message":"Yes, this would require some external knowledge, but the AZ at this moment kind of implicitly assumes that.\n\nThe external knowledge could be just in the form of the name of AZ. Like Rome, Paris or something like NTT, Verizon.\nIf names are like az1, az2 is probably some private cloud where users are employes and have some architecture knowledge.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c1675e9d6d085b7604e1865eaa78ab4fb1ee7b4e","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5740a27c_6d5808fd","line":43,"updated":"2023-08-15 17:00:39.000000000","message":"see my previous point, az may or may not provide fault tolerance in generall they will not for networking issues unles you deploy a seperate neutron region per AZ i.e. a independent neutron per AZ with no sharing.\n\nthis is not what any installer i know fo actully does although i know some large clouds have done this in there in house installer.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"7c7e197c3482436101b17b7130045f7cc1348f7a","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"93330545_b63b9ed6","line":43,"in_reply_to":"5740a27c_6d5808fd","updated":"2023-08-16 15:50:24.000000000","message":"Pretty much the same argument as for the previous answer. If the deployer decides to create all AZ as the same fault domain and encourage users to use it as it was not, it is his problem. This will only create the ability for the end user to express a desire to deploy VMs as far from each other as possible. If the deployer doesn\u0027t want to provide this ability, it is possible to not include this filter.\n\nFor Octavia, we use something like this in bigger deployments all the time but are current solution is an external service/script that will ensure that backends are placed in the correct DC/Rooms. But this solution is quite bad because in case somebody does the live migration or just Octavia failover, there is a big chance that the backend will end up in the wrong location.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fb43ba9e_2c1e0f8f","line":43,"in_reply_to":"7c19b1fd_8783c805","updated":"2023-08-17 16:11:34.000000000","message":"Understood, but I don\u0027t think you could rely on an external service to ensure correct placement when Nova allows you to place VM somewhere in the first place and also allow you to move it (live/cold migration). Maybe this could be achieved by more relying on Placement service and hope that is maybe the ultimate goal but I think this will be a long road years and years. \nBut migrating this proposal to something like this will be probably the easier part.\n\nFor the soft affinity, I guess this will be enough for my use case, but I think most of your objections will remain. And I\u0027m not sure if this soft affinity will be usable for a lot of users.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","unresolved":true,"context_lines":[{"line_number":40,"context_line":"  latency, thus should be placed in the same datacenter"},{"line_number":41,"context_line":"  (i.e. availability zone) without preference in which one."},{"line_number":42,"context_line":"* Octavia load-balancers that are hosted across different availability zones"},{"line_number":43,"context_line":"  for high availability."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"Proposed change"},{"line_number":46,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7c19b1fd_8783c805","line":43,"in_reply_to":"93330545_b63b9ed6","updated":"2023-08-16 18:16:41.000000000","message":"right so we previousl had declard orcastation of aplication like this to be out of scope of nova. so the aprpoch used by ocativa is the way this was intended to be done. or in fact it would have been prefectly reasonabel for octavia to implemnt this az selection logic itslef if it wanted too. \n\nproject like heat/massikari or blazar were where this affinity/antiaffinity\npolicy was expected to be enforced.\n\nthe exisitg server goups in nova are highly problematic and we are reluctant to extend them.\n\nthe fact that they are write once (i.e. cant be updated after they are created)\nand you cant remove and or add an existing server form a server goup cause alot of operational pain so in general we advise agains using them espically if the hard affinity/antiaffinity polices.\n\n\nthe soft affinity polices implemated in the weighers are generally less problematic but just be aware this feature is not building on a partically stong foundation.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","unresolved":true,"context_lines":[{"line_number":48,"context_line":"Bump instance_group object RPC version and add a new lazy-loaded field"},{"line_number":49,"context_line":"\"availability_zones\" with type DictOfListOfStringsField and creating"},{"line_number":50,"context_line":"corresponding load method get_availability_zones which will gather"},{"line_number":51,"context_line":"availability zones across all cells for instance group members and return"},{"line_number":52,"context_line":"a dict where the key is the name of the availability zone and its value is"},{"line_number":53,"context_line":"a list of all non-deleted instance group members in that zone."},{"line_number":54,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"83c0faea_cfb6fc00","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":35},"updated":"2023-08-16 18:16:41.000000000","message":"AZ are defined in the api db they are not modeled in the cell dbs","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","unresolved":true,"context_lines":[{"line_number":48,"context_line":"Bump instance_group object RPC version and add a new lazy-loaded field"},{"line_number":49,"context_line":"\"availability_zones\" with type DictOfListOfStringsField and creating"},{"line_number":50,"context_line":"corresponding load method get_availability_zones which will gather"},{"line_number":51,"context_line":"availability zones across all cells for instance group members and return"},{"line_number":52,"context_line":"a dict where the key is the name of the availability zone and its value is"},{"line_number":53,"context_line":"a list of all non-deleted instance group members in that zone."},{"line_number":54,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"902927cb_5d69535b","line":51,"range":{"start_line":51,"start_character":0,"end_line":51,"end_character":35},"in_reply_to":"83c0faea_cfb6fc00","updated":"2023-08-17 16:11:34.000000000","message":"Sorry, this is stupid wording. What I meant is that you need to gather information from all VMs across all cells to know in which AZ is hosted. The doesn\u0027t need a list of all AZ just make sure that the affinity of knowing one is correct.\nI\u0027ll rewrite that to be more clear.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c1675e9d6d085b7604e1865eaa78ab4fb1ee7b4e","unresolved":true,"context_lines":[{"line_number":62,"context_line":"* ServerGroupAzAffinityFilter"},{"line_number":63,"context_line":"  - Force VMs in the group to be placed in the same availability zone as other"},{"line_number":64,"context_line":"  already created VMs. In case this is the first VM in the group filter"},{"line_number":65,"context_line":"  returns True."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Challenges"},{"line_number":68,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a8ea163e_76894c55","line":65,"updated":"2023-08-15 17:00:39.000000000","message":"this wont work\n\nif hte user does not specify an AZ in the server api create request\n\nwe default the az based on the config\nhttps://github.com/openstack/nova/blob/29f7836ef6542ad98fc9beae89aa64357b0361ad/nova/compute/api.py#L617\n\nfrom parse_availability_zone here in create\n\nhttps://github.com/openstack/nova/blob/29f7836ef6542ad98fc9beae89aa64357b0361ad/nova/api/openstack/compute/servers.py#L755-L756\n\nso by the time we get to filters the az has been chosen by the api and then envocec by the map_az_to_placement_aggregate placement prefilter.\n\nhttps://github.com/openstack/nova/blob/29f7836ef6542ad98fc9beae89aa64357b0361ad/nova/scheduler/request_filter.py#L138C1-L166\n\nand we plan to make that mandatory in bobcat with the removal of the deprecated AZ filter\n\nhttps://review.opendev.org/c/openstack/nova/+/886779\n\nso no approch that is based on just adding a new filter to the schduler will work\n\nwe have rejected this approch at least twice before for similar reasons.\nhttps://review.opendev.org/c/openstack/nova-specs/+/756380","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","unresolved":true,"context_lines":[{"line_number":62,"context_line":"* ServerGroupAzAffinityFilter"},{"line_number":63,"context_line":"  - Force VMs in the group to be placed in the same availability zone as other"},{"line_number":64,"context_line":"  already created VMs. In case this is the first VM in the group filter"},{"line_number":65,"context_line":"  returns True."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Challenges"},{"line_number":68,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"856a885f_0b9445e7","line":65,"in_reply_to":"76de7d7f_79a33694","updated":"2023-08-16 18:16:41.000000000","message":"im wondering if we shoud define a new reserved value like \"auto\"\nor add a new api flag ot make it work even if the config option is set.\n\nwe try to avoid config depenent api behavior. this config driven api behavior predates when we really started to avoid adding any new config driven api behavior.\n\nbasically for interop if im usign this new feature i would want to design it so it work the same on all clouds where possible.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","unresolved":true,"context_lines":[{"line_number":62,"context_line":"* ServerGroupAzAffinityFilter"},{"line_number":63,"context_line":"  - Force VMs in the group to be placed in the same availability zone as other"},{"line_number":64,"context_line":"  already created VMs. In case this is the first VM in the group filter"},{"line_number":65,"context_line":"  returns True."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Challenges"},{"line_number":68,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ea9c2ecd_ce385ded","line":65,"in_reply_to":"856a885f_0b9445e7","updated":"2023-08-17 16:11:34.000000000","message":"Yes, the auto will be possible and maybe better (clearer). But it will still need to allow VMs to be defined without explicitly specified zone. Because for example at this moment you could let AZ be chosen by Cinder. If you create a VM with a boot disk on cinder and you forbid cross AZ mount. There is no other possibility then to choose AZ after you know which volumes are mounted.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"7c7e197c3482436101b17b7130045f7cc1348f7a","unresolved":true,"context_lines":[{"line_number":62,"context_line":"* ServerGroupAzAffinityFilter"},{"line_number":63,"context_line":"  - Force VMs in the group to be placed in the same availability zone as other"},{"line_number":64,"context_line":"  already created VMs. In case this is the first VM in the group filter"},{"line_number":65,"context_line":"  returns True."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Challenges"},{"line_number":68,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"76de7d7f_79a33694","line":65,"in_reply_to":"a8ea163e_76894c55","updated":"2023-08-16 15:50:24.000000000","message":"The default value of this parameter is None https://github.com/openstack/nova/blob/master/nova/conf/availability_zone.py#L45\nwhich will cause no AZ to be defined in the build-request so the scheduler can choose a host at will.\nBut you are correct that I should mention that I expect this config to remain default and also user should not define AZ when booting VM, otherwise this filter will fail. I will update that in spec.\n\nThis approach is not really on anything in the old az-filter. It will also not change build-request to contain AZ if it does not contain it before, so placement will return all possible hosts in all possible AZ. I prototype this code and it works in master, where this filter is already disabled if I\u0027m not mistaken.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"329b2ae82b4f65f0e12535117479bef84d5cd111","unresolved":true,"context_lines":[{"line_number":70,"context_line":"race condition when VMs are scheduled in parallel."},{"line_number":71,"context_line":"This could be easily achieved by using the same mechanism as existing"},{"line_number":72,"context_line":"affinity filters. Do the validation in nova-compute after resources are"},{"line_number":73,"context_line":"claimed but before VMs build starts."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The availability zones field in instance_group needs to be reset after certain"},{"line_number":76,"context_line":"operations. This could be achieved by extending the reset call that is already"}],"source_content_type":"text/x-rst","patch_set":3,"id":"de683363_7e59cac1","line":73,"updated":"2023-08-16 18:16:41.000000000","message":"This is kind of a blocker.\nthis requires intoducing a new upcall form the comptues that need infor form the api db about all the instance in teh goups and which az they are in.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6a997be34f03009a3870e87f81027fd69393e425","unresolved":true,"context_lines":[{"line_number":70,"context_line":"race condition when VMs are scheduled in parallel."},{"line_number":71,"context_line":"This could be easily achieved by using the same mechanism as existing"},{"line_number":72,"context_line":"affinity filters. Do the validation in nova-compute after resources are"},{"line_number":73,"context_line":"claimed but before VMs build starts."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The availability zones field in instance_group needs to be reset after certain"},{"line_number":76,"context_line":"operations. This could be achieved by extending the reset call that is already"}],"source_content_type":"text/x-rst","patch_set":3,"id":"8c601f8c_4897192a","line":73,"in_reply_to":"09eece7c_f22b3275","updated":"2023-08-17 16:37:11.000000000","message":"Right, we wish we could eliminate that upcall. Adding a new one is not something we want to do. Also, I think the computes doing AZ calculation is out of scope for them in general.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"292ba4e1ffca276ab2abd43238c955e37b652817","unresolved":true,"context_lines":[{"line_number":70,"context_line":"race condition when VMs are scheduled in parallel."},{"line_number":71,"context_line":"This could be easily achieved by using the same mechanism as existing"},{"line_number":72,"context_line":"affinity filters. Do the validation in nova-compute after resources are"},{"line_number":73,"context_line":"claimed but before VMs build starts."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The availability zones field in instance_group needs to be reset after certain"},{"line_number":76,"context_line":"operations. This could be achieved by extending the reset call that is already"}],"source_content_type":"text/x-rst","patch_set":3,"id":"09eece7c_f22b3275","line":73,"in_reply_to":"5605a12a_04466367","updated":"2023-08-17 16:11:34.000000000","message":"The upcall is already there, it is doing the same thing for old affinity filters https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1885 . The proposal will do the same thing but instead of hosts, it will ask for az. So it will behave similarly to now only the upcall will be different.\nIt is even possible to disable this upcall because it will fix only specific race conditions https://github.com/openstack/nova/blob/master/nova/conf/workarounds.py#L138 .","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":22072,"name":"Viktor Křivák","email":"viktor.krivak@ultimum.io","username":"viktor-krivak"},"change_message_id":"9acd6329b4cd71729dcb61944c4001093d5305f8","unresolved":true,"context_lines":[{"line_number":70,"context_line":"race condition when VMs are scheduled in parallel."},{"line_number":71,"context_line":"This could be easily achieved by using the same mechanism as existing"},{"line_number":72,"context_line":"affinity filters. Do the validation in nova-compute after resources are"},{"line_number":73,"context_line":"claimed but before VMs build starts."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The availability zones field in instance_group needs to be reset after certain"},{"line_number":76,"context_line":"operations. This could be achieved by extending the reset call that is already"}],"source_content_type":"text/x-rst","patch_set":3,"id":"58519eb5_019add23","line":73,"in_reply_to":"8c601f8c_4897192a","updated":"2023-08-17 17:17:55.000000000","message":"Understood, this validation in compute is not essential because it will fix only rare race condition. And I think it is possible to do that in scheduler. I just want to make this in similar way how old affinity filter works. I\u0027ll try came up with something better but I need to test it so I know it is possible to do that. I will change this part of the spec.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"1e442fe9953ae68c76d499f8dbf14c9bd7a48f86","unresolved":true,"context_lines":[{"line_number":70,"context_line":"race condition when VMs are scheduled in parallel."},{"line_number":71,"context_line":"This could be easily achieved by using the same mechanism as existing"},{"line_number":72,"context_line":"affinity filters. Do the validation in nova-compute after resources are"},{"line_number":73,"context_line":"claimed but before VMs build starts."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"The availability zones field in instance_group needs to be reset after certain"},{"line_number":76,"context_line":"operations. This could be achieved by extending the reset call that is already"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5605a12a_04466367","line":73,"in_reply_to":"de683363_7e59cac1","updated":"2023-08-16 18:42:50.000000000","message":"I haven\u0027t even looked at this spec because it\u0027s not really spec time, but ... yup, not cool.","commit_id":"a3ab71a4c71884105c316e2c99eb5cbf07fdd29c"}],"specs/2024.2/approved/availability-zone-affinity-filters.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"110f657d7ffd0a3c9d68492a75c2163cbec58205","unresolved":true,"context_lines":[{"line_number":104,"context_line":"  and \"az-anti-affinity\""},{"line_number":105,"context_line":"* /os-server-groups/{server_group_id} (GET)"},{"line_number":106,"context_line":"  Response body key \"policy\" could have additional values \"az-affinity\""},{"line_number":107,"context_line":"  and \"az-anti-affinity\""},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"Security impact"},{"line_number":110,"context_line":"---------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"8f059497_2fbda210","line":107,"updated":"2025-10-29 12:53:41.000000000","message":"We learned the hard way that hard affinity is a bad idea especially as VM\u0027s group membership and group policy in immutable. I.e. moving VMs is harder if their affinity is hard instead of soft. We should consider adding the az-affinity as a weigher and keeping it soft to avoid later problems when an AZ needs to be decommissioned but that prevents AZ affine VMs to be moved away.","commit_id":"729fe3bea8d4f734b47270d677e8d3e160d0cb86"}]}