pyrax.set_credentials() throws pyrax.exceptions.IdentityClassNotDefined exception about pyrax HOT 16 CLOSED

Duplicate of #77. Fixed in v1.4.1

from pyrax.

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)

from pyrax.

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')

from pyrax.

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.

from pyrax.

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.

from pyrax.

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.

from pyrax.

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

from pyrax.

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.

from pyrax.

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.

from pyrax.

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

from pyrax.

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

from pyrax.

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()

from pyrax.

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?

from pyrax.

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

from pyrax.

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

from pyrax.

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

from pyrax.