Open Stack

On Dec 19, 2012, at 9:47 AM, Brian Lamar <brian.lamar at rackspace.com> wrote:

> I'm personally very keen on consistency and bug squashing so your efforts are appreciated!
> 
> 1) Does 'demoted' mean "no longer a core feature of the API, but will able to be accomplished via non-core extensions"? If I wanted to keep generating admin passwords in my deployment, would OpenStack still support that at the virtualization level? This feature is quite engrained in all layers of OpenStack, not just the HTTP API.

Yes demoted just means it is an extension, not part of the core api. I think this makes sense for admin passwords since it requires a guest agent and doesn't work in a lot of deployments.
> 
> 2) If personalities are being demoted, what is being promoted to take its place? I haven't used config drive yet, but it's my understanding that it's the better/more secure replacement for personalities. Do you think this feature is used much? Is there any way we could keep personalities but use the given data to write to config drive and not use file injection? I do like the 'ease-of-use' factor personalities give.

So personalities are passed into the config drive currently and (I believe) the current version of cloud-init can install them properly. I think using cloud-init via metadata server or config drive should be the "standard" way of doing this, but I don't expect personalities to go away, I just don't think they should be part of core.

> 
> All-in-all it looks like v3 is moving slightly towards the EC2 API (not necessarily a bad thing IMO). Maybe this is because how their API works is more secure, but I *really* like not using SSH keys everywhere. I could be the only one though! 

I've been working on a secure replacement for the admin password stuff. It still requires passing a key on boot, but the admin password is stored securely encrypted and can be retrieved whenever. Is this good enough for you?

Vish