> You would just store the url in the DTO. You will need to have the KMIP secret store return the KMIP server that handled the request in the metadata that is returned to Barbican Core.
> each kmip server url would need to be in the barbican-api.conf file? I would assume that would be true. > I'm trying to stray away from making multiple active plugins That is good because only one active secret store is allowed to be active in Barbican. You can add this functionality to the KMIP secret store plugin. You would need to change it to have a list of valid KMIP servers. Then when a request is received to store or generate a key then you would need some algorithm to know which KMIP appliance to choose. Then do everything as normal. At the end then return the KMIP URL in the metatdata. Then all other operations would retrieve the server URL before communicating with the KMIP appliance. I hope that makes sense. If not then I will be around on IRC. -Nate On Fri, Jun 5, 2015 at 1:41 PM, Christopher N Solis <cnso...@us.ibm.com> wrote: > 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 > __________________________________________________________________________ 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