Update results.go - Githubissues

mehrdadpfg commented 5 years ago

adding identity_interface param to be parsed from clouds.yaml

jtopjian commented 4 years ago

@mehrdadpfg Thanks for submitting this. Can you provide background information on where this is supported in a clouds.yaml file?

mehrdadpfg commented 4 years ago

@jtopjian when you want to scrape data from OpenStack you need to identify the type of endpoint you are reaching.

cloud.yaml openstack ansible template

and also

openstack exporter

jtopjian commented 4 years ago

I apologize for being unclear. Let me break this up into a few parts:

First, it appears that the upstream Python OpenStack libraries don't actually support identity_interface as a valid field in clouds.yaml. Any example clouds.yaml file you see with this key is either in error or is supporting an old version of clouds.yaml (which if the latter is true and we can see some git history in the Python SDKs for that, I'm open to adding support for identity_interface).

Please see the following links:

None of the results in the above links are related to clouds.yaml.

You can also verify this by doing the following exercise (assuming your Keystone environment is using port 35357 for the admin interface and 5000 for public and internal):

Ensuring clouds.yaml has no identity_interface set, run:

$ openstack --debug project list

And notice that it queries port 35357 by default:

REQ: curl -g -i -X GET https://example.com:35357/v3/projects?

Next, add identity_interface: public to clouds.yaml and run the above command. Port 35357 is still queried. Not port 5000. So the field made no difference.

Now run:

$ OS_INTERFACE=public openstack --debug project list

And you'll see:

REQ: curl -g -i -X GET https://keystone-yyc.cloud.cybera.ca:5000/v3/projects?

Again, it's possible that identity_interface used to be a valid value in clouds.yaml in the past. If git history references of this field can be provided in the Python SDKs, we can look at adding it.

Second, as mentioned above OS_INTERFACE appears to be a valid environment variable that can set which interface to query. We can also see that this is properly defined in the Python SDKs:

https://github.com/openstack/osc-lib/blob/17179a72b021e0e5d848a3c852d297ec9a45e1c7/osc_lib/shell.py#L254-L265

OS_INTERFACE is stored in a variable called interface. Let's see how this is translated in os-client-config:

https://github.com/openstack/os-client-config/blob/master/os_client_config/cloud_config.py#L111-L117

So it appears that both interface and endpoint_type are two valid values, depending on which service is being queried:

And if you run the previous exercise with interface: public in clouds.yaml, you'll see that Keystone successfully queries on port 5000 and not 35357. You can also run the exercise with endpoint_type: public and also see the same result.

So now we have two confirmed correct keys: interface and endpoint_type that support should be added for (but only one new environment variable: OS_INTERFACE).

Which brings us to the third part: just adding these keys to the Cloud struct isn't actually going to do anything. It needs to be filtered down to the actual client creation, kind of similar to what @niedbalski did in https://github.com/openstack-exporter/openstack-exporter/pull/59. If the intention of adding this single field to gophercloud/utils.Cloud is so that it can be used with the openstack-exporter patch, that might work. But I'd rather see full support added to gophercloud/utils so that other applications don't need to implement similar patches.

Please let me know if this makes sense and/or if you have any questions.

jtopjian commented 4 years ago

Implemented in #97

mehrdadpfg commented 4 years ago

@jtopjian thanks for your patience and taking time for fixing this issue.

gophercloud / utils

Update results.go #95