Hi,
I’m currently developing modules to automate the process of testing OpenStack with Tempest.
In one of the modules, that configs Tempest, I’m using Tempest to interact with the target OpenStack.
I’ve recently saw that OpenStack module shouldn’t use OpenStack Client libraries, should I re-write the module to use shade?
Thanks,
Tal Shafir
Hi Tal!
Modules that use the OpenStack APIs should use shade to do so. Does the module need to make API calls to configure tempest? If so, then yes please. If not, then you should be fine.
Is there a link to what you’ve got so far that I could look at? I might be able to point you in the right direction more easily that way.
Thanks!
Monty
Thanks for the reply 
The module I’m working on is supposed to replace Red Hat’s config_tempest.py (https://github.com/redhat-openstack/python-tempestconf/blob/master/config_tempest/config_tempest.py).
For example, in case the user wants to create resources for Tempest it requires interacting with the OpenStack.
About my module, here is the link: https://github.com/TalShafir/ansible/blob/module/os_tempest_config/lib/ansible/modules/cloud/openstack/os_tempest_config.py
I’m still using Red Hat’s api_discovery which I’ll need to replace with shade for sure(for some reason shade.operator_cloud’s list_services() doesn’t work for me).
Ah - thanks -that’s helpful context.
From what I can see there, no, I do not think you need to re-implement anything in shade (well, except for maybe for the list_services thing) The main thing we want to ensure is that if anyone needs to provide an openstack module with authentication credentials that it go through clouds.yaml/os-client-config so that all the auth plugins and different SSL options and other madness are all supported the same across all the modules.
This module is dealing with tempest config files -so I’m pretty sure those should behave as people expect tempest to behave. I’d imagine that, for this module, even if you do need to use shade to do some things, you’d be driving it from that tempest config file rather than asking the user of the ansible module to directly provide auth information as parameters.
Also - let’s definitely connect somewhere on list_services not working for you. Some weird bugs just go uncovered in the last couple of days related to admin interactions with the keystone v2 api. Whether you’re hitting those - or have a whole new issue - I’d love to get it fixed for you.
Thanks, I’m glad I’ve checked before re-implementing most of the module.
About the getting the data for shade using the configuration file I’ve started to work on it but (as you could see) haven’t pushed it yet.
The error I got was: “shade.exc.OpenStack Cloud Exception: The service catalog is empty.”
My OpenStack is a packstack all-in-one for the development of the modules.
The code that generated the error(as a test):
d = {‘regions’: [‘RegionOne’], ‘auth’: {‘username’: ‘admin’, ‘password’: ‘ba15321d19ef4041’,
‘auth_url’: ‘http://192.168.133.128:5000/v2.0’}}
cloud = shade.operator_cloud(**d)
print cloud.list_services()
K. You’re not sending project information, but that shouldn’t matter.
Can you try:
import shade
shade.simple_logging(http_debug=True)
d = {‘regions’: [‘RegionOne’],
‘auth’: {‘username’: ‘admin’, ‘password’: ‘ba15321d19ef4041’,
‘auth_url’: ‘http://192.168.133.128:5000/v2.0’}}
cloud = shade.operator_cloud(**d)
print cloud.list_services()
Also - maybe send to me over at mordred@inaugust.com directly - this might be getting a little OpenStack-internals-y for the ansible-devel list
Thanks, I’ll send you the result in a few minutes(need to turn on the virtual machine).