Open Stack

> 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 <cnsolis at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>