)]}'
{"specs/queens/migrate-fixed-key-to-barbican.rst":[{"author":{"_account_id":170,"name":"Mike Perez","email":"thingee@gmail.com","username":"thingee"},"change_message_id":"1d497545a459d311129220908e95207cea9d86c4","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"The legacy ConfKeyManager is insecure, and the prefered encryption key manager"},{"line_number":23,"context_line":"is Barbican. Using Barbican in new deployments is easy, but switching"},{"line_number":24,"context_line":"deployments from the ConfKeyManager to Barbican is difficult when there are"},{"line_number":25,"context_line":"existing volumes encrypted using the ConfKeyManager."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_54284795","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":52},"updated":"2017-10-17 17:03:47.000000000","message":"Are there existing ML threads on this conversation? I don\u0027t know much on the subject myself, but I see ConfKeyManager is using Castellan. Is that not secure anymore?","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"f1755c48c82e12e4f52d0120f6ba90dac5842742","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"The legacy ConfKeyManager is insecure, and the prefered encryption key manager"},{"line_number":23,"context_line":"is Barbican. Using Barbican in new deployments is easy, but switching"},{"line_number":24,"context_line":"deployments from the ConfKeyManager to Barbican is difficult when there are"},{"line_number":25,"context_line":"existing volumes encrypted using the ConfKeyManager."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Use Cases"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_2abb20c5","line":25,"range":{"start_line":22,"start_character":0,"end_line":25,"end_character":52},"in_reply_to":"5f4e5783_54284795","updated":"2017-10-17 17:54:11.000000000","message":"The ConfKeyManager and Barbican both use Castellan, but Castellan simply defines the API. From a security perspective, the comparison is between ConfKeyManager and Barbican.\n\nSome users were deploying encrypted volumes using the ConfKeyManager\u0027s fixed_key prior to when Barbican (and Castellan) were available. Now that Barbican is the \"modern\" choice, users want to switch to Barbican as long as it doesn\u0027t break things. This spec is all about trying to help them get there.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":1207,"name":"Duncan Thomas","email":"duncan.thomas@gmail.com","username":"duncan-thomas"},"change_message_id":"f09b8ae83d762a66a34d29483b139620338ad562","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Security impact"},{"line_number":120,"context_line":"---------------"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"This change should be considered a security enhancement in that it facilitates"},{"line_number":123,"context_line":"transitioning existing ConfKeyManager deployments to Barbican."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Notifications impact"},{"line_number":126,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_15ec178d","line":123,"range":{"start_line":122,"start_character":0,"end_line":123,"end_character":62},"updated":"2017-10-17 11:10:40.000000000","message":"I\u0027m slightly uncomfortable whenever this statement is made; it changes the threat model for \"host compromise is required to get at key material\" to \"A tenant token is required to get at key material\", which might not be considered an enhancement. If I can compromise the host, then I\u0027ve got the token and I can just ask barbican for the key....\n\nHas there been any work to reduce this area for attack? If not, I think calling this an enhancement is misleading. We can\u0027t re-key or anything (yet), so all the old volumes will be left with the same reused key too. Future volumes will have a unique key, which might improve security, though those keys are more weakly protected against certain attacks.\n\nTL;DR This is a non-nuanced statement about nuanced condition, which I always object to in security situations.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"f1755c48c82e12e4f52d0120f6ba90dac5842742","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Security impact"},{"line_number":120,"context_line":"---------------"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"This change should be considered a security enhancement in that it facilitates"},{"line_number":123,"context_line":"transitioning existing ConfKeyManager deployments to Barbican."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Notifications impact"},{"line_number":126,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_2a79e092","line":123,"range":{"start_line":122,"start_character":0,"end_line":123,"end_character":62},"in_reply_to":"5f4e5783_15ec178d","updated":"2017-10-17 17:54:11.000000000","message":"It\u0027s my understanding (and I could be entirely mistaken) a big issue with the ConfKeyManager is its use of the fixed_key, sitting in plain sight in cinder.conf. If the fixed_key is ever exposed then the secret used to encrypt _every_ volume is blown. That\u0027s the main thing this blueprint is trying to repair. Once the secret is moved to Barbican then the fixed_key can be removed from cinder.conf.\n\nI am not a security expert, and don\u0027t know what level of security Barbican provides. To that end, I don\u0027t know what sort of work may be underway to reduce attack surfaces.\n\nI chose \"should\" and \"be considered\" as an attempt at nuance. I started with the notion (possibly naive) that, from a security perspective, getting rid of the ConfKeyManager is a good thing. That said, I have absolutely no qualms about changing the wording in this section if it will avoid potential misunderstanding.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":1207,"name":"Duncan Thomas","email":"duncan.thomas@gmail.com","username":"duncan-thomas"},"change_message_id":"01274ac42b83cbb4bfb3cba4c017ea82d7a2c0fb","unresolved":false,"context_lines":[{"line_number":119,"context_line":"Security impact"},{"line_number":120,"context_line":"---------------"},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"This change should be considered a security enhancement in that it facilitates"},{"line_number":123,"context_line":"transitioning existing ConfKeyManager deployments to Barbican."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":"Notifications impact"},{"line_number":126,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_4d53163a","line":123,"range":{"start_line":122,"start_character":0,"end_line":123,"end_character":62},"in_reply_to":"5f4e5783_2a79e092","updated":"2017-10-17 18:31:54.000000000","message":"There\u0027s been an argument that any key in Barbican can be recovered over the network if you\u0027ve got a user\u0027s token, which is often easier to get than compromising a hardened host. If I can compromise a host enough to get at cinder.conf then I can almost certainly grab a token and get the key quite legitimately from Barbican. Once Barbican is in use, volumes would all have a different key though... it\u0027s going to depend on exactly what you\u0027re trying to protect from as to which is the best choice - quite often it will be BArbican, even with the trade-offs. I\u0027d love somebody to pay me to fix that aspect of Barbican TBH - it could be done with service tokens and some minor enhancement to the Barbican ACL rules.\n\nI\u0027ve a mild dislike for statements like \u0027security enhancement\u0027 without qualifications, that\u0027s all really. I suspect this discussion is more than enough record of the situation, and I certainly would rather you didn\u0027t let this distract you from getting the work done - it has definite value.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":170,"name":"Mike Perez","email":"thingee@gmail.com","username":"thingee"},"change_message_id":"1d497545a459d311129220908e95207cea9d86c4","unresolved":false,"context_lines":[{"line_number":183,"context_line":"- Add and update the unit tests."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Documentation Impact"},{"line_number":187,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"The documentation will be updated to state that volumes encrypted using the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_e01f6e69","line":186,"range":{"start_line":186,"start_character":0,"end_line":186,"end_character":20},"updated":"2017-10-17 17:03:47.000000000","message":"I would like the documentation to also reflect lines 75-79 since that is something they\u0027re responsible for.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"2532f41ac0854156fe70ec095e212e2cd8abdeda","unresolved":false,"context_lines":[{"line_number":183,"context_line":"- Add and update the unit tests."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Documentation Impact"},{"line_number":187,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"The documentation will be updated to state that volumes encrypted using the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f4b6375_7cb1afe1","line":186,"range":{"start_line":186,"start_character":0,"end_line":186,"end_character":20},"in_reply_to":"3f4b6375_b9629915","updated":"2017-10-18 16:39:47.000000000","message":"Done","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":170,"name":"Mike Perez","email":"thingee@gmail.com","username":"thingee"},"change_message_id":"18186db7c3fe9a7ca109d719c510472cbae83793","unresolved":false,"context_lines":[{"line_number":183,"context_line":"- Add and update the unit tests."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Documentation Impact"},{"line_number":187,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"The documentation will be updated to state that volumes encrypted using the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f4b6375_b9629915","line":186,"range":{"start_line":186,"start_character":0,"end_line":186,"end_character":20},"in_reply_to":"5f4e5783_2ad56044","updated":"2017-10-18 16:19:22.000000000","message":"I would appreciate this to be amended in a follow up commit, just so we all remember.","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"f1755c48c82e12e4f52d0120f6ba90dac5842742","unresolved":false,"context_lines":[{"line_number":183,"context_line":"- Add and update the unit tests."},{"line_number":184,"context_line":""},{"line_number":185,"context_line":""},{"line_number":186,"context_line":"Documentation Impact"},{"line_number":187,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":188,"context_line":""},{"line_number":189,"context_line":"The documentation will be updated to state that volumes encrypted using the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f4e5783_2ad56044","line":186,"range":{"start_line":186,"start_character":0,"end_line":186,"end_character":20},"in_reply_to":"5f4e5783_e01f6e69","updated":"2017-10-17 17:54:11.000000000","message":"Yes, that\u0027s an excellent suggestion! Can that be handled at the time the doc changes are posted, or do you prefer I add something here in the spec that states the doc changes will include this?","commit_id":"1137c5fdc13ac3a9d23378f171a0a6dda81a0046"},{"author":{"_account_id":8623,"name":"Kaitlin Farr","email":"kaitlin.farr@jhuapl.edu","username":"kaitlin.farr"},"change_message_id":"09b729aa62d1ed9b4133ccf64149fb56b83cf0eb","unresolved":false,"context_lines":[{"line_number":47,"context_line":"in the database that match the ConfKeyManager\u0027s all-zeros ID. This thread will"},{"line_number":48,"context_line":"be refered to as the key migration thread."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* The key migration thread will search the volume table for encryption_key_id"},{"line_number":51,"context_line":"  entries matching the all-zeros ConfKeyManager key ID. For each matching"},{"line_number":52,"context_line":"  entry in the volume table, a new Barbican key ID will be created with the"},{"line_number":53,"context_line":"  exact same secret derived from the fixed_key config value used by the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_0bd94f82","line":50,"updated":"2017-10-18 20:23:01.000000000","message":"I like the part about it being a separate thread that searches for the encryption_key_id.\n\nWhen you store a key in Barbican, the key will be \"owned\" by the user that stored it.  The cleanest way this would work is if the Cinder thread could store key as the user that owned the volume, but I am not aware of a way to store on behalf of another user.  The best way I was planning to work around this was to store the key as an admin user, and create an access control list entry for the user that owns the volume.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"b5f4e959ee66c71072f99f3c9d9690eb0f49f7a6","unresolved":false,"context_lines":[{"line_number":47,"context_line":"in the database that match the ConfKeyManager\u0027s all-zeros ID. This thread will"},{"line_number":48,"context_line":"be refered to as the key migration thread."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"* The key migration thread will search the volume table for encryption_key_id"},{"line_number":51,"context_line":"  entries matching the all-zeros ConfKeyManager key ID. For each matching"},{"line_number":52,"context_line":"  entry in the volume table, a new Barbican key ID will be created with the"},{"line_number":53,"context_line":"  exact same secret derived from the fixed_key config value used by the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_ac1d8074","line":50,"in_reply_to":"3f4b6375_0bd94f82","updated":"2017-10-20 13:59:03.000000000","message":"You raise an interesting issue I hadn\u0027t considered, and I see how an ACL might be required in order for the volume\u0027s owner to essentially assume control (ability to read and delete) the migrated key.\n\nHowever, I poked at some code a little, and encountered another issue. That is, the cinder user doesn\u0027t appear to have the privileges necessary to create a barbican key order. I will need assistance in understanding what it would take to allow the cinder user to perform the migration actions.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":8623,"name":"Kaitlin Farr","email":"kaitlin.farr@jhuapl.edu","username":"kaitlin.farr"},"change_message_id":"09b729aa62d1ed9b4133ccf64149fb56b83cf0eb","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  exact same secret derived from the fixed_key config value used by the"},{"line_number":54,"context_line":"  ConfKeyManager. The volume table is updated with the new Baribican key ID."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* The thread will only migrate keys associated with volumes belonging to that"},{"line_number":57,"context_line":"  host. This will avoid contention when there are multiple cinder-volume hosts."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* The key migration thread will also look for ConfKeyManager keys stored in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_0bccaf87","line":56,"updated":"2017-10-18 20:23:01.000000000","message":"Just a question to make sure my understanding is correct about the cinder infrastructure as I am not that familiar with multi-node deployments of cinder.  If you have multiple cinder-volume hosts, I would think that each host/node would have entries in the volumes database table only for the volumes that are on that node, and your statement here seems obvious to me, as how else would the thread know about other volumes not on that node.  Is this the case?","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"b5f4e959ee66c71072f99f3c9d9690eb0f49f7a6","unresolved":false,"context_lines":[{"line_number":53,"context_line":"  exact same secret derived from the fixed_key config value used by the"},{"line_number":54,"context_line":"  ConfKeyManager. The volume table is updated with the new Baribican key ID."},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* The thread will only migrate keys associated with volumes belonging to that"},{"line_number":57,"context_line":"  host. This will avoid contention when there are multiple cinder-volume hosts."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* The key migration thread will also look for ConfKeyManager keys stored in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_673c41c8","line":56,"in_reply_to":"3f4b6375_0bccaf87","updated":"2017-10-20 13:59:03.000000000","message":"The cinder DB tables are shared, and so each c-vol instance will know about all volumes. Another factor to consider is HA, where volumes appear to \"belong\" to every c-vol instance. A global lock will be used to prevent multiple c-vol instances from updating the same volume.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":8623,"name":"Kaitlin Farr","email":"kaitlin.farr@jhuapl.edu","username":"kaitlin.farr"},"change_message_id":"09b729aa62d1ed9b4133ccf64149fb56b83cf0eb","unresolved":false,"context_lines":[{"line_number":56,"context_line":"* The thread will only migrate keys associated with volumes belonging to that"},{"line_number":57,"context_line":"  host. This will avoid contention when there are multiple cinder-volume hosts."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* The key migration thread will also look for ConfKeyManager keys stored in"},{"line_number":60,"context_line":"  metadata tables. Where appropriate, these entries will be updated with the"},{"line_number":61,"context_line":"  Barbican key ID stored in the corresponding volume table. Otherwise, a new"},{"line_number":62,"context_line":"  Barbican key ID will be created."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_2b03eb44","line":59,"updated":"2017-10-18 20:23:01.000000000","message":"Could you please clarify the cases where the encryption key id is stored in a metadata table?  I do not know of any.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"b5f4e959ee66c71072f99f3c9d9690eb0f49f7a6","unresolved":false,"context_lines":[{"line_number":56,"context_line":"* The thread will only migrate keys associated with volumes belonging to that"},{"line_number":57,"context_line":"  host. This will avoid contention when there are multiple cinder-volume hosts."},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"* The key migration thread will also look for ConfKeyManager keys stored in"},{"line_number":60,"context_line":"  metadata tables. Where appropriate, these entries will be updated with the"},{"line_number":61,"context_line":"  Barbican key ID stored in the corresponding volume table. Otherwise, a new"},{"line_number":62,"context_line":"  Barbican key ID will be created."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_0746ad50","line":59,"in_reply_to":"3f4b6375_2b03eb44","updated":"2017-10-20 13:59:03.000000000","message":"My initial review of the code led me to believe the key ID might be stored in the backup_metadata table, but I was mistaken. The key ID is definitely stored in the volumes and snapshots tables. I just discovered a bug in handling encrypted backups, and fixing the bug will likely require the key ID be added to the backups table. But it doesn\u0027t look like the key ID is actually stored in any metadata tables.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":8623,"name":"Kaitlin Farr","email":"kaitlin.farr@jhuapl.edu","username":"kaitlin.farr"},"change_message_id":"09b729aa62d1ed9b4133ccf64149fb56b83cf0eb","unresolved":false,"context_lines":[{"line_number":78,"context_line":"removes the fixed_key from the configuration, the key migration thread will"},{"line_number":79,"context_line":"not be spawned on startup."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The key migration thread will work in conjunction with an enhancement to"},{"line_number":82,"context_line":"Castellan and/or Barbican. During the migration process, cinder services may"},{"line_number":83,"context_line":"still encounter the ConfKeyManager\u0027s key ID (all zeros) in the database. This"},{"line_number":84,"context_line":"is not a valid Barbican key ID, and Barbican will throw an error if asked to"},{"line_number":85,"context_line":"provide the key associated with that ID. The enhancement will essentially"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_0b214fb5","line":82,"range":{"start_line":81,"start_character":55,"end_line":82,"end_character":9},"updated":"2017-10-18 20:23:01.000000000","message":"I\u0027m still not convinced that modifications to Castellan are necessary.  I hear your argument about how it makes it easier and transparent to the user, but by moving ConfKeyManager to castellan, you\u0027re then making it available to all projects using castellan, where it was only available to cinder and nova before. ConfKeyManager was only meant for testing in cinder and nova, but it seems like people still used it in their deployments and now we need to handle the case where people want to upgrade.  If it is available for other projects to use, they may still use it despite warnings, and then we\u0027d have to deal with a migration issue in other projects, too.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"b5f4e959ee66c71072f99f3c9d9690eb0f49f7a6","unresolved":false,"context_lines":[{"line_number":78,"context_line":"removes the fixed_key from the configuration, the key migration thread will"},{"line_number":79,"context_line":"not be spawned on startup."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"The key migration thread will work in conjunction with an enhancement to"},{"line_number":82,"context_line":"Castellan and/or Barbican. During the migration process, cinder services may"},{"line_number":83,"context_line":"still encounter the ConfKeyManager\u0027s key ID (all zeros) in the database. This"},{"line_number":84,"context_line":"is not a valid Barbican key ID, and Barbican will throw an error if asked to"},{"line_number":85,"context_line":"provide the key associated with that ID. The enhancement will essentially"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_27c0897b","line":82,"range":{"start_line":81,"start_character":55,"end_line":82,"end_character":9},"in_reply_to":"3f4b6375_0b214fb5","updated":"2017-10-20 13:59:03.000000000","message":"Understood. Perhaps I was mistaken, but we had an irc exchange that led me to believe you had a WIP in mind that would allow the all-zeros key ID to properly function during the migration period.\n\nI also have a WIP I can share that offers this capability without actually moving the entire ConfKeyManager into Castellan. The code changes would need to go there (in Castellan), but would not actually add the entire ConfKeyManager.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":8623,"name":"Kaitlin Farr","email":"kaitlin.farr@jhuapl.edu","username":"kaitlin.farr"},"change_message_id":"09b729aa62d1ed9b4133ccf64149fb56b83cf0eb","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Instead of using a separate migration thread, each piece of code that fetches"},{"line_number":95,"context_line":"and uses the encryption key ID could be responsible for migrating the key into"},{"line_number":96,"context_line":"Barbican. However, there are multiple places where the code needs to handle"},{"line_number":97,"context_line":"the key ID, and each instance would need to be updated to perform the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_fd5fd60b","line":94,"updated":"2017-10-18 20:23:01.000000000","message":"Separate question: how do other projects handle migration of existing items to a new back end?  For example, migrating volumes to a new cinder back end.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"},{"author":{"_account_id":21129,"name":"Alan Bishop","email":"abishopsweng@gmail.com","username":"ASBishop","status":"ex Red Hat"},"change_message_id":"b5f4e959ee66c71072f99f3c9d9690eb0f49f7a6","unresolved":false,"context_lines":[{"line_number":91,"context_line":"Alternatives"},{"line_number":92,"context_line":"------------"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"Instead of using a separate migration thread, each piece of code that fetches"},{"line_number":95,"context_line":"and uses the encryption key ID could be responsible for migrating the key into"},{"line_number":96,"context_line":"Barbican. However, there are multiple places where the code needs to handle"},{"line_number":97,"context_line":"the key ID, and each instance would need to be updated to perform the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f4b6375_8744dd1c","line":94,"in_reply_to":"3f4b6375_fd5fd60b","updated":"2017-10-20 13:59:03.000000000","message":"I have no experiences to share, but perhaps others can add theirs.","commit_id":"3581aba6ae4849e5168227bb06d6973ca62a6e39"}]}