)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0e4009a6ff16e064c83f287b1e12892a5331cd46","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"823d9d69_a7f7f341","updated":"2024-07-16 15:00:09.000000000","message":"I\u0027m ok with the upgrade path, no other nits.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6da1a972_aca27386","updated":"2024-07-16 12:46:39.000000000","message":"i have some nit but im more or less ok with proceeding with this as is.\n\nmel is proposing to take the most strict approch by default which will mean no upgrade impact for anyoen already using unifed limits\n\nso based on that i am +2 rather then +1\n\nmy suggesion actully has a slight upgrade inpact for exsiting deployment but it a nicer flow in general IMO but its only a slight preference so i have no objection to melaines propsoed approch.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"}],"specs/2024.2/approved/unified-limits-nova-unset-limits.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":true,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]strict_unified_limits`` which defaults to ``True``. When set to"},{"line_number":58,"context_line":"``True``, the Nova API will use the native oslo.limit behavior of considering"},{"line_number":59,"context_line":"unset unified limits as zero. When set to ``False``, the Nova API will consider"},{"line_number":60,"context_line":"unset unified limits as unlimited or \"don\u0027t care\". When set to ``True``, the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a1569250_970493c3","line":57,"range":{"start_line":57,"start_character":53,"end_line":57,"end_character":57},"updated":"2024-07-16 12:46:39.000000000","message":"this might be controversiol but given this is only used if your using\nthe unified limits driver and that is not currently our default i think we should default to `False` for 2024.2 and 2025.1\n\nin 2025.1 we should make the unifed limit driver the default adn deprecte \n\n`[quota]strict_unified_limits`\n\nin 2025.2 and 2026.1 it should default to `True` and in 2026.2 we should remove the config option maintaining the `True` behavior.\n\n\ni think that provies the most reasonable upgrade path.\n\nthat would be my perfernce but i dont think that is worth holdign the spec on and would be fine with defering this to the implmation or keeping it at `True` as currently proposed.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"0e4009a6ff16e064c83f287b1e12892a5331cd46","unresolved":true,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]strict_unified_limits`` which defaults to ``True``. When set to"},{"line_number":58,"context_line":"``True``, the Nova API will use the native oslo.limit behavior of considering"},{"line_number":59,"context_line":"unset unified limits as zero. When set to ``False``, the Nova API will consider"},{"line_number":60,"context_line":"unset unified limits as unlimited or \"don\u0027t care\". When set to ``True``, the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d78d1b83_55a5f66e","line":57,"range":{"start_line":57,"start_character":53,"end_line":57,"end_character":57},"in_reply_to":"a1569250_970493c3","updated":"2024-07-16 15:00:09.000000000","message":"For upgrading, indeed we need to have the default value to be ``True``.\n\nBy Epoxy, we could maybe change it to ``False`` but meh.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ac6990e91b096b8bfc624da509b845f56b451407","unresolved":true,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]strict_unified_limits`` which defaults to ``True``. When set to"},{"line_number":58,"context_line":"``True``, the Nova API will use the native oslo.limit behavior of considering"},{"line_number":59,"context_line":"unset unified limits as zero. When set to ``False``, the Nova API will consider"},{"line_number":60,"context_line":"unset unified limits as unlimited or \"don\u0027t care\". When set to ``True``, the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a20b8403_791e3480","line":57,"range":{"start_line":57,"start_character":53,"end_line":57,"end_character":57},"in_reply_to":"d78d1b83_55a5f66e","updated":"2024-07-16 20:10:25.000000000","message":"I do think the idea of defaulting to `False` will be/is controversial. I did want to default to `False` for the first couple of cycles like Sean says but I reread the comments from Dan and John on this proposed patch: https://review.opendev.org/c/openstack/oslo.limit/+/899415\nand thought it is unlikely we would get consensus on making it default to `False`.\n\nSo I went ahead and proposed it as defaulting to `True` here.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":true,"context_lines":[{"line_number":57,"context_line":"``[quota]strict_unified_limits`` which defaults to ``True``. When set to"},{"line_number":58,"context_line":"``True``, the Nova API will use the native oslo.limit behavior of considering"},{"line_number":59,"context_line":"unset unified limits as zero. When set to ``False``, the Nova API will consider"},{"line_number":60,"context_line":"unset unified limits as unlimited or \"don\u0027t care\". When set to ``True``, the"},{"line_number":61,"context_line":"Nova API will use the native oslo.limit behavior of considering unset unified"},{"line_number":62,"context_line":"limits as zero."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"The only exception to ``[quota]strict_unified_limits \u003d False`` is if there are"},{"line_number":65,"context_line":"not registered limits set at all. `Registered limits`_ are default limits that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"acddc87f_a3b2fbbd","line":62,"range":{"start_line":60,"start_character":50,"end_line":62,"end_character":15},"updated":"2024-07-16 12:46:39.000000000","message":"nit: you repated yourself here","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ac6990e91b096b8bfc624da509b845f56b451407","unresolved":true,"context_lines":[{"line_number":57,"context_line":"``[quota]strict_unified_limits`` which defaults to ``True``. When set to"},{"line_number":58,"context_line":"``True``, the Nova API will use the native oslo.limit behavior of considering"},{"line_number":59,"context_line":"unset unified limits as zero. When set to ``False``, the Nova API will consider"},{"line_number":60,"context_line":"unset unified limits as unlimited or \"don\u0027t care\". When set to ``True``, the"},{"line_number":61,"context_line":"Nova API will use the native oslo.limit behavior of considering unset unified"},{"line_number":62,"context_line":"limits as zero."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"The only exception to ``[quota]strict_unified_limits \u003d False`` is if there are"},{"line_number":65,"context_line":"not registered limits set at all. `Registered limits`_ are default limits that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2d751ba0_bedb9155","line":62,"range":{"start_line":60,"start_character":50,"end_line":62,"end_character":15},"in_reply_to":"acddc87f_a3b2fbbd","updated":"2024-07-16 20:10:25.000000000","message":"Oops, copy pasta.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":true,"context_lines":[{"line_number":125,"context_line":"command will be enhanced to scan the database for resources in flavors that do"},{"line_number":126,"context_line":"not have registered limits set and show them in the output. The intent is to"},{"line_number":127,"context_line":"help admins/operators catch all resources and set limits for them before"},{"line_number":128,"context_line":"unified limits quotas are enabled."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Performance Impact"},{"line_number":131,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0dc6c23c_5c2efc1b","line":128,"updated":"2024-07-16 12:46:39.000000000","message":"ack so this will need to scan both the defied flavor in the api db and the embded flavor of all non deleted instnaces as the two may not be the same.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ac6990e91b096b8bfc624da509b845f56b451407","unresolved":true,"context_lines":[{"line_number":125,"context_line":"command will be enhanced to scan the database for resources in flavors that do"},{"line_number":126,"context_line":"not have registered limits set and show them in the output. The intent is to"},{"line_number":127,"context_line":"help admins/operators catch all resources and set limits for them before"},{"line_number":128,"context_line":"unified limits quotas are enabled."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Performance Impact"},{"line_number":131,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0d5cc077_8d1bb95b","line":128,"in_reply_to":"0dc6c23c_5c2efc1b","updated":"2024-07-16 20:10:25.000000000","message":"Oh good point about the embedded flavors. I will add that to the flavor scanning patch.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":true,"context_lines":[{"line_number":151,"context_line":""},{"line_number":152,"context_line":"The ``[quota]strict_unified_limits`` config option would only impact an upgrade"},{"line_number":153,"context_line":"if the admin/operator sets it to ``True`` at the same time they enable unified"},{"line_number":154,"context_line":"limits quotas by using the UnifiedLimitsDriver."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"If a deployer decides to switch to the UnifiedLimitsDriver during their upgrade"},{"line_number":157,"context_line":"and set ``[quota]strict_unified_limits`` to ``False`` before upgrading, there"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5479a971_e30b45e8","line":154,"updated":"2024-07-16 12:46:39.000000000","message":"right since we are  defaultign to strict and not changing the quota driver in this release there relly shoudl be no upgrade impact to this as propsoed.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"ac6990e91b096b8bfc624da509b845f56b451407","unresolved":true,"context_lines":[{"line_number":151,"context_line":""},{"line_number":152,"context_line":"The ``[quota]strict_unified_limits`` config option would only impact an upgrade"},{"line_number":153,"context_line":"if the admin/operator sets it to ``True`` at the same time they enable unified"},{"line_number":154,"context_line":"limits quotas by using the UnifiedLimitsDriver."},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"If a deployer decides to switch to the UnifiedLimitsDriver during their upgrade"},{"line_number":157,"context_line":"and set ``[quota]strict_unified_limits`` to ``False`` before upgrading, there"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c9366ca7_a76d64c9","line":154,"in_reply_to":"5479a971_e30b45e8","updated":"2024-07-16 20:10:25.000000000","message":"I agree. I included this section really to explain the conditions that would cause an upgrade impact, to help readers understand why this proposal as-is has no upgrade impact. I should have written a first sentence in the paragraph to say \"this spec as proposed will have no upgrade impact\" to make it clearer and then go on to describe why and what would cause an upgrade impact.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b60f067bbb5b1853770e33e53b2da9aa61a7071f","unresolved":true,"context_lines":[{"line_number":158,"context_line":"is a possibility that resources could be allocated beyond what the deployer"},{"line_number":159,"context_line":"would have intended until they take action on the logged warnings and set"},{"line_number":160,"context_line":"registered limits for resources missing limits."},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"Implementation"},{"line_number":163,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":164,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"81145321_00d3027e","line":161,"updated":"2024-07-16 12:46:39.000000000","message":"this is however is still good to capture.\n\ni woudl generally not recomemnd upgrade and changign the driver in one step bnut if they do this is valid.\n\n\ni woudl recommend upgradeing with the old driver\nimporting the limits to keystone and then changign the driver i a post upgrade maintance window instead\nbut im ok with this section.","commit_id":"190e4cf9015a1c944f4283a9d99365f11a6214a3"}],"specs/2024.2/approved/unified-limits-zero-as-unlimited.rst":[{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"fcebb7b3b5d1bb96d7f96934951693f8b7384ade","unresolved":true,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]unified_limit_of_zero_as_unlimited`` which defaults to ``True``. When"},{"line_number":58,"context_line":"set to ``True``, the Nova API will consider unified limits of 0 or missing"},{"line_number":59,"context_line":"unified limits as unlimited and log a warning message about the resource(s)"},{"line_number":60,"context_line":"with 0 or missing limits every time quota for that resource is enforced."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5b6e6a87_b72b7e86","line":57,"updated":"2024-07-10 15:57:19.000000000","message":"I can\u0027t remember if there was any objection to having this default to True but I wasn\u0027t sure how helpful it would be if it were opt-in? We can discuss it.","commit_id":"ca4f10f592ad6ec54254c71ab2f0585b7217c7f4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"580bfc902019edfc6a3505e670cd680eaef8678d","unresolved":true,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]unified_limit_of_zero_as_unlimited`` which defaults to ``True``. When"},{"line_number":58,"context_line":"set to ``True``, the Nova API will consider unified limits of 0 or missing"},{"line_number":59,"context_line":"unified limits as unlimited and log a warning message about the resource(s)"},{"line_number":60,"context_line":"with 0 or missing limits every time quota for that resource is enforced."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b805f41f_b6b88243","line":57,"in_reply_to":"5b6e6a87_b72b7e86","updated":"2024-07-10 19:45:48.000000000","message":"(later) Sean and I chatted a bit on IRC [1] and agreed it might be overly simplistic to treat zero as unlimited to address the problem. Because oslo.limit returns a limit of 0 literally when a registered limit is missing, allowing 0 to mean unlimited is a very small change that involves no additional Keystone API calls. However, when enabled, it would provide no way for an admin/operator to express they want to disallow allocation of a resource intentionally by setting it to 0.\n\nSummary from IRC was there are three cases:\n1. no limits at all -\u003e they didn\u0027t migrate\n2. some registered limits set -\u003e enforce only those resource classes\n3. all resource classes in the request have limits -\u003e all are enforced\n\nSo I expect I will be updating this spec to take a more sophisticated approach.\n\n[1] https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2024-07-10.log.html#t2024-07-10T15:58:30","commit_id":"ca4f10f592ad6ec54254c71ab2f0585b7217c7f4"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"91abac7f3f96b5f4b3eb701b7494eb97dac7696e","unresolved":false,"context_lines":[{"line_number":54,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"The proposal in this spec is to add a new configuration option"},{"line_number":57,"context_line":"``[quota]unified_limit_of_zero_as_unlimited`` which defaults to ``True``. When"},{"line_number":58,"context_line":"set to ``True``, the Nova API will consider unified limits of 0 or missing"},{"line_number":59,"context_line":"unified limits as unlimited and log a warning message about the resource(s)"},{"line_number":60,"context_line":"with 0 or missing limits every time quota for that resource is enforced."}],"source_content_type":"text/x-rst","patch_set":1,"id":"49d8a4a8_1ffd5b40","line":57,"in_reply_to":"b805f41f_b6b88243","updated":"2024-07-13 02:03:07.000000000","message":"Done","commit_id":"ca4f10f592ad6ec54254c71ab2f0585b7217c7f4"}]}