Open Stack

On Dec 19, 2012, at 1:08 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:

> 
> 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.

Understood, my primary concern is around making sure this is still *possible* as I wouldn't want this code stripped out of the Compute API and Virt layers unless suitable extension points were provided to replace this functionality.

>> 
>> 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.
> 

I agree the metadata server or config drive should be the standard, my hope is that we can keep the ease of specifying files at the command line with a server create no matter what the back-end may be.

>> 
>> 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?

I personally think the admin password implementation is "secure enough". All data should be accessed through SSL and the password is currently never stored. I don't think we should ever endeavor to store the admin password, no matter how secure it might seem. I like that right now it's sent to the agent and the user once and then lost into the ether.

> 
> Vish
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev