On Tue, 2014-03-25 at 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?
I think the idea of using Keystone for keypair management in Nova is a good one. There is already precedent in Nova for doing this kind of thing ... it's already been done for images, volumes, and network. One problem with the Keystone v3 credentials API, though, is that it does not have support for unique names of keypairs per project, as that is how the Nova API /keypairs resource endpoint works. > What you guys think about the idea? What are the cloud > operators/sysadmins view on that? As long as the functionality was enabled using the standard driver-based setup (as was done for glance, nova, cinder, and neutron integration), I don't see any issues for deployers. Of course, you'd need a migration script, but that's not a huge deal. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
