There is an ongoing effort to deprecate the ConfKeyManager, but care must be taken when migrating existing ConfKeyManager deployments to Barbican. The ConfKeyManager's fixed_key secret can be added to Barbican, but the process of switching from one key manager to another will need to be done smoothly to ensure encrypted volumes continue to function during the migration period.
One thing that will help the migration process is consolidating the two ConfKeyManager implementations (one in Cinder and one in Nova). The two are functionally identical, as dictated by the need to derive the exact same secret from the fixed_key. While it may seem counter- intuitive, adding a ConfKeyManager implementation to Castellan will facilitate the process of deprecating them in Cinder and Nova. To that end, I identified a series of small steps to get us there: 1) Unify the "fixed_key" oslo_config definitions in Cinder and Nova so they are identical (right now their help texts are slightly different). This step avoids triggering a DuplicateOptError exception in the next step. 2) Add a ConfKeyManager implementation to Castellan. This essentially involves copying in one of the existing implementations (either Cinder's or Nova's). 3) Replace Cinder's and Nova's implementations with references to the one in Castellan. This can be done in a way that retains compatibility with the key_manager "backend" (was "api_class") config options currently used by Cinder and Nova. The code in cinder/keymgr/conf_key_manager.py and nova/keymgr/conf_key_manager.py will collapse down to this: from castellan.key_manager import conf_key_manager class ConfKeyManager(conf_key_manager.ConfKeyManager): pass Having a common ConfKeyManager implementation will make it much easier to support migrating things to Barbican, and that's an important step toward the goal of deprecating the ConfKeyManager entirely. Please let me know your thoughts, as I plan to begin proposing patches. Regards, Alan Bishop
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev