create server should return adminPass

[clayg]

on rackspace's cloud servers the response for a server create returns the initial root password as adminPass in the API response, but the raw response json is lost when the server instance is returned and the adminPass attribute isn't stored on the object.

This means you can get the adminPass when creating a server on the Rackspace cloud with the python-openstacksdk

I'm monkey-patching Resource with the following code:

from openstack import connection, resource

class PatchedResource(resource.Resource):

    def create_by_id(self, *args, **kwargs):
        resp = super(PatchedResource, self).create_by_id(*args, **kwargs)
        self._attrs['adminPass'] = resp.get('adminPass')
        return resp

resource.Resource = PatchedResource

This is obviously a hack, I think could do something a tad bit tighter by monkeypatching compute._proxy.server.Server - but that's still pretty gross.

As I understand it not all cloud's provide an adminPass when creating an instance and key_pairs is the recommend strategy for initial authorization to new servers. Nevertheless the adminPass is super convenient and my ideal client for using OpenStack clouds wouldn't throw out useful information from the response. I hope it would be possible to expose a cleaner solution for retrieving the adminPass from the create_server method when using the Rackspace's OpenStack(ish?) Cloud.

I'm not sure if the ideal fix from the python-openstacksdk perspective is to make the adminPass a proper attribute (admin_pass) on the server instance, or if it would be better to somehow attach the raw response object to the conn.compute.create_server return value so developers can dig out possibly valuable arbitrary information added from extensions? Or perhaps if there is a supported way to inject a subclassed PatchedServerResource onto an existing connection instance's proxy for compute [1]?

I hope this is descriptive and helpful.

1. Maybe here, https://github.com/openstack/python-openstacksdk/blob/2574e9585a55f2554ac10299f18be9fd9c0e852f/openstack/compute/v2/_proxy.py#L280 - if the _server.Server class was attached to the Proxy class as _server_resource_class, it might not feel so gross to override the class attribute on an instance of the compute._proxy.Proxy by saying conn.compute._server_resource_class = PatchedServerResource as opposed to conn.patched_compute = PatchedComputeProxy(conn.session) where PatchedComputeProxy would have to override a half-dozen methods that use the _server.Server class :\ I think this strategy is called dependency injection - and I don't think it would be as obvious a hack as monkeypatching the global class definition - but maybe I'm splitting hairs?

[Brian Curtin (brian.curtin)]

I talked to clayg on IRC and explained some of this, but this should be handled in the Rackspace extension. The relevant bug over there is https://github.com/rackerlabs/rackspace-sdk-plugin/issues/21