)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6a754f96d3ae230077b438715cd3840b93f70b84","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"91c870b2_e5fe96c7","updated":"2025-01-08 14:39:36.000000000","message":"This might be a bug to be fixed not a new feature.","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"67046a7961583a8952e76ae5f8d456b7bef202c3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"d745cfda_a949f5c8","updated":"2025-06-20 10:37:42.000000000","message":"Looks good to me.","commit_id":"1103094177520659699181268b6fbc0b582a38bd"}],"specs/2025.1/approved/add-mutual-prefix.rst":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6a754f96d3ae230077b438715cd3840b93f70b84","unresolved":true,"context_lines":[{"line_number":21,"context_line":"using config files (provider.yaml)."},{"line_number":22,"context_line":"https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In this configuration file, even if the values of custom traits are modified or"},{"line_number":25,"context_line":"the trait is deleted, the original trait does not be removed from the target"},{"line_number":26,"context_line":"resource provider."},{"line_number":27,"context_line":"In scenarios where the custom traits registered with the resource provider"},{"line_number":28,"context_line":"change infrequently, and old custom traits affect scheduling, this behavior can"},{"line_number":29,"context_line":"be a problem."}],"source_content_type":"text/x-rst","patch_set":2,"id":"635a31b1_216cf172","line":26,"range":{"start_line":24,"start_character":0,"end_line":26,"end_character":18},"updated":"2025-01-08 14:39:36.000000000","message":"In the provider.yaml definition the admin can specify \"additional\" traits to be added to the RP top of what nova-compute would generate. So if such \"additional\" trait is then removed from the provider.yaml file then I would expect that next time when nova-compute re-generates the provider tree the additional trait will not be added to the tree and during syncing that to placement the trait list is overwritten.\n\nSo it feels like a bug. @smooney@redhat.com what do you think?","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":37390,"name":"Masanori Kuroha","display_name":"Masanori Kuroha","email":"mkuroha@lycorp.co.jp","username":"mkuroha"},"change_message_id":"e92ea398792f59adc69a658c7e92ca4b6f952e0b","unresolved":true,"context_lines":[{"line_number":21,"context_line":"using config files (provider.yaml)."},{"line_number":22,"context_line":"https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In this configuration file, even if the values of custom traits are modified or"},{"line_number":25,"context_line":"the trait is deleted, the original trait does not be removed from the target"},{"line_number":26,"context_line":"resource provider."},{"line_number":27,"context_line":"In scenarios where the custom traits registered with the resource provider"},{"line_number":28,"context_line":"change infrequently, and old custom traits affect scheduling, this behavior can"},{"line_number":29,"context_line":"be a problem."}],"source_content_type":"text/x-rst","patch_set":2,"id":"29577ddc_79ae85ac","line":26,"range":{"start_line":24,"start_character":0,"end_line":26,"end_character":18},"in_reply_to":"635a31b1_216cf172","updated":"2025-05-16 10:07:42.000000000","message":"@gibizer@gmail.com Thank you for your comment.\n\nI updated this nova-spec to reflect the results of this PTG discussion and this PoC: https://review.opendev.org/c/openstack/nova/+/948304","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4be64db8b23608bfe77233d052599b3ef1e3ae59","unresolved":true,"context_lines":[{"line_number":21,"context_line":"using config files (provider.yaml)."},{"line_number":22,"context_line":"https://docs.openstack.org/nova/latest/admin/managing-resource-providers.html"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"In this configuration file, even if the values of custom traits are modified or"},{"line_number":25,"context_line":"the trait is deleted, the original trait does not be removed from the target"},{"line_number":26,"context_line":"resource provider."},{"line_number":27,"context_line":"In scenarios where the custom traits registered with the resource provider"},{"line_number":28,"context_line":"change infrequently, and old custom traits affect scheduling, this behavior can"},{"line_number":29,"context_line":"be a problem."}],"source_content_type":"text/x-rst","patch_set":2,"id":"d762a7a9_75db0e86","line":26,"range":{"start_line":24,"start_character":0,"end_line":26,"end_character":18},"in_reply_to":"635a31b1_216cf172","updated":"2025-06-20 17:14:55.000000000","message":"so from my perspective the current behavior is intended behaviour.\nThe current API contract, as I understand it, allows operators to add CUSTOM_ traits to any RP via the placement rest API, and Nova is required to preserve them.\nnote that we supproted operators defineing custom traits on nova created resouce providers before we intoduced provier.yaml.\n\nAs such, when we remove a CUSTOM_ treat from the provider.yaml nova cannot tell the difference between a trait added by the API and the file.\n\n--- 5 months later ---\nso i woudl treat this clean up as a new feature not a bug. we dicsused this in the ptg and agreed on a new  dierrction which is now captured in v5","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3a142f9017ea7e6225fe7e1c42436d6042a83b65","unresolved":true,"context_lines":[{"line_number":26,"context_line":"resource provider."},{"line_number":27,"context_line":"In scenarios where the custom traits registered with the resource provider"},{"line_number":28,"context_line":"change infrequently, and old custom traits affect scheduling, this behavior can"},{"line_number":29,"context_line":"be a problem."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Use Cases"},{"line_number":32,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a7f0e379_a7debddc","line":29,"updated":"2024-12-16 03:55:04.000000000","message":"In our usecase, the problem happens in the traits replace scenario.","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":37390,"name":"Masanori Kuroha","display_name":"Masanori Kuroha","email":"mkuroha@lycorp.co.jp","username":"mkuroha"},"change_message_id":"e92ea398792f59adc69a658c7e92ca4b6f952e0b","unresolved":true,"context_lines":[{"line_number":26,"context_line":"resource provider."},{"line_number":27,"context_line":"In scenarios where the custom traits registered with the resource provider"},{"line_number":28,"context_line":"change infrequently, and old custom traits affect scheduling, this behavior can"},{"line_number":29,"context_line":"be a problem."},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Use Cases"},{"line_number":32,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"389aabf1_f5d101d1","line":29,"in_reply_to":"a7f0e379_a7debddc","updated":"2025-05-16 10:07:42.000000000","message":"Thank you for the additional information. I have also mentioned the replacement in the spec.","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3a142f9017ea7e6225fe7e1c42436d6042a83b65","unresolved":true,"context_lines":[{"line_number":58,"context_line":"    traits:"},{"line_number":59,"context_line":"      additional:"},{"line_number":60,"context_line":"        - \u0027CUSTOM_EXAMPLE_TRAIT_A\u0027"},{"line_number":61,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE_TRAIT_A\u0027"},{"line_number":62,"context_line":"      mutual_prefix:"},{"line_number":63,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE\u0027"},{"line_number":64,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"0415bd42_f7a5fb33","line":61,"updated":"2024-12-16 03:55:04.000000000","message":"The `mutual_prefix` looks an extra property for the additional traits. So I feel extra key-value style is easier to manage the prefix.\n\n\n```suggestion\n      additional:\n        - \u0027CUSTOM_EXAMPLE_TRAIT_A\u0027:\n            mutual_prefix: \u0027CUSTOM_TEST_EXAMPLE\u0027\n```","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3a142f9017ea7e6225fe7e1c42436d6042a83b65","unresolved":true,"context_lines":[{"line_number":59,"context_line":"      additional:"},{"line_number":60,"context_line":"        - \u0027CUSTOM_EXAMPLE_TRAIT_A\u0027"},{"line_number":61,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE_TRAIT_A\u0027"},{"line_number":62,"context_line":"      mutual_prefix:"},{"line_number":63,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE\u0027"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"- Only one custom trait (``CUSTOM_TEST_EXAMPLE_TRAIT_A`` in the example above)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d3065da1_fb602c0e","line":62,"updated":"2024-12-16 03:55:04.000000000","message":"The value of `mutual_prefix` is list form. So is it okay to set two mutual_prefix, `CUSTOM_EXAMPLE` and `CUSTOM_TEST_EXAMPLE`?","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4be64db8b23608bfe77233d052599b3ef1e3ae59","unresolved":true,"context_lines":[{"line_number":59,"context_line":"      additional:"},{"line_number":60,"context_line":"        - \u0027CUSTOM_EXAMPLE_TRAIT_A\u0027"},{"line_number":61,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE_TRAIT_A\u0027"},{"line_number":62,"context_line":"      mutual_prefix:"},{"line_number":63,"context_line":"        - \u0027CUSTOM_TEST_EXAMPLE\u0027"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"- Only one custom trait (``CUSTOM_TEST_EXAMPLE_TRAIT_A`` in the example above)"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b04ed69c_0a016640","line":62,"in_reply_to":"d3065da1_fb602c0e","updated":"2025-06-20 17:14:55.000000000","message":"the problem with mutal_prfix (i dont think this a good name for this by the way)\nis it does not work when upggrading exisitng deployments,\nwe cannot modify flavors/images to request the new traits instead.\n\nso to me this both complicates teh usage of the feature as the same prefix need to be used on all host and does not work for exisiting deployments.","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"},{"author":{"_account_id":8878,"name":"Masahito Muroi","email":"masahito.muroi@linecorp.com","username":"masa"},"change_message_id":"3a142f9017ea7e6225fe7e1c42436d6042a83b65","unresolved":true,"context_lines":[{"line_number":74,"context_line":"- If multiple custom traits with the same mutual_prefix are specified in the"},{"line_number":75,"context_line":"  additional section, the behavior is that only the first one is registered."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"- If the mutual_prefix is not specified, or if custom traits without"},{"line_number":78,"context_line":"  mutual_prefix are used, the current behavior is the same. In other words, if"},{"line_number":79,"context_line":"  ``CUSTOM_EXAMPLE_TRAIT_A`` is deleted or updated, the trait will remain in"},{"line_number":80,"context_line":"  the resource provider."}],"source_content_type":"text/x-rst","patch_set":2,"id":"0870c3bd_3f28bfff","line":77,"updated":"2024-12-16 03:55:04.000000000","message":"Which is it prefix match pattern, longest match or shortest match?","commit_id":"e393aaff3d2547413f7377713a2ef05e8a1206b6"}],"specs/2025.2/approved/copy-applied-provider-yaml.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4be64db8b23608bfe77233d052599b3ef1e3ae59","unresolved":true,"context_lines":[{"line_number":96,"context_line":""},{"line_number":97,"context_line":"No performance impact on nova is anticipated. If there are frequent updates to"},{"line_number":98,"context_line":"custom traits, requests for deleting and creating traits will be frequently"},{"line_number":99,"context_line":"sent to the Placement API."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":"Other deployer impact"},{"line_number":102,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"6ee632c7_7d96faf5","line":99,"updated":"2025-06-20 17:14:55.000000000","message":"today i dont think we treate provide.yaml as mutable config\nso this would mean you would have to restart your compute agent often and if your restarting the compute agent we are already doing a lot of work and updating the inventory on start. so i agree the the incremental overhead of this is minimal compared to the work we are already doing on an nova-compute agent restart.","commit_id":"1103094177520659699181268b6fbc0b582a38bd"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4be64db8b23608bfe77233d052599b3ef1e3ae59","unresolved":true,"context_lines":[{"line_number":145,"context_line":"Testing"},{"line_number":146,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"- Add unit/functional tests"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Documentation Impact"},{"line_number":151,"context_line":"\u003d\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":5,"id":"efbb65d5_63854e7e","line":148,"updated":"2025-06-20 17:14:55.000000000","message":"i generrally agree with this level of testing.\n\nwe could optionally extened on of the post run hooks like \n\nhttps://github.com/openstack/nova/blob/master/gate/post_test_hook.sh\n\nto update the provider file and restart the agent \n\nbut i dont think that is required. if we want to add extra testign like that we can discuss it in the implemetion.\n\nas this requires modifying the fiels on disk and restarting the agent its not in scope fo tempest.","commit_id":"1103094177520659699181268b6fbc0b582a38bd"}]}
