<div dir="ltr">Seems really well thought out. Super impressed by the level of detail here. Consolidation of duplicated code is pretty much always a good idea in my book. Thanks for getting this rolling. <br><br>I am happy to review as you push patches. Might also be good to get Kaitlin Farr involved too since she knows a lot in this area. <br><div><br></div><div>-Kendall (diablo_rojo)</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">On Tue, Oct 10, 2017 at 9:40 AM Alan Bishop <<a href="mailto:abishop@redhat.com">abishop@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There is an ongoing effort to deprecate the ConfKeyManager, but care<br>must be taken when migrating existing ConfKeyManager deployments to<br>Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican,<br>but the process of switching from one key manager to another will need<br>to be done smoothly to ensure encrypted volumes continue to function<br>during the migration period.<br><br>One thing that will help the migration process is consolidating the<br>two ConfKeyManager implementations (one in Cinder and one in Nova).<br>The two are functionally identical, as dictated by the need to derive<br>the exact same secret from the fixed_key. While it may seem counter-<br>intuitive, adding a ConfKeyManager implementation to Castellan will<br>facilitate the process of deprecating them in Cinder and Nova.<br><br>To that end, I identified a series of small steps to get us there:<br><br>1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova<br>so they are identical (right now their help texts are slightly <br>different). This step avoids triggering a DuplicateOptError exception<br>in the next step.<br><br>2) Add a ConfKeyManager implementation to Castellan. This essentially<br>involves copying in one of the existing implementations (either Cinder's<br>or Nova's).<br><br>3) Replace Cinder's and Nova's implementations with references to the<br>one in Castellan. This can be done in a way that retains compatibility<br>with the key_manager "backend" (was "api_class") config options<br>currently used by Cinder and Nova. The code in <br>cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py<br>will collapse down to this:<br><br>  from castellan.key_manager import conf_key_manager<br><br>  class ConfKeyManager(conf_key_manager.ConfKeyManager):<br>      pass<br><br>Having a common ConfKeyManager implementation will make it much<br>easier to support migrating things to Barbican, and that's an important<br>step toward the goal of deprecating the ConfKeyManager entirely.<br><br>Please let me know your thoughts, as I plan to begin proposing patches.<br><br>Regards,<br><br>Alan Bishop<br><br></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>