Hello Chris, I defer to Nate and Kaitlin for things KMIP.
>From a config perspective though, it seems that something needs to decide >which KMIP backend handles which secret. Where ever that decision-making logic >lives (in Barbican or in a proxy that Barbican talks to), it has to know what >KMIP backends are available. If this list of backends is known/static then it >seems that storing these in a config file (like barbican-api.conf) would be >acceptable. Keep in mind that more than one Barbican API node might be hitting >the same KMIP backends concurrently. As for multiple plugins in Barbican, the current approach favors having an instance per plugin class, so IMHO it would be better to have a single multi-KMIP plugin class that handles the above decision logic. This would most likely be your 'active' secret store plugin. Thanks, John From: Christopher N Solis <cnso...@us.ibm.com<mailto:cnso...@us.ibm.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Friday, June 5, 2015 at 12:41 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [Barbican] Multiple KMIP servers on a single barbican Hey all. I wanted to get people's opinion on allowing barbican to talk to multiple KMIP servers. I got good advice from Nathan and John and it seems like it would be pretty easy keeping track of which secret resides in which KMIP applicance. You would just store the url in the DTO. However, in order for barbican to be aware of all KMIP servers wouldn't that mean that each kmip server url would need to be in the barbican-api.conf file? Or somewhere for barbican to know that multiple kmip servers are available? I noticed that there is a blueprint to introduce the concept of a single active and multiple inactive secret store plugins so I'm trying to stray away from making multiple active plugins. Regards, Chris Solis
__________________________________________________________________________ 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
