)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":36393,"name":"Callum Dickinson","email":"callum.dickinson@catalystcloud.nz","username":"Callum027","status":"Catalyst Cloud"},"change_message_id":"2170baecb24ce41013314e94a68b741167561e73","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f68603b2_6bc0df3a","updated":"2026-11-08 19:08:20.000000000","message":"Aodh in its current state allows an alarm to be created before the resource itself exists. This patch would change to to Aodh rejecting creation of an alarm until the resource being monitored has been created in Gnocchi, which can easily happen when using some kind of automation such as Heat or Terraform even if Ceilometer notification meters .\n\nIt is also possible for Gnocchi resources to be moved to another project. Under this scenario, this patch would not apply on `gnocchi_resources_threshold` alarms.\n\nFor this to be compatible with existing workflows *and* enforce security constraints in all cases, they need to be enforced by Aodh Evaluator like in my previously submitted (though incomplete) patches.","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":39493,"name":"Daniel Gines","display_name":"Daniel Gines","email":"dangines@gmail.com","username":"danielgines"},"change_message_id":"9d69f58466e3a6ba5f42ce8540e86f6ba0956968","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fc75f98d_3a5c4ff4","in_reply_to":"4e6a59d2_bf6bd96c","updated":"2026-11-08 22:58:55.000000000","message":"Thanks, I agree. We tested PS1 on a clean 2026.1 deployment and saw both problems: a Heat stack with a server and an OS::Aodh::GnocchiResourcesAlarm only worked because Ceilometer created the Gnocchi resource one to three seconds before Heat created the alarm, and the alarms created before the change kept reading the measures of the other project. Checking the existence of the resource with the aodh service credentials, to accept resources that do not exist yet, does not help either: it tells the caller whether a resource ID exists in another project, and an alarm created before the resource still reads it once another project creates it.\n\nPS2 reworks the change along the lines of option 2 in comment #6 of bug 2162780, which Takashi preferred in comment #8, with the same scope_to_project attribute as the Prometheus rule. The API no longer sends any request to Gnocchi: it stores the project scope in the gnocchi_resources_threshold and gnocchi_aggregation_by_metrics_threshold rules, including the sub rules of composite alarms (whose gnocchi_aggregation_by_resources_threshold sub rules now get the same project filter as the top level rule). The evaluator reads the measures of a resource through the aggregates API with the resource id and the project filter, and checks the owner of the metrics of a gnocchi_aggregation_by_metrics_threshold rule before reading them. An alarm can still be created before its resource, and once a resource is moved to another project, the alarms of the previous project no longer read it. We tested it on a clean 2026.1 deployment with Gnocchi 4.7.0 and master, including a Heat stack, and telemetry-tempest-plugin master passes without changes.\n\nThe alarms that already exist have no scope, and nothing stored with an alarm tells whether it was created by an admin, so the evaluator restricts them to the project of the alarm. An admin alarm on a resource of another project stops working until an admin updates it (any update sets the scope); this is in the upgrade section of the release note. How did your patches handle that case? I cannot see bug 2137599.","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":36393,"name":"Callum Dickinson","email":"callum.dickinson@catalystcloud.nz","username":"Callum027","status":"Catalyst Cloud"},"change_message_id":"66672513fd016373cb5f5e453a7a6fc00fc5d77f","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4e6a59d2_bf6bd96c","in_reply_to":"68297479_55c131d3","updated":"2026-11-08 20:44:25.000000000","message":"^ Apologies, by \"no longer exist\" I mean \"do not yet exist\".","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":36393,"name":"Callum Dickinson","email":"callum.dickinson@catalystcloud.nz","username":"Callum027","status":"Catalyst Cloud"},"change_message_id":"38f418782e4ac4f63c0dc1627f01a562492d20d1","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"68297479_55c131d3","in_reply_to":"c4c25a4c_aea5e31d","updated":"2026-11-08 20:38:37.000000000","message":"I should also add that the possibility of resources moving to other projects also makes the API-based approach not ideal, because if we allow alarms to be created for resources that no longer exist but reject ones that exist on other projects, that confirms the existence of the resource.\n\nMy recommendation is that all the checks for this security issue be performed in Aodh Evaluator, and Aodh API allow the alarms to be created as it currently does.","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":36393,"name":"Callum Dickinson","email":"callum.dickinson@catalystcloud.nz","username":"Callum027","status":"Catalyst Cloud"},"change_message_id":"5a7a8f98577e3df355886b3375d8d0b0892a9d1b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c4c25a4c_aea5e31d","in_reply_to":"f68603b2_6bc0df3a","updated":"2026-11-08 19:08:39.000000000","message":"Marking as unresolved","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":39493,"name":"Daniel Gines","display_name":"Daniel Gines","email":"dangines@gmail.com","username":"danielgines"},"change_message_id":"9e163296df6d3f5611123605b1c998b0b4da4c57","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"12826af6_aa689d4d","in_reply_to":"f8af9627_8eefe2ac","updated":"2026-11-09 21:56:50.000000000","message":"Sorry, my previous reply went to the parent thread by mistake, so it did not answer this one.\n\nExisting alarms do not need to be updated here either: the evaluator restricts an alarm without scope_to_project to the project of the alarm, as your patch does. The difference is in admin alarms on resources of other projects: with your patch they stop working, and here an admin can restore them by updating the alarm, which stores the scope once in the rule.\n\nAlso a correction to my earlier reply: option 2 is in comment #4 of bug 2162780 (https://bugs.launchpad.net/aodh/+bug/2162780/comments/4), and Takashi preferred it in comment #6 (https://bugs.launchpad.net/aodh/+bug/2162780/comments/6).","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":39493,"name":"Daniel Gines","display_name":"Daniel Gines","email":"dangines@gmail.com","username":"danielgines"},"change_message_id":"614e16774e48f50284b48a85c7fdcd98597ec082","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b1a5284c_ff3d2c7d","in_reply_to":"fc75f98d_3a5c4ff4","updated":"2026-11-08 23:22:23.000000000","message":"Bug 2137599 is public now, so I could read it and your patch. The patch compares the project of the resource with the project of the alarm for every alarm, so admin alarms on resources of other projects stop working as well, and it covers only gnocchi_resources_threshold. PS2 restricts the existing alarms in the same way, but an admin can restore them with an update. The next patch set switches the Closes-Bug footer to 2137599.","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"},{"author":{"_account_id":36393,"name":"Callum Dickinson","email":"callum.dickinson@catalystcloud.nz","username":"Callum027","status":"Catalyst Cloud"},"change_message_id":"18d30bbd5d05d40baca05f96aa03f55fb19edcee","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f8af9627_8eefe2ac","in_reply_to":"fc75f98d_3a5c4ff4","updated":"2026-11-08 23:04:47.000000000","message":"My patch resolved the lack of project scoping on the alarm by using the project ID set on the alarm itself; this required passing through the alarm object in a number of places so alarm evaluation can take into account the project without having to set it in the alarm rule metadata.\n\nIt makes the implementation more complicated but it means that existing alarms do not need to be updated, and it means that the project ID does hot have to be set in multiple places.\n\nBug 2137599 will be made public shortly as it is effectively a duplicate of your bug.","commit_id":"e8f7005f41c3f152dcf5f523a1106777b0f8dad0"}]}