Query for type "compute" instead of name "nova"

[msabramo]

The former doesn't work in my private OpenStack cloud (from Metacloud), because the service is not named "nova"; it's named "Compute Service".

{
    Name:      "Compute Service",
    Type:      "compute",
    ...
}

As a result of this, I was getting this error from gophercloud while trying to run the Packer OpenStack builder:

Missing endpoint, or insufficient privileges to access endpoint

I think type "compute" is probably a more portable way to do it. That was the impression I got from looking at
http://docs.rackspace.com/auth/api/v2.0/auth-client-devguide/content/Service_Types-d1e265.html

Cc: @sam-falvo, @jrperritt, @mitchellh

[sam-falvo]

Hi @msabramo ! I'm not sure how to address this issue, honestly. Rackspace is a bit of the odd-one of the bunch. According to Openstack's official docs, found http://docs.openstack.org/api/openstack-identity-service/2.0/content/Request_Response_Types-d1e459.html , it appears that "nova" is the more-or-less "standard" name to use. Also, my experiments with Nebula, Inc.'s cloud offerings similarly use "nova".

I will leave this for the Gophercloud community to decide. Since I work for Rackspace, I'm obviously biased, and don't feel comfortable making a command decision on this topic. Thoughts from others are welcome!

[gecampbell]

The name is pretty much up to whoever configures the deployment. The type should be “compute.” At Rackspace, for example, the name is “CloudServersOpenStack.”

On Aug 15, 2014, at 1:49 PM, Samuel A. Falvo II <notifications@github.commailto:notifications@github.com> wrote:

Hi @msabramohttps://github.com/msabramo ! I'm not sure how to address this issue, honestly. Rackspace is a bit of the odd-one of the bunch. According to Openstack's official docs, found http://docs.openstack.org/api/openstack-identity-service/2.0/content/Request_Response_Types-d1e459.html , it appears that "nova" is the more-or-less "standard" name to use. Also, my experiments with Nebula, Inc.'s cloud offerings similarly use "nova".

I will leave this for the Gophercloud community to decide. Since I work for Rackspace, I'm obviously biased, and don't feel comfortable making a command decision on this topic. Thoughts from others are welcome!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/179#issuecomment-52343601.

[msabramo]

In my private OpenStack instance, which was set up by a company called Metacloud, the name is "Compute Service".

[msabramo]

Here's what @gecampbell was saying -- that Rackspace uses the name "CloudServersOpenStack":

http://docs.rackspace.com/servers/api/v2/cs-gettingstarted/content/nova_auth.html

[msabramo]

Is NOVA_SERVICE_NAME a standard environment variable? It looks like it.

Search for NOVA_SERVICE_NAME in these pages:

• https://pypi.python.org/pypi/python-novaclient/2.6.10
• http://goodsquishy.com/2012/08/rackspace-cloud-servers-from-the-command-line/

export NOVA_SERVICE_NAME=cloudServersOpenStack

for example is what the second link suggests for Rackspace.

That said, it seems like the "type" might be a more reliable indicator.

[sam-falvo]

Right, I just posted to Gophercloud-dev, soliciting input from others, since this change could potentially break Packer and/or Nebula users.

