)]}'
{"specs/pike/approved/libvirt-qemu-native-luks.rst":[{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"28e046fa426115e66cd1607f1dde7c2a0ec66223","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"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"},{"line_number":8,"context_line":"Libvirt: Enable QEMU native LUKs handling"},{"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"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/libvirt-qemu-native-luks"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_2e080e90","line":8,"updated":"2017-04-04 16:35:06.000000000","message":"Nit: The \u0027s\u0027 in LUKS is also capitalized.  (Same in the commit message.)","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"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"},{"line_number":8,"context_line":"Libvirt: Enable QEMU native LUKs handling"},{"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"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/libvirt-qemu-native-luks"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_646197d3","line":8,"in_reply_to":"dfeb2761_2e080e90","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Libvirt: Enable QEMU native LUKs handling"},{"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"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/libvirt-qemu-native-luks"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"QEMU 2.6 [1]_ and Libvirt 2.2.0 [2]_ allow LUKS files and block devices to be"},{"line_number":14,"context_line":"decrypted natively by QEMU. This spec outlines the required changes to utilise"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_4b46a9c2","line":11,"range":{"start_line":11,"start_character":0,"end_line":11,"end_character":68},"updated":"2017-04-04 14:46:51.000000000","message":"This doesn\u0027t exist, have you just not created it yet?","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Libvirt: Enable QEMU native LUKs handling"},{"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"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/libvirt-qemu-native-luks"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"QEMU 2.6 [1]_ and Libvirt 2.2.0 [2]_ allow LUKS files and block devices to be"},{"line_number":14,"context_line":"decrypted natively by QEMU. This spec outlines the required changes to utilise"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_24a38fb4","line":11,"range":{"start_line":11,"start_character":0,"end_line":11,"end_character":68},"in_reply_to":"dfeb2761_4b46a9c2","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":31,"context_line":"Use Cases"},{"line_number":32,"context_line":"---------"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"A user should be able to boot from or attach an encrypted volumes of any type"},{"line_number":35,"context_line":"to an instance without the use of host command-line utilities such as"},{"line_number":36,"context_line":"`cryptsetup`."},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_eb68dd1d","line":34,"range":{"start_line":34,"start_character":58,"end_line":34,"end_character":65},"updated":"2017-04-04 14:46:51.000000000","message":"nit: volume","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":31,"context_line":"Use Cases"},{"line_number":32,"context_line":"---------"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"A user should be able to boot from or attach an encrypted volumes of any type"},{"line_number":35,"context_line":"to an instance without the use of host command-line utilities such as"},{"line_number":36,"context_line":"`cryptsetup`."},{"line_number":37,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_04a88b8a","line":34,"range":{"start_line":34,"start_character":58,"end_line":34,"end_character":65},"in_reply_to":"dfeb2761_eb68dd1d","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The native LUKS support provided by QEMU 2.6 will be enabled by the"},{"line_number":42,"context_line":"introduction of a new encryption provider constant of `qemuluks`. When used"},{"line_number":43,"context_line":"this will result in Nova providing the additional disk XML for the domain and"},{"line_number":44,"context_line":"creating the associated secrets required for Libvirt to then configure QEMU to"},{"line_number":45,"context_line":"natively decrypt the associated volume."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_ab489586","line":42,"range":{"start_line":42,"start_character":66,"end_line":42,"end_character":75},"updated":"2017-04-04 14:46:51.000000000","message":"I think you need to give more detail about when this is used. From what I know, the encryption provider is based on the volume type in cinder, and the volume type API in cinder takes the full class path of the encryption provider in nova (terrible terrible stuff, I know). It\u0027s also not documented at all:\n\nhttps://developer.openstack.org/api-ref/block-storage/v2/index.html?expanded\u003dcreate-volume-type-detail#create-volume-type\n\nBut I thought the encryption provider comes back through to nova as metadata on the connection_info and we use that to load up the provider to use:\n\nhttps://github.com/openstack/nova/blob/master/nova/volume/encryptors/__init__.py#L44\n\nSo how does one go about knowing they can use this new thing, since it\u0027s dependent on the version of qemu and libvirt that you have in the compute host where you\u0027re attaching the volume? Will we just have a LUKS provider type in cinder and if specified, we use a priority order list such that native luks encryption is preferred if available, otherwise we use the old way?","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":9555,"name":"Matthew Booth","email":"mbooth@redhat.com","username":"MatthewBooth"},"change_message_id":"84a1eb4f428abd4f0ff94c4091930f698354049a","unresolved":false,"context_lines":[{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The native LUKS support provided by QEMU 2.6 will be enabled by the"},{"line_number":42,"context_line":"introduction of a new encryption provider constant of `qemuluks`. When used"},{"line_number":43,"context_line":"this will result in Nova providing the additional disk XML for the domain and"},{"line_number":44,"context_line":"creating the associated secrets required for Libvirt to then configure QEMU to"},{"line_number":45,"context_line":"natively decrypt the associated volume."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_9a787cc4","line":42,"updated":"2017-04-04 15:12:58.000000000","message":"This doesn\u0027t seem right to me, because how the qemu process decrypts a volume is an implementation detail of the compute host. Cinder really doesn\u0027t need to know anything about this at all. The provider constant should remain \u0027luks\u0027, and the compute host should decide how to decrypt it.\n\nContrast this with \u0027plain\u0027, which has a different on-disk format.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d268819f05e4c912952b915ef5bf29c5246595a3","unresolved":false,"context_lines":[{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The native LUKS support provided by QEMU 2.6 will be enabled by the"},{"line_number":42,"context_line":"introduction of a new encryption provider constant of `qemuluks`. When used"},{"line_number":43,"context_line":"this will result in Nova providing the additional disk XML for the domain and"},{"line_number":44,"context_line":"creating the associated secrets required for Libvirt to then configure QEMU to"},{"line_number":45,"context_line":"natively decrypt the associated volume."}],"source_content_type":"text/x-rst","patch_set":3,"id":"bff0334d_5c6e07c9","line":42,"in_reply_to":"dfeb2761_4499f376","updated":"2017-04-12 15:20:09.000000000","message":"@mdbooth: the tight coupling with cinder is probably a legacy artifact of when nova-volume was split out.\n\nI think we should propose a microversion to cinder v3 API such that rather than take a full classpath for the encryption provider, it\u0027s just an enum. How that gets mapped on the nova side is up to nova.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"The native LUKS support provided by QEMU 2.6 will be enabled by the"},{"line_number":42,"context_line":"introduction of a new encryption provider constant of `qemuluks`. When used"},{"line_number":43,"context_line":"this will result in Nova providing the additional disk XML for the domain and"},{"line_number":44,"context_line":"creating the associated secrets required for Libvirt to then configure QEMU to"},{"line_number":45,"context_line":"natively decrypt the associated volume."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_4499f376","line":42,"in_reply_to":"dfeb2761_9a787cc4","updated":"2017-04-04 17:25:32.000000000","message":"Agreed, I\u0027ve removed the use of a `qemuluks` constant in the latest draft, thanks!","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* Continue to use the current `cryptsetup` frontend encryptors and only support"},{"line_number":51,"context_line":"  volume types that provide `device_path` in their connection_info."},{"line_number":52,"context_line":"* An alternative approach to allow for the use of encrypted RBD volumes is to"},{"line_number":53,"context_line":"  map these volumes to the compute host using the `rbd` kernel module via the"},{"line_number":54,"context_line":"  `map` command. This would provide the required `device_path` that then"},{"line_number":55,"context_line":"  allows the existing encryptors to be used."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Data model impact"},{"line_number":58,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_e67c9484","line":55,"range":{"start_line":52,"start_character":2,"end_line":55,"end_character":44},"updated":"2017-04-04 14:46:51.000000000","message":"danpb shot down the suggestion of using the rbd kernel module for encryption years ago:\n\nhttps://review.openstack.org/#/c/239798/","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"d268819f05e4c912952b915ef5bf29c5246595a3","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* Continue to use the current `cryptsetup` frontend encryptors and only support"},{"line_number":51,"context_line":"  volume types that provide `device_path` in their connection_info."},{"line_number":52,"context_line":"* An alternative approach to allow for the use of encrypted RBD volumes is to"},{"line_number":53,"context_line":"  map these volumes to the compute host using the `rbd` kernel module via the"},{"line_number":54,"context_line":"  `map` command. This would provide the required `device_path` that then"},{"line_number":55,"context_line":"  allows the existing encryptors to be used."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Data model impact"},{"line_number":58,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bff0334d_dc61f7d4","line":55,"range":{"start_line":52,"start_character":2,"end_line":55,"end_character":44},"in_reply_to":"dfeb2761_847c9b1f","updated":"2017-04-12 15:20:09.000000000","message":"I\u0027m good with listing the reference as justification for not doing the alternative.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* Continue to use the current `cryptsetup` frontend encryptors and only support"},{"line_number":51,"context_line":"  volume types that provide `device_path` in their connection_info."},{"line_number":52,"context_line":"* An alternative approach to allow for the use of encrypted RBD volumes is to"},{"line_number":53,"context_line":"  map these volumes to the compute host using the `rbd` kernel module via the"},{"line_number":54,"context_line":"  `map` command. This would provide the required `device_path` that then"},{"line_number":55,"context_line":"  allows the existing encryptors to be used."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"Data model impact"},{"line_number":58,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_847c9b1f","line":55,"range":{"start_line":52,"start_character":2,"end_line":55,"end_character":44},"in_reply_to":"dfeb2761_e67c9484","updated":"2017-04-04 17:25:32.000000000","message":"I\u0027ve removed this from the latest draft but it might be worth listing in passing as something that we have considered before but view as the wrong approach.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":92,"context_line":"Developer impact"},{"line_number":93,"context_line":"----------------"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"None"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Implementation"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_869948c5","line":95,"updated":"2017-04-04 14:46:51.000000000","message":"What does this mean for os-brick? I thought at one point there was an effort to move the encryption code from nova into os-brick so cinder could also be using it?","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":92,"context_line":"Developer impact"},{"line_number":93,"context_line":"----------------"},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"None"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"Implementation"},{"line_number":98,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_a4d2fffe","line":95,"in_reply_to":"dfeb2761_869948c5","updated":"2017-04-04 17:25:32.000000000","message":"I\u0027ve added a note in the latest draft around this, IMHO it\u0027s not an issue as they would need to use and abuse Libvirt in order to meet their requirements.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Work Items"},{"line_number":107,"context_line":"----------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Remove the encryptor classes from Nova and only use the classes provided by"},{"line_number":110,"context_line":"  os-brick. While this is not strictly required for the implementation of this"},{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_068c1834","line":109,"updated":"2017-04-04 14:46:51.000000000","message":"So that\u0027s this: https://review.openstack.org/#/c/391597/\n\nI think ^ should be handled under a cleanup/refactor blueprint, or this blueprint, rather than a bug, because it\u0027s not a bug.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":106,"context_line":"Work Items"},{"line_number":107,"context_line":"----------"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Remove the encryptor classes from Nova and only use the classes provided by"},{"line_number":110,"context_line":"  os-brick. While this is not strictly required for the implementation of this"},{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_84cffb54","line":109,"in_reply_to":"dfeb2761_068c1834","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":109,"context_line":"* Remove the encryptor classes from Nova and only use the classes provided by"},{"line_number":110,"context_line":"  os-brick. While this is not strictly required for the implementation of this"},{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_e6cdb431","line":112,"range":{"start_line":112,"start_character":15,"end_line":112,"end_character":23},"updated":"2017-04-04 14:46:51.000000000","message":"Honestly I think we should not even distinguish between native qemu encryption for luks and the old legacy way for luks encryption, since it leaks to the volume types API. I\u0027d think we just have luks and depending on what\u0027s available on the compute host, you use the native encryption first if it\u0027s available, else fallback to the old stuff.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":109,"context_line":"* Remove the encryptor classes from Nova and only use the classes provided by"},{"line_number":110,"context_line":"  os-brick. While this is not strictly required for the implementation of this"},{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_040d2ba0","line":112,"range":{"start_line":112,"start_character":15,"end_line":112,"end_character":23},"in_reply_to":"dfeb2761_e6cdb431","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_66cac44e","line":114,"range":{"start_line":114,"start_character":2,"end_line":114,"end_character":22},"updated":"2017-04-04 14:46:51.000000000","message":"Is it the libvirt virt driver that does anything with this though? I\u0027m a bit confused given the existing luks encryptor is defined outside of nova/virt/libvirt/.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":111,"context_line":"  spec does provide an opportunity to decrease code duplication in this area."},{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_a4fb1f77","line":114,"range":{"start_line":114,"start_character":2,"end_line":114,"end_character":22},"in_reply_to":"dfeb2761_66cac44e","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_66cf6456","line":116,"range":{"start_line":115,"start_character":2,"end_line":116,"end_character":51},"updated":"2017-04-04 14:46:51.000000000","message":"How would a user / admin know this? As noted above, it\u0027s defined in the volume type in cinder but used on a compute host in nova, and you could have mixed level computes so the volume type might work on one but not another if the versions of libvirt and qemu are different on the compute hosts. That\u0027s why I think you need a priority order.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":112,"context_line":"* Introduce a `qemuluks` constant to os-brick that uses the `NoOpEncryptor`"},{"line_number":113,"context_line":"  frontend encryptor class, essentially passing responsibility back to the"},{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_c402a36f","line":116,"range":{"start_line":115,"start_character":2,"end_line":116,"end_character":51},"in_reply_to":"dfeb2761_66cf6456","updated":"2017-04-04 17:25:32.000000000","message":"Done","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"},{"line_number":120,"context_line":"  Nova to pass a given volumes encrypted properties to"},{"line_number":121,"context_line":"  `LibvirtConfigGuestDisk`."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_46f10095","line":118,"range":{"start_line":117,"start_character":65,"end_line":118,"end_character":28},"updated":"2017-04-04 14:46:51.000000000","message":"Until native support lands in QEMU and Libvirt for RBD volume encryption, right? Because native LUKS is already in qemu and libvirt per this spec.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"92a97632dc8d46ead100ee85dedea00dc77fac93","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"},{"line_number":120,"context_line":"  Nova to pass a given volumes encrypted properties to"},{"line_number":121,"context_line":"  `LibvirtConfigGuestDisk`."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_1680a945","line":118,"range":{"start_line":117,"start_character":65,"end_line":118,"end_character":28},"in_reply_to":"dfeb2761_04f76b61","updated":"2017-04-05 09:37:07.000000000","message":"From my understanding (and talking to Eric Blake briefly): What is \navailable in QEMU 2.9 is LUKS layering over network (or plain) block\ndevices, i.e. you can layer LUKS over any other block driver (NBD, RBD,\nplain block devices, etc).\n\nBut what is *not* available yet in QEMU 2.9 is: LUKS-in-QCOW2.  That \nwill be for QEMU 2.10\n\nAs there are some security drawbacks to the two possible layerings -- \nLUKS under or over QCOW2:\n  \n  - In LUKS under QCOW2 (i.e. QCOW2 reads LUKS, which reads a raw file), \n    the QCOW2 metadata is encrypted, so you can\u0027t even see the volume\n    size without a passphrase.\n\n  - In QCOW2 over LUKS (i.e. LUKS reads QCOW2, which reads a raw file), \n    actions like copying a common base image (or internal snapshots,\n    which Nova doesn\u0027t use, upstream QEMU doesn\u0027t really recommend it\n    anyway) means that copies of the same guest-visible offset can\n    appear in more than one host address, and that weakens the power of\n    encryption.\n\nSo Dan Berrangé is doing work to integrate LUKS directly in QCOW2 to\nmitgate the above.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"28e046fa426115e66cd1607f1dde7c2a0ec66223","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"},{"line_number":120,"context_line":"  Nova to pass a given volumes encrypted properties to"},{"line_number":121,"context_line":"  `LibvirtConfigGuestDisk`."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_b386cb12","line":118,"range":{"start_line":117,"start_character":65,"end_line":118,"end_character":28},"in_reply_to":"dfeb2761_46f10095","updated":"2017-04-04 16:35:06.000000000","message":"From looking at upstream QEMU list / Git, LUKS support for network block drivers (NBD, RBD, Gluster, iSCSI, etc) is already available.\n\nFor libvirt: LUKS support is wired up only for raw files / local block devices currently[*]. Support for all network block drivers -- RBD, NBD, iSCSI, Gluster, NFS, and also for QCOW2 itself is still to be worked on.\n\nAlso confirmed this with Dan Berrangé.\n\n[*] https://www.redhat.com/archives/libvir-list/2016-June/msg00357.html","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":114,"context_line":"  Libvirt virt driver."},{"line_number":115,"context_line":"* Allow the use of the `qemuluks` constant only if the required QEMU and"},{"line_number":116,"context_line":"  Libvirt versions are present on the compute host."},{"line_number":117,"context_line":"* Block the use of the `qemuluks` constant for RBD volumes until native support"},{"line_number":118,"context_line":"  lands in QEMU and Libvirt."},{"line_number":119,"context_line":"* Extend the `nova/virt/libvirt/volumes/` block volume drivers within"},{"line_number":120,"context_line":"  Nova to pass a given volumes encrypted properties to"},{"line_number":121,"context_line":"  `LibvirtConfigGuestDisk`."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_04f76b61","line":118,"range":{"start_line":117,"start_character":65,"end_line":118,"end_character":28},"in_reply_to":"dfeb2761_b386cb12","updated":"2017-04-04 17:25:32.000000000","message":"Can you confirm which QEMU version the network block driver support landed in Kashyap?\n\nNote that we don\u0027t connect iSCSI or NFS volumes to a domain directly through libvirt at present. It is however configurable with glusterfs volumes.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"2db879147f9daa50472470974509b94dbcd955da","unresolved":false,"context_lines":[{"line_number":138,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"* Unit tests."},{"line_number":141,"context_line":"* The existing `tempest.scenario.test_encrypted_cinder_volumes` scenario should"},{"line_number":142,"context_line":"  be extended to include the use of the new `qemuluks` constant when Nova is"},{"line_number":143,"context_line":"  also configured to use the Libvirt virt driver."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Documentation Impact"},{"line_number":146,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_c60bd07a","line":143,"range":{"start_line":141,"start_character":2,"end_line":143,"end_character":49},"updated":"2017-04-04 14:46:51.000000000","message":"Well, it\u0027s not only that, but also that the versions are new enough for qemu and libvirt and you\u0027re not using ceph as the cinder backend...","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"cf192e5e5ad7be618c1db84b91a16eca98486b75","unresolved":false,"context_lines":[{"line_number":138,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"* Unit tests."},{"line_number":141,"context_line":"* The existing `tempest.scenario.test_encrypted_cinder_volumes` scenario should"},{"line_number":142,"context_line":"  be extended to include the use of the new `qemuluks` constant when Nova is"},{"line_number":143,"context_line":"  also configured to use the Libvirt virt driver."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Documentation Impact"},{"line_number":146,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfeb2761_64fbd746","line":143,"range":{"start_line":141,"start_character":2,"end_line":143,"end_character":49},"in_reply_to":"dfeb2761_c60bd07a","updated":"2017-04-04 17:25:32.000000000","message":"Yup, I\u0027ve left a TODO to add more details regarding the UCA packages and (I assume) CI jobs you were talking about in the channel today.","commit_id":"8d3751a9b582a02577662ece51de7c74a8f2caac"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"8f841d8a3dcf92bef5bf91d33c2bde99b4538df2","unresolved":false,"context_lines":[{"line_number":14,"context_line":"devices to be decrypted natively by QEMU. This spec outlines the required"},{"line_number":15,"context_line":"changes to utilise this new functionality within the Libvirt Nova virt driver"},{"line_number":16,"context_line":"and the possible benefits of doing so."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"bff0334d_2867e1bf","line":17,"updated":"2017-04-10 10:35:27.000000000","message":"A couple of points:\n\n(1) I think it would be helpful to add some verbiage about network block drivers (RBD, NFS, iSCSI, etc). \n\n(2) As noted in my previous comment, currently (as of QEMU 2.9) is possible only via QEMU. An example of QEMU usage from the KVMForum 2016 presentation[*] from Daniel Berrangé, from slide-18:\n\n----\n$QEMU -object secret,id\u003dsec0,file\u003dkey.bin \\\n -object secret,id\u003dsec1,file\u003dpasswd.bin \\\n -drive if\u003dnone,driver\u003dluks,key-secret\u003dsec0,id\u003ddrive0,\\\n file.driver\u003drbd,file.password-secret\u003dsec1,\\\n file.filename\u003drbd:somehost:9000/somevol \\\n -device virtio-blk,drive\u003ddrive0\n----\n\nThis is not yet wired into libvirt\u0027s QEMU command-line generator (as of libvirt 3.2.0)\n\nSo perhaps it is worthwhile to add a TODO item until support for network block drivers lands in upstream libvirt.\n\n\n[*] https://people.redhat.com/berrange/kvm-forum-2016/kvm-forum-2016-security.pdf","commit_id":"51f0ee726d42bb290a3a2761ddca92c46cdebfb2"},{"author":{"_account_id":10135,"name":"Lee Yarwood","display_name":"Lee Yarwood","email":"lyarwood@redhat.com","username":"lyarwood"},"change_message_id":"fbe133e97aba6f32a1fcbf9b0b32ad86826f364d","unresolved":false,"context_lines":[{"line_number":14,"context_line":"devices to be decrypted natively by QEMU. This spec outlines the required"},{"line_number":15,"context_line":"changes to utilise this new functionality within the Libvirt Nova virt driver"},{"line_number":16,"context_line":"and the possible benefits of doing so."},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"Problem description"},{"line_number":19,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"bff0334d_5d1c1a77","line":17,"in_reply_to":"bff0334d_2867e1bf","updated":"2017-04-10 15:01:44.000000000","message":"Ah! I misunderstood your last comment and assumed it was wired up in Libvirt, I\u0027ll revert to the previous draft in that case and just target this at files and host block devices.","commit_id":"51f0ee726d42bb290a3a2761ddca92c46cdebfb2"},{"author":{"_account_id":6962,"name":"Kashyap Chamarthy","email":"kchamart@redhat.com","username":"kashyapc"},"change_message_id":"8f841d8a3dcf92bef5bf91d33c2bde99b4538df2","unresolved":false,"context_lines":[{"line_number":152,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":".. [1] http://wiki.qemu-project.org/ChangeLog/2.6#Block_devices_2"},{"line_number":155,"context_line":".. [2] TODO - find a reference to QEMU 2.9 allowing LUKS on RBD "},{"line_number":156,"context_line":".. [3] https://libvirt.org/news-2016.html"},{"line_number":157,"context_line":".. [4] https://libvirt.org/formatstorageencryption.html"},{"line_number":158,"context_line":".. [5] https://launchpad.net/ubuntu/+source/qemu"}],"source_content_type":"text/x-rst","patch_set":5,"id":"bff0334d_68172947","line":155,"updated":"2017-04-10 10:35:27.000000000","message":"You can add a reference to the KVMForum presentation from DanPB above.","commit_id":"51f0ee726d42bb290a3a2761ddca92c46cdebfb2"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e8a5c1ce09c7e043a2b396b023e22e818e06f022","unresolved":false,"context_lines":[{"line_number":46,"context_line":"secret required for Libvirt to then configure QEMU to natively decrypt the"},{"line_number":47,"context_line":"volume."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"If the required versions are not present Nova will fallback to the current"},{"line_number":50,"context_line":"`LuksEncryptor` encryptor using `cryptsetup` to decrypt the volume."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_3cdea33d","line":49,"updated":"2017-04-12 15:38:22.000000000","message":"One thing I think that needs to be mentioned here or somewhere in the spec, is what happens if I have an old encrypted volume that used cryptsetup when the volume was attached, and now when we go to detach it, we do this check to see oh we can use native encryption with qemu, cool, but do we know that we have to detach with cryptsetup because that\u0027s what it was encrypted with? So in a nutshell, describe the upgrade implication for this.","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e8a5c1ce09c7e043a2b396b023e22e818e06f022","unresolved":false,"context_lines":[{"line_number":67,"context_line":"Security impact"},{"line_number":68,"context_line":"---------------"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"None"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"Notifications impact"},{"line_number":73,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_dcee97eb","line":70,"updated":"2017-04-12 15:38:22.000000000","message":"Better?","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e8a5c1ce09c7e043a2b396b023e22e818e06f022","unresolved":false,"context_lines":[{"line_number":77,"context_line":"Other end user impact"},{"line_number":78,"context_line":"---------------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"This change should be transparent to existing users of `LuksEncryptor`. Users"},{"line_number":81,"context_line":"should continue to use this encryption provider as before, allowing Nova to"},{"line_number":82,"context_line":"decide when to use the native LUKS support offered by QEMU 2.6 or the"},{"line_number":83,"context_line":"original `cryptsetup` encryptors."},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Performance Impact"},{"line_number":86,"context_line":"------------------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_bcc2b351","line":83,"range":{"start_line":80,"start_character":72,"end_line":83,"end_character":33},"updated":"2017-04-12 15:38:22.000000000","message":"nit: to be clear, the encryption provider is defined on the volume type, which is setup by the admin of the cloud, so it\u0027s not really up to the user here, unless you mean which volume type the user uses to create their volume. Anyway, it\u0027s semantics, but I wanted to point it out.","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e8a5c1ce09c7e043a2b396b023e22e818e06f022","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"The Libvirt virt driver will have a unique encryptor implementation outside of"},{"line_number":99,"context_line":"those Nova currently provides under `nova/volume/encryptors` or that were"},{"line_number":100,"context_line":"recently copied to os-brick under `os_brick/encryptors`."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_5c0cc792","line":98,"updated":"2017-04-12 15:38:22.000000000","message":"I\u0027m not entirely sure how you\u0027re going to have nova/volumes/ecnryptor call into the virt driver code to see if they have an override, things could get a bit weird here. It almost seems like we should have stevedore extensions for these things and they are weighted.","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5621b7a7aeb2698cf34935179ee794e09c944ad9","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"The Libvirt virt driver will have a unique encryptor implementation outside of"},{"line_number":99,"context_line":"those Nova currently provides under `nova/volume/encryptors` or that were"},{"line_number":100,"context_line":"recently copied to os-brick under `os_brick/encryptors`."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_df3329f5","line":98,"in_reply_to":"bff0334d_5c0cc792","updated":"2017-04-12 15:43:15.000000000","message":"My thoughts on implementation for this in IRC:\n\n(10:40:40 AM) mriedem: lyarwood: i\u0027m also not sure how you\u0027re going to implement a libvirt-specific encryption provider that doesn\u0027t live in nova/volume/encryptors, but i think we could make that clean with a stevedore extension\n(10:41:41 AM) mriedem: like we could have 3 encryptors registered, and each encryptor defines a type (so we\u0027d have 1 cryptsetup and 2 luks registered), a weight, and an is_supported() or is_available() method\n(10:42:26 AM) mriedem: so for this case, we filter down to the 2 luks encryptors, then filter based on is_available() - the cryptsetup one we have always returns True, but the qemu one has to check versions. then depending on the final list, we sort them based on weight\n(10:42:41 AM) mriedem: so the qemu one is always weighed higher than the cryptsetup luks one, if we have to pick","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"21fd9c62aa726cbc838b069ba29cabcb06bb8f0b","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Developer impact"},{"line_number":96,"context_line":"----------------"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"The Libvirt virt driver will have a unique encryptor implementation outside of"},{"line_number":99,"context_line":"those Nova currently provides under `nova/volume/encryptors` or that were"},{"line_number":100,"context_line":"recently copied to os-brick under `os_brick/encryptors`."},{"line_number":101,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_df7e89ad","line":98,"in_reply_to":"bff0334d_df3329f5","updated":"2017-04-12 16:07:07.000000000","message":"nvm, this was way over complicating things, the libvirt driver has a _get_volume_encryptor method we can just hijack to do the new thing else fallback to the old thing.","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e8a5c1ce09c7e043a2b396b023e22e818e06f022","unresolved":false,"context_lines":[{"line_number":148,"context_line":"* Unit tests."},{"line_number":149,"context_line":"* Existing tempest tests should trigger the use of this new functionality"},{"line_number":150,"context_line":"  assuming the required versions of Libvirt and QEMU are present."},{"line_number":151,"context_line":"* Continue testing the fallback path using jobs that do not use UCA and thus do"},{"line_number":152,"context_line":"  not provide the required QEMU and Libvirt versions."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bff0334d_dce217a0","line":151,"updated":"2017-04-12 15:38:22.000000000","message":"I don\u0027t think we have anything like this now on master, but OK.\n\nIf we had an encrypted volume attached during the ocata side of grenade and then decrypted that on the pike side, it would test this, but that means adding this scenario to grenade which is probably more work than it\u0027s worth.","commit_id":"cfaba72c3de1ca00d7d275ba7e50145adec0dca5"}]}