)]}'
{"specs/victoria/approved/availability-zone-affinity-anti-affinity-filter.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fc7e150b60550bfcb9354edfaddcae0d444a0df7","unresolved":false,"context_lines":[{"line_number":4,"context_line":""},{"line_number":5,"context_line":"    http: // creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d"},{"line_number":8,"context_line":"Availability Zone Affinity Filter"},{"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"},{"line_number":10,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f560f44_90654a20","line":7,"range":{"start_line":7,"start_character":2,"end_line":7,"end_character":49},"updated":"2020-10-07 10:33:11.000000000","message":"you can drop the spaces and trim the length of the lines to the length of the title","commit_id":"cb73043920e2a85938fab42f72286323971ed2ea"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fc7e150b60550bfcb9354edfaddcae0d444a0df7","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https: // blueprints.launc/+spec/availability-zone-affinity-anti-affinity-filter"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Instances can have different scheduling requirements such as low latency, higher reliability and availability. Consequently, such instances are required to be created within a single availability zone for low latency between instances or on different availability zones for higher reliability in a group of instances. Currently, it is not possible to create instances with such requirements unless each availability zone is specified for each instance creation."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This spec introduces a new filter scheduler where a group of instances can be created by affinity policy on a single availability zone or instances can be created each on a different availability zone with anti-affinity policy."},{"line_number":16,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f560f44_d06b42ed","line":13,"updated":"2020-10-07 10:33:11.000000000","message":"please wrap lines at 79 charachter","commit_id":"cb73043920e2a85938fab42f72286323971ed2ea"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"fc7e150b60550bfcb9354edfaddcae0d444a0df7","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Instances can have different scheduling requirements such as low latency, higher reliability and availability. Consequently, such instances are required to be created within a single availability zone for low latency between instances or on different availability zones for higher reliability in a group of instances. Currently, it is not possible to create instances with such requirements unless each availability zone is specified for each instance creation."},{"line_number":14,"context_line":""},{"line_number":15,"context_line":"This spec introduces a new filter scheduler where a group of instances can be created by affinity policy on a single availability zone or instances can be created each on a different availability zone with anti-affinity policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Problem description"},{"line_number":18,"context_line":"\u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d\u003d \u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f560f44_b0496e8f","line":15,"range":{"start_line":15,"start_character":27,"end_line":15,"end_character":43},"updated":"2020-10-07 10:33:11.000000000","message":"a new scheduler filter","commit_id":"cb73043920e2a85938fab42f72286323971ed2ea"}],"specs/wallaby/approved/availability-zone-affinity-anti-affinity-filter.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba89445e7b2b033fe39f9bbd32a49271e4780e75","unresolved":false,"context_lines":[{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launc/+spec/availability-zone-affinity-anti-affinity-filter"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Instances can have different scheduling requirements such as low latency,"},{"line_number":14,"context_line":"higher reliability and availability. Consequently, such instances are required"},{"line_number":15,"context_line":"to be created within a single availability zone for low latency between"},{"line_number":16,"context_line":"instances or on different availability zones for higher reliability in a group"},{"line_number":17,"context_line":"of instances. Currently, it is not possible to create instances with such"},{"line_number":18,"context_line":"requirements unless each availability zone is specified for each instance"},{"line_number":19,"context_line":"creation."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_18182a82","line":17,"range":{"start_line":13,"start_character":0,"end_line":17,"end_character":12},"updated":"2020-10-08 14:58:27.000000000","message":"this would be deployment specific.\nthere is no gareentee that hosts within an AZ have low latency\n\nthe AZ could be split into multiple cells at different edge sights.\n\nconversly there is no guarentee of higher reliablity by selecting different AZ an AZ in openstack is not the equivalent of an AZ in aws meaning it is not a seperate fault domain. its is just a metadta tag on a host aggreate.\nit has not high avaiablity implication by defualt.\n\nsome deployments use it for that other dont.","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba89445e7b2b033fe39f9bbd32a49271e4780e75","unresolved":false,"context_lines":[{"line_number":18,"context_line":"requirements unless each availability zone is specified for each instance"},{"line_number":19,"context_line":"creation."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"This spec introduces a new scheduler filter where a group of instances can be"},{"line_number":22,"context_line":"created by affinity policy on a single availability zone or instances can be"},{"line_number":23,"context_line":"created each on a different availability zone with anti-affinity policy."},{"line_number":24,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_580e223d","line":21,"range":{"start_line":21,"start_character":52,"end_line":21,"end_character":71},"updated":"2020-10-08 14:58:27.000000000","message":"you are refering to server groups?","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba89445e7b2b033fe39f9bbd32a49271e4780e75","unresolved":false,"context_lines":[{"line_number":32,"context_line":"deployments with large number of availability zones, it is not practical to"},{"line_number":33,"context_line":"watch available zones and instances in the group. Current server group"},{"line_number":34,"context_line":"anti-affinity filter only guarantee instances in the server group with"},{"line_number":35,"context_line":"anti-affinity policy on different hosts, but these hosts can be in the same"},{"line_number":36,"context_line":"availability zone."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":""},{"line_number":39,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_dbb98c16","line":36,"range":{"start_line":35,"start_character":41,"end_line":36,"end_character":18},"updated":"2020-10-08 14:58:27.000000000","message":"yep but again AZ are not actully fault domains in openstack so it typical for multiple AZ to have shared openstack infrasturture and its rather unusal for them to be deployed as completly independed fault domains. to do that you have to have a 1:1 mapping between AZ and nova cells and even then teh non nova compents like placment cinder and neutron woudl also need to be configured to operate in an multipel AZs\n\nservice like keystone,glance,swift and placment also dont have the concept of AZ the same way that nova has so an AZ is quite a leaky abstrtion to use to model fault domains.\n\neven if nova has been configured in such a way as to make each AZ a seperate fault domain ist rather unlikely that all other services have been so you instace will still be imapacted if there is a failure of say the keystone service regardless of which az they are in.\n\nunless you use cells V2 to deploy a seperate database/conductor and have a per cell rabbitmq instance per az all az in nova share the same db/message bus and are handeled by the same conducrtor/api/schulder. as such a failure of the contoler services will affect all az in the same cell equally.\n\n\ncells are not actully a ha mechanisium either but they have some improved resiliance provided the failure is configed to only one cell\n\ne.g. the failure of a cell conductor or cell db will not affect other cells provided that conductor is not also the super conductor.","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3be570c18d5b190330d664a40124e2c1dbdd0d3e","unresolved":false,"context_lines":[{"line_number":67,"context_line":"same availability zone. A user creates an instance in the group with"},{"line_number":68,"context_line":"anti-affinity policy, Later instances will be created on hosts from different"},{"line_number":69,"context_line":"availability zones. For example, if the first instance is created on host4 in"},{"line_number":70,"context_line":"AZ2, the second instance, will be created on host1, host2, or host3 in AZ1."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_2c3a10e5","line":70,"updated":"2020-10-08 17:04:51.000000000","message":"As we discussed during the last IRC Nova meeting [1], AZ affinity and anti-affinity is already managed by Nova :\n* you can specify N instances to be on the same AZ just by specifying the same --availability_zone at boot time\n* you can specify N instances to be on distinct AZs by looking over the os-availability-zones API, pick N distinct AZs, and boot each of the N instances using a different --az value corresponding to the AZ you picked\n\nThe only miss I see here in this workflow is with multi-create:\n* you can specify N instances to be created on the same AZ by using both --max and --az\n* but you can\u0027t specify N instances to be on mutually exclusive AZs on one single boot command\n\nI\u0027m all open for discussing about the multi-create gap, but I personnally think adding this possibility would require substantial API change which wouldn\u0027t be worth it.\nI\u0027d personnally recommend you to pursue your efforts into AZ-exclusive multi-create by writing a 3rd-party tool which would orchestrate the AZ exclusion and trigger concurrent API calls accordingly.\n\n[1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-10-08-16.00.log.html#l-147","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ee4e6fe5a644cad7a13cff904620c0748408eed6","unresolved":false,"context_lines":[{"line_number":67,"context_line":"same availability zone. A user creates an instance in the group with"},{"line_number":68,"context_line":"anti-affinity policy, Later instances will be created on hosts from different"},{"line_number":69,"context_line":"availability zones. For example, if the first instance is created on host4 in"},{"line_number":70,"context_line":"AZ2, the second instance, will be created on host1, host2, or host3 in AZ1."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_65989119","line":70,"in_reply_to":"9f560f44_2c3a10e5","updated":"2020-10-09 10:07:51.000000000","message":"given our reluctance to add new functionality to multi-create and the fact that in general we would prefer to remove that api rather then enhance it i would agree with using external tooling for that usecase.\n\nmulti create currently reuses the same request spec for all instnace as a way to carry info related to which host the instance are currently schduled too for normal anti afinity\n\npreserving that behavior and allowing az antiafinity would be invaisve to cahnge. im not saying it cant be done but its more work then this spec currently proposes doing and would be required for this to work for multi create.","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ba89445e7b2b033fe39f9bbd32a49271e4780e75","unresolved":false,"context_lines":[{"line_number":73,"context_line":"Proposed change"},{"line_number":74,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Availability zone affinity filter scheduler logic is to filter hosts in"},{"line_number":77,"context_line":"availability zones based on policy (affinity or anti-affinity). Server groups"},{"line_number":78,"context_line":"are used to record instances in the group and group\u0027s policy. We go over the"},{"line_number":79,"context_line":"components of the proposed solution and alternative approach."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Server Group"},{"line_number":82,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_f6be27d2","line":79,"range":{"start_line":76,"start_character":0,"end_line":79,"end_character":61},"updated":"2020-10-08 14:58:27.000000000","message":"so the AZ if not set in the boot request will be populated by the api before we reach teh schduler filter using the defualt az set in its nova.conf or nova if no value is configured.\n\nso by the time the request is recived at teh filter it will already be populated int eh build_request/requst_spec and the filter will not be able to tell if the az was requested by the use or populated by the api.\n\nthis is done here \n\nhttps://github.com/openstack/nova/blob/cf26d1863163a2dbdfaad012ffa4af7be827a0af/nova/api/openstack/compute/servers.py#L662\n\nwhich defults the as to the one in the config\n\nhttps://github.com/openstack/nova/blob/9fa563666e8500510def19269f740d99cab0e994/nova/compute/api.py#L541-L542","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"},{"author":{"_account_id":10058,"name":"Erlon R. Cruz","email":"erlon.rodrigues.cruz@canonical.com","username":"sombrafam"},"change_message_id":"3ad39156c8a9731f49869f9c88222b0b80f3f0a0","unresolved":false,"context_lines":[{"line_number":193,"context_line":"Server Group Affinity Filter"},{"line_number":194,"context_line":"----------------------------"},{"line_number":195,"context_line":""},{"line_number":196,"context_line":"Affinity filter should be updated to check for the scheduler hint, if  ``availability_zone_affinity\u003dFalse`` or it is not specified, the filter should"},{"line_number":197,"context_line":"be applied to the host otherwise should return."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9f560f44_58b2a297","line":196,"range":{"start_line":196,"start_character":68,"end_line":196,"end_character":70},"updated":"2020-10-08 14:24:59.000000000","message":"wrap here","commit_id":"13069e921c92811763f9f6946fe6b32f5fdcfd59"}]}