My only concern is that querying for type compute potentially will give the wrong results (versus no results which I'd argue is a better solution). For example, Rackspace also has type compute, name cloudServers, which doesn't offer a Nova V2 compatible service. I've had Gophercloud attempt to use that endpoint in the past when just doing a search for type compute.

BTW, for those wondering why v0.2.0 doesn't offer a built-in solution to searching the service catalog, this topic and my inability to come to a consistent solution should prove informative.

[sam-falvo]

I'd never seen NOVA_SERVICE_NAME before in either Rackspace or Openstack documentation. I'll ask around here at the office to see how widely supported it is with our other SDK implementations.

[msabramo]

Ah okay, I didn't realize that there are other types of compute services that are not nova-compatible. In that case, using "type" would be bad. Maybe NOVA_SERVICE_NAME instead then?

[msabramo]

Although I notice that I don't have NOVA_SERVICE_NAME set in my environment and python-novaclient still works. So maybe I'll look in the code and see what it's doing. I would think that's the more or less the "reference implementation" of how to do stuff.

[gecampbell]

Just FYI, it’s quite possible to have multiple endpoints with the type=“compute”

For example, Rackspace’s production system has name=“CloudServersOpenStack” for next-gen and name=“CloudServers” for our first-gen. In some companies, they might have separate clouds for production vs. development/staging.

In other words, to extract the proper endpoint, you need to know the type, the name, the region, and the URLtype (since there may be public vs. private endpoints).

On Aug 15, 2014, at 2:10 PM, Marc Abramowitz <notifications@github.commailto:notifications@github.com> wrote:

Although I notice that I don't have NOVA_SERVICE_NAME set in my environment and python-novaclient still works. So maybe I'll look in the code and see what it's doing. I would think that's the more or less the "reference implementation" of how to do stuff.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/179#issuecomment-52345945.

[devcamcar]

Does gophercloud key off the name of the service or the type? It should be the type and it should be "compute". That lets different vendors put whatever name they want on it ("Nova" or "Compute" or whatever) while still letting client libraries know what a service is when they need to find one. Our keystone service-list looks like:

+----------------------------------+---------------+--------------+---------------------------+
|                id                |      name     |     type     |        description        |
+----------------------------------+---------------+--------------+---------------------------+
| 7dc14a1dc40146f0b0e3957b54969eb6 |     glance    |    image     |    Glance Image Service   |
| 3b626ae1bf184654816df2e7189f8451 |    keystone   |   identity   | Keystone Identity Service |
| 1dfaf8d6286b43ad9f56725b4a7d0668 |      nova     |   compute    |    Nova Compute Service   |
etc
etc
etc
+----------------------------------+---------------+--------------+---------------------------+

[sam-falvo]

So there's no point in even bothering with a default then? We have to add a special case to Gophercloud for every single provider? Seems inefficient.

[msabramo]

When I use python-novaclient, when it successfully finds nova, it hits this line:

https://git.openstack.org/cgit/openstack/python-novaclient/tree/novaclient/service_catalog.py#n80

(Pdb) n
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/novaclient/service_catalog.py(81)url_for()
-> endpoint["serviceName"] = service.get("name")
(Pdb) service_type
'compute'
(Pdb) service.get("type")
u'compute'
(Pdb) service_name
''
(Pdb) service.get("name")
u'Compute Service'

so it appears that it matched because the type matched and it didn't require a particular name.

[sam-falvo]

@devcamcar -- It can key off of any set of fields you provide in the ApiCredentials structure. Fields set to their zero-value are assumed to not be important for determining which endpoint to select. This HAS yielded endpoint selection bugs in the past, which is why I'm no longer advocating this approach in v0.2.0 API.

[sam-falvo]

@msabramo -- Good to know! I'm just waiting to hear back about the NOVA_SERVICE_NAME inside of Rackspace, but other evidence suggests I made a mistake keying off of just the name by default.

[devcamcar]

+1 here

[devcamcar]

Also I don't think NOVA_SERVICE_NAME is valuable. The type should be consistent and most things aren't made aware of that env variable anyway.

[msabramo]

Here's the line in python-novaclient, where it's hard-coded to look for a type of "compute":

https://git.openstack.org/cgit/openstack/python-novaclient/tree/novaclient/client.py#n699

def _construct_http_client(username=None, password=None, project_id=None,
                           auth_url=None, insecure=False, timeout=None,
                           proxy_tenant_id=None, proxy_token=None,
                           region_name=None, endpoint_type='publicURL',
                           extensions=None, service_type='compute', # <-- looks for service_type "compute"
                           service_name=None, volume_service_name=None,
                           timings=False, bypass_url=None, os_cache=False,
                           no_cache=True, http_log_debug=False,
                           auth_system='keystone', auth_plugin=None,
                           auth_token=None, cacert=None, tenant_id=None,
                           user_id=None, connection_pool=False, session=None,
                           auth=None, user_agent='python-novaclient',
                           **kwargs):

[msabramo]

In another part of python-novaclient, it has this:

DEFAULT_OS_COMPUTE_API_VERSION = "1.1"
DEFAULT_NOVA_SERVICE_TYPE_MAP = {'1.1': 'compute',
                                 '2': 'compute',
                                 '3': 'computev3'}

[gecampbell]

Here’s an example of how the endpoint is found in php-opencloud:

https://github.com/rackspace/php-opencloud/blob/master/lib/OpenCloud/Common/Service/CatalogService.php#L193

Note that the URLtype is almost always “public,” so it provides that as a default, but there is no standard for the name. The type, of course, varies by service, but it IS standard (“compute” for Nova).

On Aug 15, 2014, at 2:48 PM, Marc Abramowitz <notifications@github.commailto:notifications@github.com> wrote:

In another part of python-novaclient, it has this:

DEFAULT_OS_COMPUTE_API_VERSION = "1.1"
DEFAULT_NOVA_SERVICE_TYPE_MAP = {'1.1': 'compute',
'2': 'compute',
'3': 'computev3'}

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/179#issuecomment-52349835.

[sam-falvo]

Thanks for everyone's patience. I've received enough feedback from enough people to make the decision to merge. Thanks everyone for your input!