[openstack-dev] [Ironic][Keystone] Move drivers credentials to Keystone

Matt Wagner matt.wagner at redhat.com
Tue Mar 25 20:50:11 UTC 2014


On 25/03/14 12:23 +0000, Lucas Alvares Gomes wrote:
>Hi,
>
>Right now Ironic is being responsible for storing the credentials for the
>IPMI and SSH drivers (and potentially other drivers in the future), I
>wonder if we should delegate this task to Keystone. The Keystone V3 API now
>has a /credentials endpoint which would allow us to specify arbitrary types
>(not only ec2 anymore) and use it as a credential store[1].
>
>That would avoid further fragmentation of credentials being stored in
>different places in OpenStack, and make the management of the credentials
>easier (Think about a situation where many nodes share the same IPMI
>username/password and we need to update it, if this is stored in Keystone
>it only needs to be updated there once cause nodes will only hold a
>reference to it)
>
>It also was pointed to me that setting a hard dependency on Keystone V3
>might significantly raises the bar for integration with existing clouds*.
>So perhaps we should make it optional? In the same way we can specify a
>username/password or key_filename for the ssh driver we could have a
>reference to a credential in Keystone V3?

As others seem to be saying, I think it might make sense to make this
pluggable. Store it in driver metadata, or store it in Keystone, or
store it in Barbican. Of course, that's 3x the effort.

As a relative newcomer -- is it problematic for us to leverage an
incubated service? I suppose that a pluggable approach with Barbican
as one option would alleviate any problems that might exist.

This would argue to me that the easiest thing for Ceilometer might be
to query us for IPMI stats, if the credential store is pluggable.
"Fetch these bare metal statistics" doesn't seem too off-course for
Ironic to me. The alternative is that Ceilometer and Ironic would both
have to be configured for the same pluggable credential store.

Or am I crazy?

-- Matt



More information about the OpenStack-dev mailing list