Having the same problem with os_volume that I had with glance images where I get a 404 error.
Error message:
fatal: [localhost]: FAILED! => {“changed”: false, “failed”: true, “msg”: “Error fetching volume list: Not Found (HTTP 404)”}
When I got an error like this with glance, I had to go in and modify some code in the shade library. I made sure I put the shade library back to what it was before so it shouldn’t be the issue here.
My OpenStack (metacloud) uses v1 APIs of cinder.
The other issue, somewhat related is using the security_groups found in 2.0. Those don’t work with my openstack environment either because they require neutron. No neutron in my environment.
Sorry you’re having issues. Sounds like metacloud is doing something we don’t expect with
their endpoints since you are having the same problem. This is difficult to debug without a
metacloud account.
Your solution to the image service problem was to add code to remove the “/v1”. Does that
solution also fix the problem with the volume service?
As for security groups, in your clouds.yaml (which I assume you are using?), you will need
to set ‘secgroup_source’ to ‘nova’. It defaults to using neutron.
-Dave
Ah, thanks for the info on the security group stuff. I’ll try that out. I’m happy to let someone have a metacloud account to test things with.
We aren’t doing anything special on our URLs at all. Attached is the output of a keystone catalog. I would appreciate any feedback you might have on any issues you see with the catalog.
As mentioned Vallard can provide access to a publicly available cloud for testing purposes.
keystone catalog
Service: compute
Accounts would be most helpful and appreciated. Myself and Monty Taylor do most of the Ansible and
shade development, so if we could both get access, that would go a long way to improving the modules
for you. Please email me off-list to let me know what you need from us to make that happen.
-Dave
Everything Shrews says is correct - I would love an account - and we can add a metacloud profile to os-client-config too. I’m sure you’re not doing anything too crazy - it turns out that the number of ways all this can combine are large - we have all sorts of logic already to handle “normal” behavior. I’m sure we’ll just find another nugger of normal 
Thanks. I’ll set it up tomorrow and email you both off list.
So, good news and good-ish news…
The glance 404 problem you were experiencing should be fixed in shade.
I have tested this against your cloud. We haven’t released a new version
with the fix yet, but you can pull in the latest code from the source repo
(https://github.com/openstack-infra/shade) and give that a test, if you like.
Since the default image API version is 2, you should set
image_api_version to 1 in your clouds.yaml file, or set the environment
variable OS_IMAGE_API_VERSION to 1, if you aren’t using a clouds.yaml.
As for the volume 404 problem, I cannot reproduce that with the latest
released version of shade, which is 0.14.0, against your cloud. Can you
try upgrading shade and testing that again?
-Dave