pyrax.set_credentials() throws pyrax.exceptions.IdentityClassNotDefined exception

[mlew]

Authenticating with pyrax.set_credentials() seems to have broken in pyrax >=1.4.0. When I try to run code that worked with 1.3.9 I get the following exception:

pyrax.exceptions.IdentityClassNotDefined: No identity class has been defined for the current environment.

[EdLeafe]

Duplicate of #77. Fixed in v1.4.1

[mlew]

I tried running the same code that works with pyrax 1.3.9 using 1.4.0 and 1.4.1. With each of these distributions I'm still getting the following exception:

pyrax.exceptions.IdentityClassNotDefined: No identity class has been defined for the current environment

My code looks like this:

import pyrax

pyrax.set_settings(username, key, region=region)

[sivel]

Ed,

I am not sure this is the same thing. This is caused when there is no ~/.pyrax.cfg file or if the file exists but is empty, as pyrax.Settings.read_config either doesn't get called or doesn't actually do anything. If there is no such file, pyrax.identity is not set up. Seeing as though there is a default_identity_type, I'd imagine, that regardless of having a config file, this should still work.

As it stands now, I cannot see any easy way of authenticating without a ~/.pyrax.cfg. Unless I am just missing something obvious here.

The only way I see that it can work without having a .pyrax.cfg is to do something like:

import pyrax
cls = pyrax.utils.import_class('pyrax.identity.rax_identity.RaxIdentity')
pyrax.identity = cls()
pyrax.set_credentials('username', 'apikey')

[EdLeafe]

OK, I think the report just looked the same as the one from yesterday. This is not a bug; rather, it is exactly what the exception was designed to do.

You have to define the identity class somehow: in either the config file, in the environment variable, or by calling pyrax.set_setting("identity_type", "rackspace"). I will fix the bug for set_setting(), and also fix a few more little outliers that I've noticed. Stay tuned.

[sivel]

Using pyrax.set_setting with an empty or non-existent file seems to fail as well

>>> import pyrax
>>> pyrax.settings.set('identity_type', 'rackspace')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/matt/python_venvs/pyrax/pyrax/pyrax/__init__.py", line 171, in set
    dct = self._settings[env]
KeyError: 'default'

You may have some other changes coming that will help, but I imagine more than just that would be required to make set_setting on it's own handle this case. Just trying to figure out what the best practice way of doing this will be without a .pyrax.cfg file.

Since this is a somewhat non-backwards compatible change, it would be good to have a standard "resolution" to getting people back up and running, that may not involve a .pyrax.cfg file. Of course creating a .pyrax.cfg file and giving at least a heading will resolve things. However, a pure code based approach may make it easier for deploying applications utilizing pyrax. So far, it looks like my code snippet above is the easiest I have found, but again, I haven't had much time to dig through the new code, so you may know of something I am missing.

[EdLeafe]

Yes, I've handled that. And no, it should be backwards-compatible - that's why these things are bugs. I added the environment variable support as well as the manual settings so that the config file wouldn't be required. I guess the only thing that isn't backwards-compatible is that you can no longer assume that the can only be run on Rackspace.

[EdLeafe]

OK, 1.4.2 has been pushed. Let me know if any problems remain.

[mlew]

Ok, looks like this is fixed, but I had to add the following line before I called set_credentials(), as sivel pointed out:

pyrax.settings.set('identity_type', 'rackspace')

The docs should be updated here to reflect this additional requirement.

[EdLeafe]

I added that information in the section below ("Pyrax Configuration"). But you're correct - it's probably good to mention it in the auth section as well.

[michelts]

@EdLeafe the settings tell me I can use OS environment variables but I couldn't make it. In the issue #82 I explain a little more about it.

[amg84]

This seems like a bug, I have only been using the pyrax for about an hour, so I might have overlooked something, but it seems odd that set_credentials authorises and then list_containers fails for being Unauthorised:

import pyrax
pyrax.set_setting("identity_type", "rackspace")
pyrax.set_credentials(username, api_key)
cf = pyrax.cloudfiles
cf.list_containers()
Traceback (most recent call last):
File "", line 1, in
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/pyrax/cf_wrapper/client.py", line 44, in _wrapped
return fnc(_args, *_kwargs)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/pyrax/cf_wrapper/client.py", line 894, in list_containers
hdrs, conts = self.connection.get_container("")
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1080, in get_container
full_listing=full_listing)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1022, in _retry
self.url, self.token = self.get_auth()
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1010, in get_auth
insecure=self.insecure)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 329, in get_auth
insecure=insecure)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 263, in get_keystoneclient_2_0
raise ClientException('Unauthorised. Check username, password'
swiftclient.client.ClientException: Unauthorised. Check username, password and tenant name/id

[EdLeafe]

Hmmm... I'm not able to reproduce this. Can you tell me what version of python-swiftclient is installed?

If it's 1.3.0 or later, could you run this and let me know what it outputs?

import pyrax
pyrax.set_setting("identity_type", "rackspace")
pyrax.set_credentials(username, api_key)
cf = pyrax.cloudfiles

print "OPTS", cf.connection.os_options

cf.list_containers()

[amg84]

Here you go:
python-swiftclient==1.4.0

import pyrax
pyrax.set_setting("identity_type", "rackspace")
pyrax.set_credentials('', '')
cf = pyrax.cloudfiles
print "OPTS", cf.connection.os_options
OPTS {'region_name': 'DFW', 'tenant_id': u'10006071', 'auth_token': u'436efddf72884a8299bea611c034bcde', 'endpoint_type': 'publicURL', 'tenant_name': u'10006071', 'object_storage_url': None}
cf.list_containers()
Traceback (most recent call last):
File "", line 1, in
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/pyrax/cf_wrapper/client.py", line 44, in _wrapped
return fnc(_args, *_kwargs)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/pyrax/cf_wrapper/client.py", line 894, in list_containers
hdrs, conts = self.connection.get_container("")
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1080, in get_container
full_listing=full_listing)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1022, in _retry
self.url, self.token = self.get_auth()
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 1010, in get_auth
insecure=self.insecure)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 329, in get_auth
insecure=insecure)
File "/home/agrundy/virtualenv/hive_cloudfiles/local/lib/python2.7/site-packages/swiftclient/client.py", line 263, in get_keystoneclient_2_0
raise ClientException('Unauthorised. Check username, password'
swiftclient.client.ClientException: Unauthorised. Check username, password and tenant name/id

Issues in the past (python-cloudfiles) have stemmed from the fact I am trying to connect to the UK cloud files, could this be the cause?

[EdLeafe]

Yes, that is definitely the case here. pyrax still defaults to the 'DFW' region, as seen in the output you provided: 'region_name': 'DFW'. To use any other region, add the line:

pyrax.set_setting("region", "LON")

before the call to set_credentials().

[EdLeafe]

Hold on - I just tested this, and found another bug. I've opened up a new issue: #86.

[EdLeafe]

OK, @amg84 - this has been fixed in 1.4.5. You can now set the region using pyrax.set_setting("region", "LON").