)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"f87ea3cb266497d06b40710aecb2ac9a061c468a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"5e61e818_58aae900","updated":"2026-04-16 15:31:51.000000000","message":"I wonder if we should rather replace keystoneclient by SDK and use the classes implemented there, if that\u0027s the pattern we\u0027ve already made in the other resources ?","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":13177,"name":"Emma Foley","email":"efoley@redhat.com","username":"emma-l-foley"},"change_message_id":"037cdf640fb5c92393ba0bc4d44fba321710360a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"9546c746_39bbbeb8","updated":"2026-04-27 11:18:40.000000000","message":"Okay, so now I\u0027m waiting for some decision from cores on whether the ceilometer custom data types are go/no-go. Juan gave a +2 previously, Takashi gave a minus 1 and Jaromir indicated that he\u0027s okay with keeping it if I think it\u0027s useful.\nTBH, I\u0027d lean towards keeping it for nova, since it\u0027s less work now that it\u0027s in, but that\u0027s not a good reason.\nI **think** that most of the work to migrate to the SDK is done, since the end result is that we have a datatype that shares an interface with the actual nova server objects, so the tricky transition with the non-matching attributes is done. Skipping the custom datatypes might be fairly straightforward. (I may regret saying that)","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":34975,"name":"Jaromír Wysoglad","email":"jwysogla@redhat.com","username":"jwysogla"},"change_message_id":"af195f261b6c168f662810532e60629a3f067183","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"39ece406_bb078448","updated":"2026-05-04 09:24:44.000000000","message":"This is fine by me. I think it was discussed thoroughly enough and it\u0027s sitting here long enough. If we decide that we really need to get rid of the abstractions, we can do it in a followup as well.","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":34975,"name":"Jaromír Wysoglad","email":"jwysogla@redhat.com","username":"jwysogla"},"change_message_id":"cbaf3d199e9d4970c674d02a989204f3de78fc28","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"e7d19dc2_459f4693","in_reply_to":"31321509_89cb7947","updated":"2026-04-22 07:49:59.000000000","message":"I hope future changes to openstacksdk won\u0027t be too much of a problem, since I can imagine it\u0027d create issues across a lot of other services as well.\n\nThis is a pretty simple abstraction, so if you Emma think it\u0027s useful and especially if you think we\u0027ll need similar for nova, I\u0027m OK with keeping it.","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":13177,"name":"Emma Foley","email":"efoley@redhat.com","username":"emma-l-foley"},"change_message_id":"d17869842e85980220e951a5d2690885c19d3b0a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"e57e1d44_75bf7838","in_reply_to":"5e61e818_58aae900","updated":"2026-04-17 15:39:02.000000000","message":"The main reason for proposing it this way was to provide a compatibility layer as we migrated from keystoneclient to openstacksdk, and limit the size of the objects that we pass around (and the data that we log as well).\n\nSome ceilometer code uses sdk objects directly, but other use custom classes (e.g. NovaLikeServer in the novaclient.\n\nUsing custom data classes limits the impact of future changes to the openstacksdk e.g. if field names change, so that we don\u0027t have to change that name everywhere.","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":32968,"name":"Juan Larriba","email":"jlarriba@redhat.com","username":"jlarriba"},"change_message_id":"552fc1109e5861a048617be1d9a3305b470d4f07","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"07032d10_c3ca2987","in_reply_to":"9546c746_39bbbeb8","updated":"2026-05-04 07:40:14.000000000","message":"I will let Jaromir and/or Takashi to decide on this regard.","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":13177,"name":"Emma Foley","email":"efoley@redhat.com","username":"emma-l-foley"},"change_message_id":"79e3a6f9a66804ba72e7618513b3217701e00ec8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"31321509_89cb7947","in_reply_to":"e57e1d44_75bf7838","updated":"2026-04-17 20:10:56.000000000","message":"It would probably simplify things to use the sdk resources.\nI foresee some issues with nova/glance migration, since the novaclient relies on images in its implementation. Perhaps aiming to keep it simple here and stick with what we already have, and then consider this approach of introducing custom dataclasses in the more complex cases.\n\nI can propose a change using sdk objects, unless there are other strong opinions for/against it.\nI\u0027ll leave the review as-is for a while, since it\u0027s the weekend here anyway.","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"},{"author":{"_account_id":13177,"name":"Emma Foley","email":"efoley@redhat.com","username":"emma-l-foley"},"change_message_id":"8c0711cb69d138ab90d80222715213c74ae65e11","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"4d63599a_05b0d733","in_reply_to":"e7d19dc2_459f4693","updated":"2026-04-24 18:34:50.000000000","message":"One benefit is that it encodes what information that we actually use","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"}],"ceilometer/keystone_client.py":[{"author":{"_account_id":34975,"name":"Jaromír Wysoglad","email":"jwysogla@redhat.com","username":"jwysogla"},"change_message_id":"cbaf3d199e9d4970c674d02a989204f3de78fc28","unresolved":true,"context_lines":[{"line_number":102,"context_line":"        :param kwargs: Attribute filters used to locate the project, e.g."},{"line_number":103,"context_line":"            ``name\u003d\u0027myproject\u0027``, ``domain_id\u003d\u0027\u003cuuid\u003e\u0027``. All keyword"},{"line_number":104,"context_line":"            arguments are forwarded to the underlying ``find`` call."},{"line_number":105,"context_line":"        :returns: A single ``Project`` resource"},{"line_number":106,"context_line":"            object whose attributes match all supplied filters."},{"line_number":107,"context_line":"        :raises ceilometer.exceptions.NotFound: if no project matches"},{"line_number":108,"context_line":"            the filters."}],"source_content_type":"text/x-python","patch_set":5,"id":"7960a6a9_f39aec95","line":105,"updated":"2026-04-22 07:49:59.000000000","message":"we should have a similar update to the other docstrings","commit_id":"d1abb065b35f274765faf6516d08151eb870dcbf"}]}