The createImage action for nova returns a URL to the Image created in a Location header. However, it returns one constructed from the internal glance.api_servers config values, which in clouds that have an internal and a public glance api will result in internal URLs being returned to the end user - who likely does not have routable access, given that they are internal API servers.
novaclient currently does not experience any issues since it does not treat the URL as a URL to be used, and instead pops the last element from the url, knowing it to be the image_id and it returns that to the user.
Perhaps a better option would be to add a microversion and return the image id in a json dict response so that everyone can do what nova is doing without feeling dirty about it.
ALSO:
* We should put in a warning to the API docs that createImage is by default a cold snapshot
* We should probably put in a note in the API docs that the Location header return value is more likely than not to be broken, and that if the cloud in question doens't have the new microversion, that the user should pop the ID off the end of the URL
From looking at the glance API reference docs, it looks like /v1/ or /v2/ is always required in a request, so the fact that nova returns an unversioned '/images/