)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"b41b1aff3b592cb1b6bd8f8d9edcf8c1d6771170","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"66345c71_e4c4df4c","updated":"2024-12-12 13:08:37.000000000","message":"@Jan I think this will fix the problem with pep8 running on ubuntu-noble: https://review.opendev.org/c/openstack/cinder/+/926485","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@purestorage.com","username":"sdodsley"},"change_message_id":"0f5f7c1527c043114975e274e50b3ed18e87f10a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"f16dc8c0_ac0cdb84","updated":"2026-02-19 14:43:28.000000000","message":"Changing vote as this has not been progress in over a year - potentially abandon","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@purestorage.com","username":"sdodsley"},"change_message_id":"9e42498bf1441ee6949c227999665dc454469fa2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"df82b4d0_0baa3cf1","updated":"2024-12-18 15:52:17.000000000","message":"I\u0027m OK with this moving forward as long as we don\u0027t add this into the cinder support matrix.\nMy one concern is how this will work in a DCN deployment and multiple compute AZs, where connectivity between computes can be completely isolated.","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"016a10552143670b16b39faa5e70dd64ba46cd9d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"b772c14c_c5e3ba0a","updated":"2024-12-11 13:47:56.000000000","message":"Looks like the pep8 job failure is that a wheel couldn\u0027t be built on ubuntu-noble.  Hopefully the next patch set will land on ubuntu-jammy.","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fa5e90daa84e23d7d1315e8f546efdbe4e519283","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"d4915af6_6d5c741f","updated":"2024-12-17 22:05:47.000000000","message":"Thanks Jan and sorry it took long to circle back to this.\nMost of the concerns are addressed in your replies. Regarding the discussion of move vs transfer vs relocate, we can discuss that in the cinder meeting today and reach a consensus.","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"f1543168_61ccf471","updated":"2024-12-09 15:04:21.000000000","message":"Thanks for proposing Jan. There was a lot to grasp here but I\u0027ve some questions and suggestions inline. To summarize the major concerns:\n\n1. Being a cinder team member for forever, volume transfer and snapshot transfer are keywords that I can\u0027t remap in my head being associated to migration of volume and it confused me every time i encountered them in any paragraph. Is there a reason for not using moved/migrated instead of transfer, that would be much more helpful though I would like to hear other core members opinion on this.\nAlso to note, transfer in context of data is acceptable but in context of volumes/snapshots is confusing so I don\u0027t recommend to change every occurrence of the word \u0027transfer\u0027.\n2. Migrating snapshots with volumes every time seems too complex and a lot can go wrong there, I would recommend to keep it optional and only allow when needed via a config option\n3. The need to access cinder DB in a HCI setup is something that seems to have a big deployment impact since I\u0027m unsure if we copy the cinder DB credentials to compute nodes for any other deployment use case","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"3739a67f640a935f408c7bf6a0070ab1b3c97cad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"b9019833_a03bbdfb","in_reply_to":"66345c71_e4c4df4c","updated":"2024-12-12 13:29:17.000000000","message":"Actually, that won\u0027t fix it because it\u0027s in a different repo!  Here is a patch for cinder-specs: https://review.opendev.org/c/openstack/cinder-specs/+/937620","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fa5e90daa84e23d7d1315e8f546efdbe4e519283","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"ff53a1eb_3623ba90","in_reply_to":"956ea7d9_9dac6e04","updated":"2024-12-17 22:05:47.000000000","message":"1. You are right that this is not the typical migration operation we perform in cinder. Relocation sounds like a good option but as i mentioned, if other reviewers agree that \u0027transfer\u0027 is good enough in this context, I won\u0027t block it for that.\n2. Thanks for considering about making snapshots optional though it\u0027s a good/needed feature to have if we encounter a case where we need to use it.\n3. Right, if there is no way around then at least it should be documented to make informed decisions while deploying with this driver.","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"2963eaab6547e78092e788319cde60dddc197231","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"0d7a9db3_e507376f","in_reply_to":"b772c14c_c5e3ba0a","updated":"2024-12-11 14:58:08.000000000","message":"Thanks for the hint. It does work locally in a ubuntu noble container once I install `libpcre3-dev`. Do you know where I need to add this dependency?","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0d0b3643fa0c94065f2da7312fd6b0e492632081","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"956ea7d9_9dac6e04","in_reply_to":"f1543168_61ccf471","updated":"2024-12-09 19:02:07.000000000","message":"Thanks for the feedback Rajat. \n\n1. I can definitly understand that this is confusing. Initially I started using the term `migration` and at the time also wanted to resue the cinder volume migration mechanism. During implementation of the proof of concept I realized that the process of volume \"movement\" needed to differ from what is referred to by cinder as `migration`. I thought that using `migration` could lead to confusion, since it could be misunderstood to mean *the* cinder volume migration, especially since both meanings would be required in the documentation of the driver.\nCinder already uses:\nmigration: moving volumes between services\nclone: creating copies of volumes\nreplication: mirroring volumes\ntransfer: moving volumes between projects\nOf the above `transfer` seemed to be the best candidate to overload with another meaning, since it would not be used in the context of a volume driver.\nI think technically (from the result, not the process) it is a migration by the cinder definition, but might get confused with the existing mechanism.\nI have also since searched for further synonyms of migration and found `relocation`, which is not used in the cinder context yet.\nI am going to update your other comments reagrdings this once a suitable candidate is found.\n\n2. Snapshots do add a lot of complexity and I would have avoided them altogether in this driver if they were not a requirement. Making this feature optional should not be a problem though.\n\n3. I guess right now no production environment would deploy a volume-service on a compute node and I think nova, by design, does not require database access from services deployed on compute nodes.\nUnfortunately I see no way around this, while sticking to implementing the concept as a volume driver (The alternative being to implement the concept in a standalone service with its own API and RPC and only implementing a stub volume driver, that talks to the service API and runs in the control plane).\nThis should definitly be documented in a prominent place, so that people can make an informed decision whether this driver satisfies their security requirements.","commit_id":"859cd91a1bd744afa37305e2c25fee101b43f8a1"}],"specs/2025.1/add-dmclone-driver.rst":[{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"ea9e7974d6158ea08bc60733e8c0ab09b1376a37","unresolved":true,"context_lines":[{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"#TODO"},{"line_number":12,"context_line":"https://blueprints.launchpad.net/cinder/+spec/example"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":".. note::"},{"line_number":15,"context_line":"   Although the term *transfer* in the context of the OpenStack block-storage"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f5ef860_350ffe84","line":12,"updated":"2024-11-15 13:51:23.000000000","message":"Naming things is hard, so I wanted to ask before creating the actual blueprint.\nProposal: dmclone-local-storage-driver","commit_id":"49f9edf1c3f57eea5ae0709b5a85b0a143a6987b"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"#TODO"},{"line_number":12,"context_line":"https://blueprints.launchpad.net/cinder/+spec/example"},{"line_number":13,"context_line":""},{"line_number":14,"context_line":".. note::"},{"line_number":15,"context_line":"   Although the term *transfer* in the context of the OpenStack block-storage"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2429b708_45bbba06","line":12,"in_reply_to":"5f5ef860_350ffe84","updated":"2024-12-09 15:04:21.000000000","message":"sounds good to me","commit_id":"49f9edf1c3f57eea5ae0709b5a85b0a143a6987b"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":14,"context_line":".. note::"},{"line_number":15,"context_line":"   Although the term *transfer* in the context of the OpenStack block-storage"},{"line_number":16,"context_line":"   service is used to describe the movement of volumes between projects,"},{"line_number":17,"context_line":"   throughout this document it will be used to refer to the process of moving"},{"line_number":18,"context_line":"   volumes between different volume services and thus hypervisors."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"This blueprint proposes a new volume driver which will serve volumes based on"},{"line_number":21,"context_line":"local storage. Volumes will be transferred transparently to the required"}],"source_content_type":"text/x-rst","patch_set":6,"id":"37c310aa_896613c9","line":18,"range":{"start_line":17,"start_character":28,"end_line":18,"end_character":10},"updated":"2024-12-09 15:04:21.000000000","message":"i feel live migration or volume migration would be a more suitable","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":37535,"name":"Florent Le Lain","display_name":"flelain","email":"florent.le-lain@ovhcloud.com","username":"flelain"},"change_message_id":"d0dfa69aaa01811bd65810320ca452e0bc8ec845","unresolved":true,"context_lines":[{"line_number":14,"context_line":".. note::"},{"line_number":15,"context_line":"   Although the term *transfer* in the context of the OpenStack block-storage"},{"line_number":16,"context_line":"   service is used to describe the movement of volumes between projects,"},{"line_number":17,"context_line":"   throughout this document it will be used to refer to the process of moving"},{"line_number":18,"context_line":"   volumes between different volume services and thus hypervisors."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"This blueprint proposes a new volume driver which will serve volumes based on"},{"line_number":21,"context_line":"local storage. Volumes will be transferred transparently to the required"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9886b161_1f13aa20","line":18,"range":{"start_line":17,"start_character":28,"end_line":18,"end_character":10},"in_reply_to":"37c310aa_896613c9","updated":"2024-12-11 14:30:27.000000000","message":"+1 here","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":18,"context_line":"   volumes between different volume services and thus hypervisors."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"This blueprint proposes a new volume driver which will serve volumes based on"},{"line_number":21,"context_line":"local storage. Volumes will be transferred transparently to the required"},{"line_number":22,"context_line":"compute node using the device mapper clone target [1]_. With this method"},{"line_number":23,"context_line":"volumes will be accessible almost instantaneously on the attaching hypervisor."},{"line_number":24,"context_line":"Writes will always be local to the hypervisor and data will copied in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"d7fa7ff3_774a50be","line":21,"range":{"start_line":21,"start_character":31,"end_line":21,"end_character":42},"updated":"2024-12-09 15:04:21.000000000","message":"moved/migrated\n\npersonally i feel it is more confusing to use transfer as the keyword here","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"5d72c078837c365d40d25c79a3447b9c605a6a3f","unresolved":true,"context_lines":[{"line_number":18,"context_line":"   volumes between different volume services and thus hypervisors."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"This blueprint proposes a new volume driver which will serve volumes based on"},{"line_number":21,"context_line":"local storage. Volumes will be transferred transparently to the required"},{"line_number":22,"context_line":"compute node using the device mapper clone target [1]_. With this method"},{"line_number":23,"context_line":"volumes will be accessible almost instantaneously on the attaching hypervisor."},{"line_number":24,"context_line":"Writes will always be local to the hypervisor and data will copied in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"a7348386_5efe90cc","line":21,"range":{"start_line":21,"start_character":31,"end_line":21,"end_character":42},"in_reply_to":"2a517022_9f0094d2","updated":"2024-12-12 08:24:58.000000000","message":"I have outlined my thoughts in Rajat\u0027s general feedback above:\nhttps://review.opendev.org/c/openstack/cinder-specs/+/935347/comments/f1543168_61ccf471\n\n\u003e I can definitly understand that this is confusing. Initially I started using the term migration and at the time also wanted to resue the cinder volume migration mechanism. During implementation of the proof of concept I realized that the process of volume \"movement\" needed to differ from what is referred to by cinder as migration. I thought that using migration could lead to confusion, since it could be misunderstood to mean the cinder volume migration, especially since both meanings would be required in the documentation of the driver.\nCinder already uses:\nmigration: moving volumes between services\nclone: creating copies of volumes\nreplication: mirroring volumes\ntransfer: moving volumes between projects\nOf the above transfer seemed to be the best candidate to overload with another meaning, since it would not be used in the context of a volume driver.\nI think technically (from the result, not the process) it is a migration by the cinder definition, but might get confused with the existing mechanism.\nI have also since searched for further synonyms of migration and found relocation, which is not used in the cinder context yet.\n\n\nI am not fixed on any specific wording here and will change it to whatever is favored by the community","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9d069768cad388276e01c703605810a545d1cde1","unresolved":true,"context_lines":[{"line_number":18,"context_line":"   volumes between different volume services and thus hypervisors."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"This blueprint proposes a new volume driver which will serve volumes based on"},{"line_number":21,"context_line":"local storage. Volumes will be transferred transparently to the required"},{"line_number":22,"context_line":"compute node using the device mapper clone target [1]_. With this method"},{"line_number":23,"context_line":"volumes will be accessible almost instantaneously on the attaching hypervisor."},{"line_number":24,"context_line":"Writes will always be local to the hypervisor and data will copied in the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"2a517022_9f0094d2","line":21,"range":{"start_line":21,"start_character":31,"end_line":21,"end_character":42},"in_reply_to":"d7fa7ff3_774a50be","updated":"2024-12-12 01:52:54.000000000","message":"I agree with Rajat here.  Is there a reason why you don\u0027t want to call this \"migration\"?","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":37535,"name":"Florent Le Lain","display_name":"flelain","email":"florent.le-lain@ovhcloud.com","username":"flelain"},"change_message_id":"d0dfa69aaa01811bd65810320ca452e0bc8ec845","unresolved":true,"context_lines":[{"line_number":32,"context_line":"storage. As its name implies it is ephemeral in the sense that it is bound to"},{"line_number":33,"context_line":"the lifecycle of an instance. However, managing compute resources and storage"},{"line_number":34,"context_line":"in a cloud-native way usually requires storage to be decoupled from compute."},{"line_number":35,"context_line":"Another way to make local storage available is to use PCI-passthrough with"},{"line_number":36,"context_line":"NVMes. Additional to the inherent inflexibility of this approach it binds the"},{"line_number":37,"context_line":"instance using this kind of storage to the hypervisor, preventing"},{"line_number":38,"context_line":"live-migration."}],"source_content_type":"text/x-rst","patch_set":6,"id":"f37a45d8_afaca612","line":35,"updated":"2024-12-11 14:30:27.000000000","message":"Instance disk may also be on the compute, which lets you both take advantage of performance and live migration feature.\nNow, it\u0027s not additional volume in the form of a block-storage and consequently not managed in such a way.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0996c64640b20e17013dbc283e991608deebd892","unresolved":true,"context_lines":[{"line_number":32,"context_line":"storage. As its name implies it is ephemeral in the sense that it is bound to"},{"line_number":33,"context_line":"the lifecycle of an instance. However, managing compute resources and storage"},{"line_number":34,"context_line":"in a cloud-native way usually requires storage to be decoupled from compute."},{"line_number":35,"context_line":"Another way to make local storage available is to use PCI-passthrough with"},{"line_number":36,"context_line":"NVMes. Additional to the inherent inflexibility of this approach it binds the"},{"line_number":37,"context_line":"instance using this kind of storage to the hypervisor, preventing"},{"line_number":38,"context_line":"live-migration."}],"source_content_type":"text/x-rst","patch_set":6,"id":"b1d9deab_a85934f9","line":35,"in_reply_to":"f37a45d8_afaca612","updated":"2024-12-11 15:22:43.000000000","message":"The idea is to make local storage usable in a cloud native way. So that you can bundle your app and let it run anywhere with the required amount of storage, extend the storage later if required and reschedule your app without worrying about where your data is.\n\nOf course this can all be done manually now, but the whole idea of the cloud is to provide easy abstractions so that users do not need to worry about all this, right?","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":64,"context_line":""},{"line_number":65,"context_line":"A new volume driver will be added which will provide volumes based on local"},{"line_number":66,"context_line":"storage and return connectors of ``\"driver_volume_type\": \"local\"`` for these"},{"line_number":67,"context_line":"volumes. Upon attachment, volumes will be transferred to the volume service"},{"line_number":68,"context_line":"residing on the host shown in the ``connector`` object."},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The actual transferal will be handled by the Linux kernel\u0027s device mapper clone"}],"source_content_type":"text/x-rst","patch_set":6,"id":"baf26245_e4ceb422","line":67,"range":{"start_line":67,"start_character":42,"end_line":67,"end_character":53},"updated":"2024-12-09 15:04:21.000000000","message":"migrated/moved","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":75,"context_line":"The device-mapper clone target"},{"line_number":76,"context_line":"------------------------------"},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"The Linux kernel\u0027s device-mapper clone target [1]_ allows to create a copies of"},{"line_number":79,"context_line":"block devices in the background, while being able to access and use the"},{"line_number":80,"context_line":"destination device transparently. The nature of the source device is"},{"line_number":81,"context_line":"irrelevant, i.e. it can be a local device or a device accessible via network by"},{"line_number":82,"context_line":"any means of transport, e.g. iSCSI, NVMeoF, etc.."}],"source_content_type":"text/x-rst","patch_set":6,"id":"d31bd5fc_0ecfac6b","line":79,"range":{"start_line":78,"start_character":68,"end_line":79,"end_character":13},"updated":"2024-12-09 15:04:21.000000000","message":"a copy of block device\nOR\ncopies of block devices","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":125,"context_line":"  remote host, allowing immediate local attachment of the volume on the remote"},{"line_number":126,"context_line":"  host"},{"line_number":127,"context_line":"* A periodic job on each volume service checks all volumes which are in the"},{"line_number":128,"context_line":"  process of being transferred and, once data transfer is done, finishes the"},{"line_number":129,"context_line":"  process and cleans up the source volume"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Since writes are always handled locally to the node they occur on, no actual"}],"source_content_type":"text/x-rst","patch_set":6,"id":"558d48a3_409bfab1","line":128,"range":{"start_line":128,"start_character":19,"end_line":128,"end_character":30},"updated":"2024-12-09 15:04:21.000000000","message":"this usage of transfer doesn\u0027t seem correct since we are talking in context of volumes","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":125,"context_line":"  remote host, allowing immediate local attachment of the volume on the remote"},{"line_number":126,"context_line":"  host"},{"line_number":127,"context_line":"* A periodic job on each volume service checks all volumes which are in the"},{"line_number":128,"context_line":"  process of being transferred and, once data transfer is done, finishes the"},{"line_number":129,"context_line":"  process and cleans up the source volume"},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Since writes are always handled locally to the node they occur on, no actual"}],"source_content_type":"text/x-rst","patch_set":6,"id":"76d7ee51_7cc51368","line":128,"range":{"start_line":128,"start_character":46,"end_line":128,"end_character":54},"updated":"2024-12-09 15:04:21.000000000","message":"this usage of transfer is correct since we are referring to data transfer here","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":37535,"name":"Florent Le Lain","display_name":"flelain","email":"florent.le-lain@ovhcloud.com","username":"flelain"},"change_message_id":"d0dfa69aaa01811bd65810320ca452e0bc8ec845","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Since writes are always handled locally to the node they occur on, no actual"},{"line_number":132,"context_line":"multi-attachments can be supported using the device-mapper clone target."},{"line_number":133,"context_line":"However, multi-attachments on two nodes for the **same** instance are a"},{"line_number":134,"context_line":"prerequisite for live-migration of instances with attached volumes [2]_. In"},{"line_number":135,"context_line":"this scenario writes will only occur on either the source node, before the"},{"line_number":136,"context_line":"instance is migrated or on the destination node after a successful"},{"line_number":137,"context_line":"live-migration. With these preconditions it is possible to attach the volume on"}],"source_content_type":"text/x-rst","patch_set":6,"id":"a14713cd_e51f4f55","line":134,"updated":"2024-12-11 14:30:27.000000000","message":"Is it? We\u0027re migrating instances with multi-attachment\u003dfalse in our context.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0996c64640b20e17013dbc283e991608deebd892","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Since writes are always handled locally to the node they occur on, no actual"},{"line_number":132,"context_line":"multi-attachments can be supported using the device-mapper clone target."},{"line_number":133,"context_line":"However, multi-attachments on two nodes for the **same** instance are a"},{"line_number":134,"context_line":"prerequisite for live-migration of instances with attached volumes [2]_. In"},{"line_number":135,"context_line":"this scenario writes will only occur on either the source node, before the"},{"line_number":136,"context_line":"instance is migrated or on the destination node after a successful"},{"line_number":137,"context_line":"live-migration. With these preconditions it is possible to attach the volume on"}],"source_content_type":"text/x-rst","patch_set":6,"id":"cdd2f1c6_7f38e069","line":134,"in_reply_to":"a14713cd_e51f4f55","updated":"2024-12-11 15:22:43.000000000","message":"I see how this is confusing. The first usage of multi-attachment refers to the cinder feature, while the second usage refers to the fact that during live-migration there are multiple (two) attachments for the same instance on different nodes, which is allowed even for drivers that do not support multi-attachment (the feature)\n\n\n\nI could probably just remove the second \"multi-\" and it would make more sense","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":145,"context_line":"Besides support for local connections, the driver also needs to handle remote"},{"line_number":146,"context_line":"connections for multiple reasons:"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Source volumes need to be connected to the destination. Ideally this will"},{"line_number":149,"context_line":"  reuse the existing attachment API and target driver subsystem."},{"line_number":150,"context_line":"* Host-assisted volume migrations copy data between volumes on the source"},{"line_number":151,"context_line":"  node. The newly created remote volume thus needs to be attached there."},{"line_number":152,"context_line":"* The backup service requires remote connections."}],"source_content_type":"text/x-rst","patch_set":6,"id":"24e9114d_8d050669","line":149,"range":{"start_line":148,"start_character":58,"end_line":149,"end_character":64},"updated":"2024-12-09 15:04:21.000000000","message":"This is a deployment detail but we need storage network between the compute nodes where the cinder-volume service resides (which are using dm-clone driver) otherwise the hydration will take forever causing performance issues with volume read/writes.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0d0b3643fa0c94065f2da7312fd6b0e492632081","unresolved":true,"context_lines":[{"line_number":145,"context_line":"Besides support for local connections, the driver also needs to handle remote"},{"line_number":146,"context_line":"connections for multiple reasons:"},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* Source volumes need to be connected to the destination. Ideally this will"},{"line_number":149,"context_line":"  reuse the existing attachment API and target driver subsystem."},{"line_number":150,"context_line":"* Host-assisted volume migrations copy data between volumes on the source"},{"line_number":151,"context_line":"  node. The newly created remote volume thus needs to be attached there."},{"line_number":152,"context_line":"* The backup service requires remote connections."}],"source_content_type":"text/x-rst","patch_set":6,"id":"60685e40_dbc427fd","line":149,"range":{"start_line":148,"start_character":58,"end_line":149,"end_character":64},"in_reply_to":"24e9114d_8d050669","updated":"2024-12-09 19:02:07.000000000","message":"That is true, I will add that to the `Other deployer impact` section.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":157,"context_line":"#. The necessity of a remote connection"},{"line_number":158,"context_line":"#. The ID of a source volume when a local connection on a remote node is"},{"line_number":159,"context_line":"   required"},{"line_number":160,"context_line":"#. Whether hydration should be enabled or not"},{"line_number":161,"context_line":"   Alternative: Query the number of local ``in-use`` attachments of the source"},{"line_number":162,"context_line":"   volume from the destination node and decide from there whether to enable or"},{"line_number":163,"context_line":"   not"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Implementation"},{"line_number":166,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"66e7d1dc_554efece","line":163,"range":{"start_line":160,"start_character":3,"end_line":163,"end_character":6},"updated":"2024-12-09 15:04:21.000000000","message":"Is disabling hydration for the case when live migration has failed?","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0d0b3643fa0c94065f2da7312fd6b0e492632081","unresolved":true,"context_lines":[{"line_number":157,"context_line":"#. The necessity of a remote connection"},{"line_number":158,"context_line":"#. The ID of a source volume when a local connection on a remote node is"},{"line_number":159,"context_line":"   required"},{"line_number":160,"context_line":"#. Whether hydration should be enabled or not"},{"line_number":161,"context_line":"   Alternative: Query the number of local ``in-use`` attachments of the source"},{"line_number":162,"context_line":"   volume from the destination node and decide from there whether to enable or"},{"line_number":163,"context_line":"   not"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Implementation"},{"line_number":166,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"80ef125b_62eb8bb2","line":163,"range":{"start_line":160,"start_character":3,"end_line":163,"end_character":6},"in_reply_to":"66e7d1dc_554efece","updated":"2024-12-09 19:02:07.000000000","message":"I removed this line, because I wanted to go with the alternative and not use `volume_admin_metadata` to excessively.\n\nDisabling hydration is a general requirement for live-migration.\nFor live-migration nova will create an attachment on the destination node for the volume. After the attachment was created successfully nova will do some pre-copy of the instance data and then pause the instance, do the final copy and start the instance on the destination node (or start copying afterwards in case of post-copy mode).\nFrom cinder and the drivers perspective there is no way to know when writes will stop on the source and start on the destination node. If hydration were to be enabled immediately with the attachment (as it would normally be the case), regions could have been copied to the destination volume and get written to afterwards on the source volume. Thus leading to stale data on the destination, which would get read after the migration succeeds.\nIf hydration is disabled writes can occur on the source for as long as the instance is still running there and they will get read from the remote source once the instance is started on the destination.\nWrites will of course always be local to the node the instance is actually running on, so the driver cannot tolerate an instance moving back to the source (stale data on the source). This is however (to the best of my knowledge) never the case: The instance either starts on the destination and live-migration succeeds or it does not start and gets removed and the instance on the source gets unpaused.\n\nHydration must only be enabled once live-migration is successful. It is tied to the termination of the connection of the source volume in this concept.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fa5e90daa84e23d7d1315e8f546efdbe4e519283","unresolved":true,"context_lines":[{"line_number":157,"context_line":"#. The necessity of a remote connection"},{"line_number":158,"context_line":"#. The ID of a source volume when a local connection on a remote node is"},{"line_number":159,"context_line":"   required"},{"line_number":160,"context_line":"#. Whether hydration should be enabled or not"},{"line_number":161,"context_line":"   Alternative: Query the number of local ``in-use`` attachments of the source"},{"line_number":162,"context_line":"   volume from the destination node and decide from there whether to enable or"},{"line_number":163,"context_line":"   not"},{"line_number":164,"context_line":""},{"line_number":165,"context_line":"Implementation"},{"line_number":166,"context_line":"--------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ceff046a_fc3a9705","line":163,"range":{"start_line":160,"start_character":3,"end_line":163,"end_character":6},"in_reply_to":"80ef125b_62eb8bb2","updated":"2024-12-17 22:05:47.000000000","message":"Thanks for the explanation, sounds good.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":192,"context_line":"transfer with the dm-clone target, which makes it an ideal candidate as a"},{"line_number":193,"context_line":"general volume construction, for consistency reasons."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"A volume will thus always consist of an ``lv`` with either a linear- or clone"},{"line_number":196,"context_line":"target on top, through which it is accessed."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"In case the special ``volume_admin_metadata`` key ``dmclone:source`` is present"}],"source_content_type":"text/x-rst","patch_set":6,"id":"6b071727_9339d172","line":195,"range":{"start_line":195,"start_character":67,"end_line":195,"end_character":68},"updated":"2024-12-09 15:04:21.000000000","message":"nit: remove this","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":344,"context_line":"If the ``volume_admin_metadata`` key ``dmclone:source`` is found, a clone"},{"line_number":345,"context_line":"target will be added after finding the metadata ``lv`` and establishing the"},{"line_number":346,"context_line":"connection to the source volume from the existing remote attachment. If no"},{"line_number":347,"context_line":"metadata ``lv`` is found the volume status is set to *maintenance* and an"},{"line_number":348,"context_line":"exception is raised. Hydration is enabled according to the value of"},{"line_number":349,"context_line":"``volume_admin_metadata`` key ``dmclone:hydration``."},{"line_number":350,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"bef19960_a12d30d6","line":347,"range":{"start_line":347,"start_character":54,"end_line":347,"end_character":65},"updated":"2024-12-09 15:04:21.000000000","message":"we do not support any state as maintenance. I think we can set it to error in this case.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":362,"context_line":"Extend volume"},{"line_number":363,"context_line":"^^^^^^^^^^^^^"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"As of the writing of this spec, the dm-clone target does **not** support being"},{"line_number":366,"context_line":"extended [3]_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Therefore volume extension will be limited to volumes not in the process of"},{"line_number":369,"context_line":"being transferred."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"If the driver finds a clone target for a volume an exception will be raised."},{"line_number":372,"context_line":"For linear targets the underlying ``lv`` will be extended first. This is not"},{"line_number":373,"context_line":"done through the parent class\u0027s ``extend_volume()`` method, because that would"},{"line_number":374,"context_line":"pass the request to the target driver, which is not needed for a local device."},{"line_number":375,"context_line":"Afterwards the top-level linear target will be reloaded with the new size."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Snapshots"},{"line_number":378,"context_line":"^^^^^^^^^"},{"line_number":379,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"2bcbff88_79702355","line":376,"range":{"start_line":365,"start_character":0,"end_line":376,"end_character":0},"updated":"2024-12-09 15:04:21.000000000","message":"As i can see, we do support extending the LVM volumes but not when they are being moved i.e. if there is attach or live-migrate operation -- which is expected behavior.\n\nCan you rewrite this section in a way that says extend is supported for LVM volumes by driver extend + reloading the linear target (last paragraph) and then mention the exceptions where we won\u0027t be able to extend but also mention that it is expected behavior.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0d0b3643fa0c94065f2da7312fd6b0e492632081","unresolved":true,"context_lines":[{"line_number":362,"context_line":"Extend volume"},{"line_number":363,"context_line":"^^^^^^^^^^^^^"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"As of the writing of this spec, the dm-clone target does **not** support being"},{"line_number":366,"context_line":"extended [3]_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Therefore volume extension will be limited to volumes not in the process of"},{"line_number":369,"context_line":"being transferred."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"If the driver finds a clone target for a volume an exception will be raised."},{"line_number":372,"context_line":"For linear targets the underlying ``lv`` will be extended first. This is not"},{"line_number":373,"context_line":"done through the parent class\u0027s ``extend_volume()`` method, because that would"},{"line_number":374,"context_line":"pass the request to the target driver, which is not needed for a local device."},{"line_number":375,"context_line":"Afterwards the top-level linear target will be reloaded with the new size."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Snapshots"},{"line_number":378,"context_line":"^^^^^^^^^"},{"line_number":379,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"fd99cf5b_58ac69a6","line":376,"range":{"start_line":365,"start_character":0,"end_line":376,"end_character":0},"in_reply_to":"2bcbff88_79702355","updated":"2024-12-09 19:02:07.000000000","message":"Yes, in general extend is supported.\n\nSo if I understand correctly it is expected that this will not be possible during volume attachment or live-migration. In the case of this driver, e.g. the attachment will be shown as being complete to the user, but data transfer will still be ongoing in the background for an undeterminable amount of time. This will not be visible to the user however, so failure cannot be expected by them.\n\nIn any case I will rewrite this section in the requested manner","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fa5e90daa84e23d7d1315e8f546efdbe4e519283","unresolved":true,"context_lines":[{"line_number":362,"context_line":"Extend volume"},{"line_number":363,"context_line":"^^^^^^^^^^^^^"},{"line_number":364,"context_line":""},{"line_number":365,"context_line":"As of the writing of this spec, the dm-clone target does **not** support being"},{"line_number":366,"context_line":"extended [3]_."},{"line_number":367,"context_line":""},{"line_number":368,"context_line":"Therefore volume extension will be limited to volumes not in the process of"},{"line_number":369,"context_line":"being transferred."},{"line_number":370,"context_line":""},{"line_number":371,"context_line":"If the driver finds a clone target for a volume an exception will be raised."},{"line_number":372,"context_line":"For linear targets the underlying ``lv`` will be extended first. This is not"},{"line_number":373,"context_line":"done through the parent class\u0027s ``extend_volume()`` method, because that would"},{"line_number":374,"context_line":"pass the request to the target driver, which is not needed for a local device."},{"line_number":375,"context_line":"Afterwards the top-level linear target will be reloaded with the new size."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Snapshots"},{"line_number":378,"context_line":"^^^^^^^^^"},{"line_number":379,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"8345c479_b2401cf3","line":376,"range":{"start_line":365,"start_character":0,"end_line":376,"end_character":0},"in_reply_to":"fd99cf5b_58ac69a6","updated":"2024-12-17 22:05:47.000000000","message":"I understand that but extend is a mandatory feature so it\u0027s better to say \"extend is supported but only when X conditions are met\" rather than starting the section with extend feature not being supported which puts a negative impression in reviewer\u0027s mind. (Basically i don\u0027t want the spec to be blocked for being misinterpreted).\n\nAlso we can fail the extend with a helpful error message like \"Hydration is ongoing, please check these admin metadata fields to confirm if hydration is completed or not\" but that\u0027s an implementation detail.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":400,"context_line":"be available on the destination host. Additionally for writes to the"},{"line_number":401,"context_line":"destination target to be considered local all writes to any snapshot COW"},{"line_number":402,"context_line":"targets need to be local because they would otherwise incur additional"},{"line_number":403,"context_line":"latencies during copy-on-write IO. Therefore, when transferring a volume to"},{"line_number":404,"context_line":"another host all COW targets need to be cloned to the destination host in the"},{"line_number":405,"context_line":"same way the volume itself is cloned. The remaining targets of a snapshot are"},{"line_number":406,"context_line":"stateless and may be recreated on the destination host."},{"line_number":407,"context_line":""},{"line_number":408,"context_line":"After the transfer of all data is done the device mapper clone targets of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"e8233e14_c4802d69","line":405,"range":{"start_line":403,"start_character":46,"end_line":405,"end_character":37},"updated":"2024-12-09 15:04:21.000000000","message":"This makes me wonder if we should keep snapshots optional for this driver since this is an overhead that needs to be considered if someone wants to create snapshots.\nWe can do it via a config option like we do in nfs with nfs_snapshot_support\u003dFalse","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":470,"context_line":""},{"line_number":471,"context_line":"Performance Impact"},{"line_number":472,"context_line":"------------------"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"A periodic task will be added in the driver, which will query the database for"},{"line_number":475,"context_line":"a list of volumes for this host. It will cycle through the list, check for"},{"line_number":476,"context_line":"volumes which are being transferred and proceed to clean up if hydration is"},{"line_number":477,"context_line":"done. A volume lock will be held for the clean up duration. The looping"},{"line_number":478,"context_line":"interval for the periodic task will be configurable, so that a tradeoff may be"},{"line_number":479,"context_line":"found between load on the database and the upper bound of the delay between the"},{"line_number":480,"context_line":"end of volume transfer and clean up."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"Other deployer impact"},{"line_number":483,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"95d8ba90_df09fce6","line":480,"range":{"start_line":473,"start_character":0,"end_line":480,"end_character":36},"updated":"2024-12-09 15:04:21.000000000","message":"we can circle back on this but I\u0027m thinking of this trigger happening either:\n1. on an operation (like attach/detach of a volume triggering checks for all other volumes)\n2. some sort of event notification that would call the cleanup methods\n\nThe solution isn\u0027t obvious to me but adding 1) a new periodic task + 2) the need access cinder DB from compute nodes is already a lot of overhead for the volume service and the deployment tool.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"fa5e90daa84e23d7d1315e8f546efdbe4e519283","unresolved":true,"context_lines":[{"line_number":470,"context_line":""},{"line_number":471,"context_line":"Performance Impact"},{"line_number":472,"context_line":"------------------"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"A periodic task will be added in the driver, which will query the database for"},{"line_number":475,"context_line":"a list of volumes for this host. It will cycle through the list, check for"},{"line_number":476,"context_line":"volumes which are being transferred and proceed to clean up if hydration is"},{"line_number":477,"context_line":"done. A volume lock will be held for the clean up duration. The looping"},{"line_number":478,"context_line":"interval for the periodic task will be configurable, so that a tradeoff may be"},{"line_number":479,"context_line":"found between load on the database and the upper bound of the delay between the"},{"line_number":480,"context_line":"end of volume transfer and clean up."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"Other deployer impact"},{"line_number":483,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5eae6803_211252b6","line":480,"range":{"start_line":473,"start_character":0,"end_line":480,"end_character":36},"in_reply_to":"11499ab3_c11ab3e9","updated":"2024-12-17 22:05:47.000000000","message":"That\u0027s correct, I\u0027m just leaning on solutions that we can control (code based) than outside of our control (deployment based). But again not a strong opinion if we have already considered the alternatives.","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":30911,"name":"Jan Horstmann","email":"horstmann@osism.tech","username":"jhorstmann"},"change_message_id":"0d0b3643fa0c94065f2da7312fd6b0e492632081","unresolved":true,"context_lines":[{"line_number":470,"context_line":""},{"line_number":471,"context_line":"Performance Impact"},{"line_number":472,"context_line":"------------------"},{"line_number":473,"context_line":""},{"line_number":474,"context_line":"A periodic task will be added in the driver, which will query the database for"},{"line_number":475,"context_line":"a list of volumes for this host. It will cycle through the list, check for"},{"line_number":476,"context_line":"volumes which are being transferred and proceed to clean up if hydration is"},{"line_number":477,"context_line":"done. A volume lock will be held for the clean up duration. The looping"},{"line_number":478,"context_line":"interval for the periodic task will be configurable, so that a tradeoff may be"},{"line_number":479,"context_line":"found between load on the database and the upper bound of the delay between the"},{"line_number":480,"context_line":"end of volume transfer and clean up."},{"line_number":481,"context_line":""},{"line_number":482,"context_line":"Other deployer impact"},{"line_number":483,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"11499ab3_c11ab3e9","line":480,"range":{"start_line":473,"start_character":0,"end_line":480,"end_character":36},"in_reply_to":"95d8ba90_df09fce6","updated":"2024-12-09 19:02:07.000000000","message":"An implication for 1. would be that an operation on the particular volume-service is required for that particular service to finish volume movements. Certain operations for those volumes will be blocked until that happens","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"},{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"8c3af6d3a04ec24d39256f382e9d6354fb8797df","unresolved":true,"context_lines":[{"line_number":516,"context_line":"    Disable passing down discards to the destination device."},{"line_number":517,"context_line":"  * ``clone_hydration_threshold``"},{"line_number":518,"context_line":"    Maximum number of regions being copied from the source to the destination"},{"line_number":519,"context_line":"    device at any one time, during background hydratio*"},{"line_number":520,"context_line":"  * ``clone_hydration_batch_size``"},{"line_number":521,"context_line":"    During background hydration, try to batch together contiguous regions, so"},{"line_number":522,"context_line":"    we copy data from the source to the destination device in batches of this"}],"source_content_type":"text/x-rst","patch_set":6,"id":"89d4eb6a_3b7621d4","line":519,"range":{"start_line":519,"start_character":46,"end_line":519,"end_character":55},"updated":"2024-12-09 15:04:21.000000000","message":"hydration?","commit_id":"9cedca0603aeff2da2f5a9838bb4d1d0f1c82b51"}]}