misleading error message when openrc not sourced

[Simon Chang]

Platform:
Devstack (Grizzly) running on Ubuntu 12.04 (Precise)

The Issue:
The swift command returns "The service catalog is empty" error when the user forgot to source openrc after running stack.sh. The error message does not provide the user accurate information to correct the issue.

To replicate:
./stack.sh
swift -A <keystone_url> --os-username=<user_id> --os-password=<password> stat

Expected Result:
Failed to retrieve service catalog. Make sure openrc has been sourced.

Actual Result:
Traceback (most recent call last):
  File "/usr/local/bin/swift", line 7, in <module>
    execfile(__file__)
  File "/opt/stack/python-swiftclient/bin/swift", line 1446, in <module>
    error_queue)
  File "/opt/stack/python-swiftclient/bin/swift", line 674, in st_stat
    headers = conn.head_account()
  File "/opt/stack/python-swiftclient/swiftclient/client.py", line 1159, in head_account
    return self._retry(None, head_account)
  File "/opt/stack/python-swiftclient/swiftclient/client.py", line 1120, in _retry
    self.url, self.token = self.get_auth()
  File "/opt/stack/python-swiftclient/swiftclient/client.py", line 1096, in get_auth
    insecure=self.insecure)
  File "/opt/stack/python-swiftclient/swiftclient/client.py", line 328, in get_auth
    insecure=insecure)
  File "/opt/stack/python-swiftclient/swiftclient/client.py", line 273, in get_keystoneclient_2_0
    endpoint_type=endpoint_type)
  File "/opt/stack/python-keystoneclient/keystoneclient/service_catalog.py", line 159, in url_for
    raise exceptions.EmptyCatalog('The service catalog is empty.')
keystoneclient.exceptions.EmptyCatalog: The service catalog is empty.

[Tim Burke (1-tim-z)]

(Judging by line numbers, the traceback was from swiftclient 1.5.0.)

As best I can tell, this was fixed in https://review.openstack.org/#/c/94353/ (and released in 2.2.0). The client should now correctly error out with:

  No tenant specified

or, if it detects Keystone v3:

  No project name or project id specified.

Thanks to Donagh for spotting the need for `os_options.get(...)` instead of `... in os_options`!