)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a4e79282f71f4fc37bf8420d7cf137f1afac368a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"89b7ce4f_fd71356c","updated":"2022-11-18 14:35:15.000000000","message":"Hey all. Jan and I dove into the spec and relevant sections of existing code and replied inline to your feedback.\n\nPlease kindly take another look, so we can update the spec again accordingly.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"44e9beb76b8b356a1f33e35cc59e3c9d5ded0349","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"18d4ffed_7ce30da6","updated":"2022-11-15 10:28:07.000000000","message":"I\u0027m pretty OK with the direction but I don\u0027t want the Nova API to present a specific state that we would need to keep forever while we already have an existing API that helps to know the right status.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"afdb6c4e0ce9b2135812084a4af1096107ffb39c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"01e103f4_e4e38e57","updated":"2022-11-07 15:26:48.000000000","message":"This is the revised version of the spec once approved for Zed (https://review.opendev.org/c/openstack/nova-specs/+/816542) for updating user data, including the improved design we have discussed.\n\nPlease let me know what you think or if anything is missing.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ab3ff3931bc331159f6a75e0fb43207562094a29","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"17a55e7b_63ebf12f","updated":"2022-11-15 14:23:52.000000000","message":"this is not inline with the direction we discussed after FeatureFreeze.\n\n","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"12287d836529b1c1e38c308c401849bd149d8336","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"8e09c3f1_b335c304","updated":"2022-12-19 12:42:30.000000000","message":"All comments should now be addressed in the updated spec.\n\nI have also rearranged the flow of config drive regeneration as I think that we only need to check whether compute driver supports this when we actually would want to call the RPC method, which is only the last case.\nOtherwise, we would fail even though the compute driver could fulfill the request.","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3ae3e4b867a4d5b8c23060445c7bf1392850a38f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"a99eee7b_6bbe091c","updated":"2022-12-14 14:45:38.000000000","message":"IMHO, we still have a few thoughts that need the spec to be modified for adding more comments about the RPC API and about the os-instance API modification.","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d294608de66da6e24f41a0e937231b088e7cfc85","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"6478f4cf_9546ec13","updated":"2022-12-15 09:53:38.000000000","message":"im holding +2w because i would like to see sylvain\u0027s requests adressed before this is merged and the agreement we reached in https://review.opendev.org/c/openstack/nova-specs/+/863884/5/specs/2023.1/approved/update-userdata.rst#92 added to the spec.\n\nif you repsin this with the comments inline adressed i think we can merge this this week.","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"10f3be8f7ac7e5157240a4fecd34131f1877b724","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"baaf3b01_c64ae4d4","updated":"2022-12-14 14:12:49.000000000","message":"looks good to me","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f911a6398ad1073e9f8234e7da099e3cbbb2024a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"f71836e7_ea4ef19e","updated":"2023-01-09 22:16:13.000000000","message":"Soft -1 but I think setting a flag to trigger configdrive regen would be better.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66b919305ab3ef0efb10c8ceae4fe4a86f656dd1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"ef67e337_b5febb04","updated":"2023-01-02 05:47:47.000000000","message":"im not actully back form pto until thursday but there is one thing i think we should simplifi.\n ","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":34149,"name":"Niklas Schwarz","email":"niklas.schwarz@inovex.de","username":"nschwarz"},"change_message_id":"36e838eafd0ece81d3b0b700934a89ef4a9414f3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"ba245407_86661338","updated":"2024-05-17 09:34:38.000000000","message":"Just one question towards the direction of the spec and the feature:\n\nThe original implementation and than later the spec only wanted to make the userdata field in the database mutable. This is/was a simple change to the api and an increase of the microversion. Because of the discussion around the topic config-drives were added to the spec to be also mutable/regenerated for an update.\n\nI fully agree that both types should support the update of the data if one of them can be updated. But the mechanisms behind the tow methods work differently and for me this indicates that this is a feature which can be split in two different specs and feature to be supported by openstack.\n\nThe first feature would be to update only the userdata field in the database. The second feature would be to regenerate the config drive. This split makes it more simple to include the update of the db field in the next release and the regeneration of the config drive can be discussed and refined and the be shipped later.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d822a9a0e97c4eaa0aa57160200b70eca29e0b99","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":7,"id":"c47873cc_9f710576","in_reply_to":"ba245407_86661338","updated":"2024-05-17 10:16:53.000000000","message":"We previously had stated that updating the db without provideing a mechniume ot update the config drive was incorrect.\n\nif we to split this i would want to see the mechaium to regenerate the config drive be deliverd first before allowing the userdata update feature to proceed.\n\notherwise there is a stong chance that only the database update part would be implmented and im still not ok with implemating that on its own.\n\nwe can see if other are ok with that but config drive users should not be ignored.\n\n\nas a baromiter for where i see the direction of this progressing\n\nim -1 on doing the db update first.\nim -2 on only doing the db update and never the config drive part.\nim +1 on doing the config drive regeneration first and then the db update\nand +2 on doing all of the above in one spec.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"}],"specs/2023.1/approved/update-userdata.rst":[{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"44e9beb76b8b356a1f33e35cc59e3c9d5ded0349","unresolved":true,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"119d48b1_5bec5c4e","line":55,"updated":"2022-11-15 10:28:07.000000000","message":"fwiw, this should also be seen in the os-instance-actions API as another action.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a4e79282f71f4fc37bf8420d7cf137f1afac368a","unresolved":true,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e5821286_6b7cb50c","line":55,"in_reply_to":"119d48b1_5bec5c4e","updated":"2022-11-18 14:35:15.000000000","message":"Yes. Does this need particular mentioning in the spec that this new server action is then accessible via the os-instance-actions API? So I am asking if there is a required change / extention of that API or if that is just working for any type of  action anyways.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"07d3938471d6da8fda4978b23ce6d6ecb8ace625","unresolved":true,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"457560e3_c99886ef","line":55,"in_reply_to":"124d0f81_ed23b983","updated":"2022-12-14 15:33:03.000000000","message":"basically sylvain is asking you to add this either to the work itmes or explcitly say a new instance cation event will be recoreded in the db.\n\nthis will also have an impact on the notifactions since we will have a new action start and end notifcation","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"12287d836529b1c1e38c308c401849bd149d8336","unresolved":false,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"554dae3e_d306c09a","line":55,"in_reply_to":"457560e3_c99886ef","updated":"2022-12-19 12:42:30.000000000","message":"Done","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3ae3e4b867a4d5b8c23060445c7bf1392850a38f","unresolved":true,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"124d0f81_ed23b983","line":55,"in_reply_to":"5ababa78_d7ba0a97","updated":"2022-12-14 14:45:38.000000000","message":"My point was to make sure you will add this when implementing, which is not what I see in the spec.\n\nCould you please modify the spec to explain about this please ?","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fdb7fafd5112890cf7e6e881043f5a873934ff08","unresolved":true,"context_lines":[{"line_number":52,"context_line":""},{"line_number":53,"context_line":"A new server action (``POST /servers/{server_id}/action``) called"},{"line_number":54,"context_line":"``userdata_update`` should be added."},{"line_number":55,"context_line":"This endpoint can be called by the user to request a change in user data."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":58,"context_line":"directly, so the updated user data will be available to the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5ababa78_d7ba0a97","line":55,"in_reply_to":"e5821286_6b7cb50c","updated":"2022-11-18 14:50:19.000000000","message":"there is no requried change to os-instance-actions enpoint but we need to ensure that the user data update is recoded properly there.\nso that there is an audit log and you can check the status/error or the action.\n\nthis is just perserving the same behaivor we have for other instance actions.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"44e9beb76b8b356a1f33e35cc59e3c9d5ded0349","unresolved":true,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"0321c63d_a22d22f5","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"updated":"2022-11-15 10:28:07.000000000","message":"I\u0027m not really happy with this. I\u0027d rather prefer to continue having the same behaviour like for other asynchronous actions we have : for each action we have, we can have a list of events.\n\n\nIn the case of the action named \u0027userdata_update\", I\u0027d then prefer to have an event compute_userdata_updated to only be sent once the reboot is made in the case of a configdrive, and straight emitted in the case of a metadata.\n\nThe user would then see whether the userdata is eventually updated by looking at the Nova os-instance-actions API for that specific action and verify whether the event was emitted or not.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ab3ff3931bc331159f6a75e0fb43207562094a29","unresolved":true,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"6b5a00a7_2ba63734","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"in_reply_to":"0321c63d_a22d22f5","updated":"2022-11-15 14:23:52.000000000","message":"we agreed to not use the varible in system metadata approch.\n\ninstead what we discussed was changing the precondtion to require the server to be stopped/shelved and then having the new instance action regenerate the config drive .","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fdb7fafd5112890cf7e6e881043f5a873934ff08","unresolved":true,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"5b084f56_e16725f0","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"in_reply_to":"27f13543_dff9f939","updated":"2022-11-18 14:50:19.000000000","message":"correct shelve_offloaded instance do not need the config drive to be rebuilt at all becasue it will be recreated when it unshelved wiht the most up to date data.\n\n\nand yes if the instance is not in either the stopped or shelve_offloaded state teh instace actuion shoudl return a 409 conclict since the preconditon is not met.\n\nthere is no need to emit an event, the instance action will etiher be accpected in or rejected based on the state of the vm. the instance action event log will contain the result.\n\nim debating if this should be an async operation\n\ni think it can by syncornos in which case the api responce will contain the succes but we could make it async in which case the api would return a 202 accpted and then you would check the instace action list api to see if it succeded","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"b1d1d8c2c3c6912fadf41d82aa3e7112bbbc7ecc","unresolved":true,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b3958fb5_3863d5c0","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"in_reply_to":"5b084f56_e16725f0","updated":"2022-11-22 16:13:30.000000000","message":"\u003e im debating if this should be an async operation\n\u003e \n\u003e i think it can by syncornos in which case the api responce will contain the succes but we could make it async in which case the api would return a 202 accpted and then you would check the instace action list api to see if it succeded\n\nCertainly giving the user instant feedback on a successful API call is nice.\nBut are not ALL actions async by definition? So the request is responded with 202 and then the result is fetched via the instance action API as you said?","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a4e79282f71f4fc37bf8420d7cf137f1afac368a","unresolved":false,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"27f13543_dff9f939","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"in_reply_to":"6b5a00a7_2ba63734","updated":"2022-11-18 14:35:15.000000000","message":"1. If an instance must be \"stopped\" in order for userdata updates while a config_drive is used,  there is no \"pending\" state the likes of USERDATA_UPDATE_REQUIRES_REBOOT necessary, I agree.\n\n2. If the instance is not in a suitable state the action will just be rejected immediately.\n\n3. If accepted the action emits an event of either \"compute_userdata_updated\" or \"failed\" for that action.\n\n4. May I argue that \"shelved\" instances would not even require an active rebuild of the config drive. While shelved the instance is not currently \"living\" on a compute node and actually does not have a config drive? Or am I mistaken? \n\nIf that was the case, shelved instances with config drive would also allow for immediate updates of the user_data in the DB (like with no config drive).","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"526e0ef1c35320d785040bbf69cd426a8c890d46","unresolved":false,"context_lines":[{"line_number":69,"context_line":"If the driver supports config drive regeneration, a new variable in the"},{"line_number":70,"context_line":"instance\u0027s system metadata (``config_drive_regeneration_required``) is set,"},{"line_number":71,"context_line":"indicating that the config drive requires a rebuild."},{"line_number":72,"context_line":"In this case, the action state will be set to a new value"},{"line_number":73,"context_line":"``USERDATA_UPDATE_REQUIRES_REBOOT``, informing the user that a reboot is"},{"line_number":74,"context_line":"needed in order to complete the user data update. When a reboot is executed,"},{"line_number":75,"context_line":"the driver will check for ``config_drive_regeneration_required`` and call"},{"line_number":76,"context_line":"its config drive regeneration logic if requested."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9eff24d0_f9b97a09","line":73,"range":{"start_line":72,"start_character":0,"end_line":73,"end_character":36},"in_reply_to":"b3958fb5_3863d5c0","updated":"2022-12-13 18:42:21.000000000","message":"we server operations that synconous like\nhttps://docs.openstack.org/api-ref/compute/?expanded\u003d#create-console\n\nServer Diagnostics or server metadata\n\nbut you are right ath other then evacuate the rest all return 202.\nthe fact evacuate returns 200 is proably a bug too.\n\nreturning a 202 is likely more consitent so lets stick with that pattern.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"509892d28836a954684be3987040e9f9baa46449","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7add7951_d21d59ae","line":81,"updated":"2022-11-15 14:32:49.000000000","message":"I might missing some context here but I thought the main feedback from Dan was to bump the RPC version and send the regeneration flag as an RPC parameter. https://review.opendev.org/c/openstack/nova/+/816157/16#message-500f190a16005ff87099d5c6ba35b3e0b31f4737","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"10f3be8f7ac7e5157240a4fecd34131f1877b724","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a1c017f0_a80d12f0","line":81,"in_reply_to":"2f064a40_18e15037","updated":"2022-12-14 14:12:49.000000000","message":"as far as I see user_data is part of the Instance object we send in most of our RPC calls anyway. So if the API loads the instance from the DB updates the user_data in it in memory and sends down that instance object to the compute via the new RPC then 1) the compute will see the new user_data in the instance, 2) it can call instance.save() to persist the new user_data after the config driver regeneration succeeded. So option 1 looks OK to me.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"12287d836529b1c1e38c308c401849bd149d8336","unresolved":false,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a8f7914_d101e239","line":81,"in_reply_to":"4c7c9b0d_6d275c01","updated":"2022-12-19 12:42:30.000000000","message":"Done","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"a4e79282f71f4fc37bf8420d7cf137f1afac368a","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a2057979_ed4efb1f","line":81,"in_reply_to":"4fbc585f_dc1937c3","updated":"2022-11-18 14:35:15.000000000","message":"Our bad. I suppose this RPC bump would be similar to the recently added \"support for volume backed server rebuild\" (https://opendev.org/openstack/nova/commit/30aab9c234035b49c7e2cdc940f624a63eeffc1b), right?\n\nSo the idea is to add a \"rebuild_configdrive\" RPC-method that requires a certain RPC version. That\u0027s much cleaner, I totally agree.\n\nJust one question remains: Where to store / how to handle the new user_data while the \"update_userdata\" action is not done? (see previous discussion: https://review.opendev.org/c/openstack/nova/+/816157/comments/033c59ff_53cd6b34).\n\n1. Should we send it via RPC to the agent then rebuilding the config_drive and on success update the user_data in the database and set the action to \"successful\"?\n\n2. Or should we just attach the action ID via RPC to the agent and rather have it \"fetch\" the userdata from the action?","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"07d3938471d6da8fda4978b23ce6d6ecb8ace625","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4c7c9b0d_6d275c01","line":81,"in_reply_to":"65d51852_831c6c21","updated":"2022-12-14 15:33:03.000000000","message":"well the specific RPC call is the new one that is intoduced for this instance action so i think we are all in agreement that option 1 is the path to take.\n\non the api side fi the compute node is two old the rpc call will fail so that provides the protection we require to mark the instance action as failed and ensure the state in the db is not modifed.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"b19b9f74e91241bbd1efb74ccb940710a01d60a7","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"4fbc585f_dc1937c3","line":81,"in_reply_to":"7add7951_d21d59ae","updated":"2022-11-16 04:10:32.000000000","message":"That was my understanding as well, to not create a \"shadow RPC\" call in this manner.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"3ae3e4b867a4d5b8c23060445c7bf1392850a38f","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"65d51852_831c6c21","line":81,"in_reply_to":"a1c017f0_a80d12f0","updated":"2022-12-14 14:45:38.000000000","message":"Here the context from Dan is to make sure we can ping the nova-compute service by RPC for knowing whether it can recreate the configdrive.\n\nThis is not really a concern on how to save the modified userdata. So, while I agree with gibi here on the fact an instance.save() is enough to persist the modification, we still need to make sure we can have a specific RPC call for it.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"526e0ef1c35320d785040bbf69cd426a8c890d46","unresolved":true,"context_lines":[{"line_number":78,"context_line":"Depending on the result of the config drive regeneration, the action state"},{"line_number":79,"context_line":"will either be set to ``Done`` (if successful) or ``Failed`` if any errors"},{"line_number":80,"context_line":"occured during regeneration."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"Alternatives"},{"line_number":83,"context_line":"------------"},{"line_number":84,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"2f064a40_18e15037","line":81,"in_reply_to":"a2057979_ed4efb1f","updated":"2022-12-13 18:42:21.000000000","message":"we have 2 options\n\neither the payload of the new instance action can be the content of the new userdtata which we can pass via rpc to the comptue which will update it in the db and regenerate teh confgi drive.\n\n\nor  the new action should take no payload adn just triger the config drive to be regenerated from the current metadata.\n\nso i think option 1 include the data in the rpc and commit it to the db from the compute.\n\nthat a bit inefficent but it proably is the more consitent way to do this.\n\nyour option 2 will not work as there is no way for the agent to \"fetch\" the userdata form the action.","commit_id":"a5d8feafebbee34b4b3f10789c9923e6adbabe63"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"07d3938471d6da8fda4978b23ce6d6ecb8ace625","unresolved":true,"context_lines":[{"line_number":127,"context_line":"Notifications impact"},{"line_number":128,"context_line":"--------------------"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"None"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Other end user impact"},{"line_number":133,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a9357cce_581349d9","line":130,"updated":"2022-12-14 15:33:03.000000000","message":"we woudl jsut need the new action start and end notification for this","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"12287d836529b1c1e38c308c401849bd149d8336","unresolved":false,"context_lines":[{"line_number":127,"context_line":"Notifications impact"},{"line_number":128,"context_line":"--------------------"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"None"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"Other end user impact"},{"line_number":133,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"99a1761c_2cdda235","line":130,"in_reply_to":"a9357cce_581349d9","updated":"2022-12-19 12:42:30.000000000","message":"Done","commit_id":"197971ded63ef83a9af2df5b1410cd185a1dcdc1"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66b919305ab3ef0efb10c8ceae4fe4a86f656dd1","unresolved":true,"context_lines":[{"line_number":58,"context_line":"according instance action event will be recorded in the database."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"The handling of updates will be different, depending on whether the"},{"line_number":61,"context_line":"instance is configured via metadata service or via config drive."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"}],"source_content_type":"text/x-rst","patch_set":6,"id":"0f3a72aa_a8f4260a","line":61,"updated":"2023-01-02 05:47:47.000000000","message":"at the compute agent perhaps but the work flow at the api should be identical.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"b34dad4e10d24da587fec3a3d78953edc2ec6c7b","unresolved":true,"context_lines":[{"line_number":58,"context_line":"according instance action event will be recorded in the database."},{"line_number":59,"context_line":""},{"line_number":60,"context_line":"The handling of updates will be different, depending on whether the"},{"line_number":61,"context_line":"instance is configured via metadata service or via config drive."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"}],"source_content_type":"text/x-rst","patch_set":6,"id":"0ab082be_78db82c6","line":61,"in_reply_to":"0f3a72aa_a8f4260a","updated":"2023-01-09 15:22:42.000000000","message":"Yep, will update the wording here.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66b919305ab3ef0efb10c8ceae4fe4a86f656dd1","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":6,"id":"67977a08_fee5ff7a","line":66,"updated":"2023-01-02 05:47:47.000000000","message":"im not sure if we need this complexity.\n\nhow are you going to know if the instnqace is using config drive.\n\nare you going to check the instance system metadata to see if the vm is booted with config drive.\n\nthis is an option but it would requrie two code path to update the userdata.\n\nits proably better to just alway make the rpc call passing the user-data\nbut have the compute agent skip regenerating the config drive if the vms does not have a config drive.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f911a6398ad1073e9f8234e7da099e3cbbb2024a","unresolved":false,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":6,"id":"d97c339a_4ec59c04","line":66,"in_reply_to":"33acc66d_89d4a7a7","updated":"2023-01-09 22:16:13.000000000","message":"I agree that it\u0027s more work to do the configdrive thing. It seems nice from the user\u0027s perspective, but I\u0027m not sure it\u0027s really worth it. Instances using config drives could also be looking at the metadata server, and it would be unfortunate to force those to go through a reboot cycle just to make the API call work.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"b34dad4e10d24da587fec3a3d78953edc2ec6c7b","unresolved":false,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":6,"id":"33acc66d_89d4a7a7","line":66,"in_reply_to":"67977a08_fee5ff7a","updated":"2023-01-09 15:22:42.000000000","message":"Yes, the thought was to query the instance\u0027s system metadata to check whether it uses a config drive, like in the initial implementation.\n\nComplexity-wise, I agree that it would be cleaner to just have one code path for that. If there are no implications with calling the RPC method every time (e. g. performance, dependence on RPC / updated agents), and no one else disagrees, I guess I can update the spec accordingly.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f911a6398ad1073e9f8234e7da099e3cbbb2024a","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ce9be335_dfded81e","line":93,"updated":"2023-01-09 22:16:13.000000000","message":"I think what I\u0027d prefer is to just set a flag that the compute manager will check on next boot. Like, we could shove a flag into system_metadata that says \"config drive is dirty\". Then whenever we go to start an instance, we check that flag and regenerate like we normally would on hard reboot, initial boot, or whatever.\n\nDoing it in the context of an RPC call means it needs to complete within the timeout of an http (and rpc) call. Also, unless you provide a lock to prevent it from happening more than once, you could be adding a sort of DoS attack vector for the user to take against the compute.\n\nSetting the flag and letting it be regenerated on next boot puts like activities together.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"1de901593da57485f7da4c0eccf315a3f7f66771","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"b3e3d5ef_2f54c2fb","line":93,"in_reply_to":"4a4e84ad_7cec60c2","updated":"2023-02-07 18:00:05.000000000","message":"Ok, that makes sense.\n\nSo the proposal would be to still use a flag (like config_drive_dirty in the initial implementation) and additionally check during the HTTP call if the RPC version of the compute host that instance is currently living on is new enough. We would still require instances to be stopped. Whenever the instance is started again, compute driver checks the flag and regenerates config drive if True. To my understanding, this approach would basically replace the last step in the spec\u0027s current version.\n\nSince this is yet another approach that differs from what we agreed on after Zed\u0027s feature freeze, I would be happy to hear other opinions on this @Sean @gibi @Sylvain.","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d986cf5b96eb83c38dd359739cc331fe10d7d78e","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"4a4e84ad_7cec60c2","line":93,"in_reply_to":"8d52e24c_c23a58e0","updated":"2023-01-23 18:05:15.000000000","message":"What I said is that if we\u0027re going to do it as part of the reboot, it needs to be a flag to the RPC call so that we\u0027re not subverting the RPC interface\u0027s versioning scheme, effectively making a call we expect to have certain characteristics not represented by the version we asked for, not knowing if the other side is actually new enough or not. That\u0027s the thing I was concerned about there.\n\nMaking a *new* synchronous RPC call that must do substantial IO on the destination machine within the timeout of an HTTP request (and the MQ timeout for that matter) is also problematic for other reasons, as described above.\n\nIf you use a flag on the instance, which has the implication on \"next boot\" then we do not need to make the synchronous call. The flag is also not specifically related to any RPC call that fails to cover it in the versioning scheme, so we\u0027re not subverting that. Finally, you can check the service version of the host the instance is on (and yes, bump it for this feature) to make sure that it will honor it at next boot before you tell the HTTP requester that \"yes, I will schedule that to be done.\"","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e1f200505bbf81d0b9a254c4634f6fdc477871dd","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"c05d2cfc_7f0ccfec","line":93,"in_reply_to":"90fe4173_4be24840","updated":"2024-05-14 11:32:59.000000000","message":"Did we settle this on the PTG (my memory is failing)? This comment suggests a flag and that the config drive regeneration is tight to the instance reboot. The PTG etherpad says \"the RPC async cast is needed for checking you have a recent enough compute to handle your request\" and the current spec PS7 states that \"Call a new RPC method which starts the config drive regeneration.\n  If successful, update action state to ``compute_userdata_updated``, or\n  ``Failed`` otherwise.\"","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b5d0fe138266a24d20e50f4744a67a48716aa770","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"90fe4173_4be24840","line":93,"in_reply_to":"b3e3d5ef_2f54c2fb","updated":"2024-04-07 05:29:55.000000000","message":"@dan didnt you ahve an issue with use updating the","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"},{"author":{"_account_id":33634,"name":"Jan Hartkopf","email":"j@hartkopf.io","username":"jhartkopf"},"change_message_id":"42e8e19e0d0e0d369578aef060e56c142838ff5a","unresolved":true,"context_lines":[{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"},{"line_number":93,"context_line":"increase."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"The new user data will be sent along with the RPC request, starting the"},{"line_number":96,"context_line":"config drive regeneration. Only if it was successful, the new user data will"}],"source_content_type":"text/x-rst","patch_set":6,"id":"8d52e24c_c23a58e0","line":93,"in_reply_to":"ce9be335_dfded81e","updated":"2023-01-23 16:16:13.000000000","message":"Correct me if I\u0027m wrong, but wasn\u0027t that your proposal to use RPCs in the first place (https://review.opendev.org/c/openstack/nova-specs/+/863884/1..6/specs/2023.1/approved/update-userdata.rst#100)? Could you further elaborate on this?\n\nBy \"regenerate like we normally would\" you mean calling already existing methods? So we would not need to create a new RPC method just for config drive regen?","commit_id":"efe79ed0625ce0f01d6dd0d1d1c112297373050a"}],"specs/2024.2/approved/update-userdata.rst":[{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"84471d5401d98d5a8d322d23230d4e436b33ab54","unresolved":true,"context_lines":[{"line_number":45,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":46,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":47,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":48,"context_line":"update has been applied."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Proposed change"},{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2dd0d081_fb7a2c7f","line":48,"updated":"2024-04-05 23:02:25.000000000","message":"To my current understanding, cloud-init only expects to run once on first boot -- it records that it has run and unless the instance \"changes\" (changed UUID etc) it wont reconfigure the instance. So if the user-data is updated, what would trigger cloud-init to rerun, especially if a reboot is not initiated as part of the process?","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":32755,"name":"Christian Rohmann","email":"christian.rohmann@inovex.de","username":"frittentheke"},"change_message_id":"7dfd82d9ee0377db041d66c3d6d27827a7d443bc","unresolved":true,"context_lines":[{"line_number":45,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":46,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":47,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":48,"context_line":"update has been applied."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Proposed change"},{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2c06bd79_25a9534c","line":48,"in_reply_to":"23d9761b_844b089b","updated":"2024-04-08 09:38:07.000000000","message":"Cloud-init does have a concept of \"first boot\" [1], so it does not behave differently if the user_data is changed afterwards. But it can be configured to (selectively) update some config on every boot. See [2]/[3].\n\nAs explained modifiable user_data is supported on other Cloud implementations (AWS, Azure, GCP) and there cloud-init is certainly used extensively as well.\n\nThere are also events [4], but support for these is a whole different story and likely even more specific to cloud-init.\n\n\n[1] https://cloudinit.readthedocs.io/en/latest/explanation/boot.html#first-boot-determination\n[2] https://github.com/canonical/cloud-init/issues/3463\n[3] https://bugs.launchpad.net/cloud-init/+bug/1847583\n[4] https://cloudinit.readthedocs.io/en/latest/explanation/events.html#id1","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b5d0fe138266a24d20e50f4744a67a48716aa770","unresolved":true,"context_lines":[{"line_number":45,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":46,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":47,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":48,"context_line":"update has been applied."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Proposed change"},{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d0580207_6ba29bc9","line":48,"in_reply_to":"2dd0d081_fb7a2c7f","updated":"2024-04-07 05:29:55.000000000","message":"we disccused this in the past.\n\ni dont recally the deatails but apprenntly you can dconfigure cloud-init to run some configuration on every boot vs first boot.\n\nits been a few years at this point to the details are fuzzy but for those not using  config drive espically we anted to decouple the reboot form the updating of the userdata avaiable form the metadata api so that the user could initia the reboot seperatly when convienent to do so or configure there workload to pool for updates asycronoshly vai another means.\n\n\nif i recall correctly the orginal user didnt use config drive an only used the metadat api but obviouly we would want any solution to be functionally equivlent even if it was delayed in the config drive case.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"f8069bd753d9141cd90dfb0bffd4ad4efda66531","unresolved":true,"context_lines":[{"line_number":45,"context_line":"cloud-init, I would like to manage my stateful workload via user data and"},{"line_number":46,"context_line":"metadata on each boot. Metadata is used to store my external configuration"},{"line_number":47,"context_line":"while user data is used to perform operations like rejoining a cluster when the"},{"line_number":48,"context_line":"update has been applied."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"Proposed change"},{"line_number":51,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":7,"id":"23d9761b_844b089b","line":48,"in_reply_to":"d0580207_6ba29bc9","updated":"2024-04-08 04:38:27.000000000","message":"Its also possible to read this metadata with something other than cloud-init, but the reality is that _most_ people simply use cloud-init. I think if we\u0027re going to add things which can change post first boot, it would also be reasonable to ask if the cloud-init team has been consulted or informed of the plan.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"84471d5401d98d5a8d322d23230d4e436b33ab54","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"0e2a0a6d_40a4684e","line":66,"updated":"2024-04-05 23:02:25.000000000","message":"Both the metadata server and the config drive are versioned. Are you proposing bumping the version of the openstack metadata in order to indicate to clients that this functionality is now available? That\u0027s happened a bunch in the past, so it should be a relatively well trod path, but its still important I think.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b5d0fe138266a24d20e50f4744a67a48716aa770","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"a5c92e0a_85d1217e","line":66,"in_reply_to":"0e2a0a6d_40a4684e","updated":"2024-04-07 05:29:55.000000000","message":"we have not modifed the metadata in a long time.\nim not sure if we have continued bumping the version in the meatadata the last few time we did change them or not.\n\nthe version we have however is not a microverions \nwe only changed it in the past if we added new files/fileds or change the over all layout.\n\ni dont think we have bumped it for behaivoral change before.\n\nim not nessisaly agains that but i dont think we have an api contract today that say we should do that.\n\nfor example at one point we added the ablity for the admin passwored to be set once by the instance writhing back to the metadata api when cloudbase-init generated a password on windwos. i dont know if we singled that via a version bump or not\n\nnon of the api versioning rule we have for the main api apply to the metadata api\nso other then inspcating t he data based directory structure for specific files and there content there isnt really any client discorvableiyt built into the metadata api content.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"53c0c1dcd2d8ec35dc88a68f82da35b286e40e8a","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"40dd540c_9dff6f58","line":66,"in_reply_to":"1a5d0338_0c301e0d","updated":"2024-04-12 07:34:46.000000000","message":"I think it enables a capability downstream. If I as a reader of the metadata know that some of it might change because of this feature, I know I should check back regularly to re-read my config. As of now cloud-init et al only read this stuff on first boot and will ignore changes later unless you get lucky.\n\nAdditionally, a version bump was the pattern we set back in the day, and doing it doesn\u0027t really cost us anything, so why not?","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d822a9a0e97c4eaa0aa57160200b70eca29e0b99","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"524485c3_0ded333c","line":66,"in_reply_to":"40dd540c_9dff6f58","updated":"2024-05-17 10:16:53.000000000","message":"because we only do version bumps when the structure changes i.e we add or remove fields \n\nthis would be reusing the mechanism for a different use case.\n\nthere are already cases where the content of the metadata API can change.\n\nit changes every time we add or remove a volume or interface to the instance\nor if you add/remove server metadata\n\nwhich is updating user data special that it requires a new version to signal?\n\nwe alredy regenreate a new config drive for cross cell migration and the other operation that dan noted so to me this is not impacting the metadat api verions\n\nclients should already expect that the content of user do data could change on any boot.\n\nwe can add a new version but if we do that we wouldl not present the orginal user data under the old version and only expose the updated userdata under latests/2024.2 or whatever we used as the date for the version.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":2271,"name":"Michael Still","email":"mikal@stillhq.com","username":"mikalstill"},"change_message_id":"f8069bd753d9141cd90dfb0bffd4ad4efda66531","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"e4c67c1a_5aa94712","line":66,"in_reply_to":"a5c92e0a_85d1217e","updated":"2024-04-08 04:38:27.000000000","message":"Here are the previous versions:\n\nFOLSOM \u003d \u00272012-08-10\u0027\nGRIZZLY \u003d \u00272013-04-04\u0027\nHAVANA \u003d \u00272013-10-17\u0027\nLIBERTY \u003d \u00272015-10-15\u0027\nNEWTON_ONE \u003d \u00272016-06-30\u0027\nNEWTON_TWO \u003d \u00272016-10-06\u0027\nOCATA \u003d \u00272017-02-22\u0027\nROCKY \u003d \u00272018-08-27\u0027\nVICTORIA \u003d \u00272020-10-14\u0027\n\nWe certainly _used_ to bump the version when we changed something. I don\u0027t see any changes since commit 916ffddca8d41daa367cf819e14827cf4b4180a5 (when the Victoria version was added) that weren\u0027t internal only with the exception of perhaps 1bf45c47205057801129dc20153de0a98d9c4e08.\n\nThat is, these have previously been versioned. Maybe one change has escaped versioning, but that doesn\u0027t seem like a strong reason to give up on versioning entirely.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3190e8f6cf0c6b297cb58be9370e6be4a43b749a","unresolved":true,"context_lines":[{"line_number":63,"context_line":"If the instance uses the metadata service, user data will be updated"},{"line_number":64,"context_line":"directly and is then available to the instance. The according action state"},{"line_number":65,"context_line":"will be set to ``compute_userdata_updated``, indicating that the user data"},{"line_number":66,"context_line":"update has been successfully applied."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."}],"source_content_type":"text/x-rst","patch_set":7,"id":"1a5d0338_0c301e0d","line":66,"in_reply_to":"e4c67c1a_5aa94712","updated":"2024-04-11 14:38:46.000000000","message":"I\u0027m not really sure why we need a version bump for this. The structure is not changing and no new stuff is being added to the blob that isn\u0027t already there. We already regenerate the configdrive in various places like unshelve, evacuate, cross-cell migration, etc. I\u0027m not sure how this is different. It seems like communicating that this is available is more of a REST API microversion sort of thing.\n\nCan you articulate more of why you think the consumer of the metadata stuff needs to know that this is possible?","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e1f200505bbf81d0b9a254c4634f6fdc477871dd","unresolved":true,"context_lines":[{"line_number":67,"context_line":""},{"line_number":68,"context_line":"Otherwise, if the instance uses a config drive, the config drive,"},{"line_number":69,"context_line":"holding the user data, requires regeneration."},{"line_number":70,"context_line":"As this is dependent on the configured compute driver, user data updates"},{"line_number":71,"context_line":"for config drives will only be available with compute drivers implementing"},{"line_number":72,"context_line":"config drive regeneration."},{"line_number":73,"context_line":""},{"line_number":74,"context_line":"When the action is called, the following will be executed in order:"},{"line_number":75,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"33f8072a_1f42dad7","line":72,"range":{"start_line":70,"start_character":0,"end_line":72,"end_character":26},"updated":"2024-05-14 11:32:59.000000000","message":"This means we might have an issue with shelve_offloaded instances as there we don\u0027t know if the virt driver supports regeneration or not as we don\u0027t know which compute the instance will land during unshelve.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e1f200505bbf81d0b9a254c4634f6fdc477871dd","unresolved":true,"context_lines":[{"line_number":76,"context_line":"* If instance state is not ``STOPPED``, ``SHELVED`` or ``SHELVED_OFFLOADED``,"},{"line_number":77,"context_line":"  return 409."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* If instance state is ``SHELVED`` or ``SHELVED_OFFLOADED``, user data can be"},{"line_number":80,"context_line":"  directly updated in the database since ``UNSHELVE`` will automatically"},{"line_number":81,"context_line":"  (re-)create the config drive. Update metadata and return 202."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Otherwise, instance state is ``STOPPED``. Check if compute driver supports"},{"line_number":84,"context_line":"  config drive regeneration. If not, return 409 and update action"}],"source_content_type":"text/x-rst","patch_set":7,"id":"81d7799e_7be25253","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":63},"updated":"2024-05-14 11:32:59.000000000","message":"What will trigger the completion of the instance action in this case? Does the API completes the instance action as no RPC can be used for a shelved_offloaded instance? What if the instance will land on a compute after unshelve that has a virt driver that does not support the config drive regeneration?","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f024456208b028ac87d99497d2cbccb7c6a2c0e5","unresolved":true,"context_lines":[{"line_number":76,"context_line":"* If instance state is not ``STOPPED``, ``SHELVED`` or ``SHELVED_OFFLOADED``,"},{"line_number":77,"context_line":"  return 409."},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* If instance state is ``SHELVED`` or ``SHELVED_OFFLOADED``, user data can be"},{"line_number":80,"context_line":"  directly updated in the database since ``UNSHELVE`` will automatically"},{"line_number":81,"context_line":"  (re-)create the config drive. Update metadata and return 202."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"* Otherwise, instance state is ``STOPPED``. Check if compute driver supports"},{"line_number":84,"context_line":"  config drive regeneration. If not, return 409 and update action"}],"source_content_type":"text/x-rst","patch_set":7,"id":"756dcaa1_184b79bc","line":81,"range":{"start_line":79,"start_character":0,"end_line":81,"end_character":63},"in_reply_to":"81d7799e_7be25253","updated":"2024-05-28 13:36:20.000000000","message":"It could just not do the RPC if it\u0027s in offloaded state. Shelved would have the same RPC call as normal, right?","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e1f200505bbf81d0b9a254c4634f6fdc477871dd","unresolved":true,"context_lines":[{"line_number":86,"context_line":""},{"line_number":87,"context_line":"* Call a new RPC method which starts the config drive regeneration."},{"line_number":88,"context_line":"  If successful, update action state to ``compute_userdata_updated``, or"},{"line_number":89,"context_line":"  ``Failed`` otherwise."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new RPC method will be used to ensure that only updated compute hosts"},{"line_number":92,"context_line":"can start config drive regeneration. This will be accompanied by a RPC version"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4f8aec83_f4b3dc14","line":89,"updated":"2024-05-14 11:32:59.000000000","message":"I feel like there is a discrepancy between this statement, the comment form Dan about doing the regen at reboot at https://review.opendev.org/c/openstack/nova-specs/+/863884/7#message-d986cf5b96eb83c38dd359739cc331fe10d7d78e and the PTG etherpad.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"e1f200505bbf81d0b9a254c4634f6fdc477871dd","unresolved":true,"context_lines":[{"line_number":220,"context_line":"   * - Zed"},{"line_number":221,"context_line":"     - Reproposed"},{"line_number":222,"context_line":"   * - Antelope"},{"line_number":223,"context_line":"     - Reproposed"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9cbe9da2_80dffda5","line":223,"updated":"2024-05-14 11:32:59.000000000","message":"Would be nice to add the Dalmatian here now.","commit_id":"8162e70bd3b15f6ba34b5c661f867480df71ca76"}]}