Find Alternative for os-tenant-networks

[jtopjian]

Per a comment in #5216, a user reported that the os-tenant-networks extension is disabled. This was reported in two or three other issues, notably with HP's cloud.

os-tenant-networks provides an easy way to map network UUIDs to "human-readable" names and is a valid Nova API extension, but some flavors of OpenStack and some OpenStack sites might disable it (for reasons I'm not entirely sure of).

It would be a good long-term solution to find an alternative way to map a network UUID to a human-readable name. Bonus points for seamlessly supporting both nova-network and Neutron, which is what os-tenant-networks currently enables.

Edit: #3460 has a lot of background on os-tenant-networks.

[gravaton]

This is very important to me - my current work environment is an OpenStack cluster that has disabled the os-tenant-networks API and this causes terraform plan to fail and basically renders the tool completely unusable :sob:

I'm also going to be looking into any possible workarounds.

[jtopjian]

@gravaton the current workaround is to define both name and uuid in the network block. That manually creates the bridge where different portions of the network info are stored as well as bypasses os-tenant-networks.

Both should be exported by the neutron network resource, so you should be able to programmatically define them.

Let me know if that's not working for you. It has for all other cases to date and if it turns out there are cases appearing where the workaround is no longer applicable, then this will definitely be expedited.

Of course, defining both is redundant and unintuitive. I hope we can find an alternative solution that doesn't require that.

[gravaton]

@jtopjian So I got the network name and UUID from our team here and tried the workaround but Terraform is still breaking over this. We are not using Neutron networking, we're just using basic Nova networking. I don't have a particularly complicated configuration - my .tf file has only one item in it, an openstack_compute_instance_v2 and I inserted the network block into that. From what I've read that's right - let me know if I mucked it up somehow.

It's possible for us to enable the problem API but it will take literally months for that configuration change to propagate and I'm not sure why it's necessary when I, as a user of the OpenStack cloud, have no ability to specify the network configuration of my hosts to begin with. Since Terraform can't choose or manage those things a failure to get detailed information about them shouldn't be a fatal error.

[jtopjian]

@gravaton Thanks for the notes.

I totally agree with you. Most OpenStack clouds I run are nova-network based and I don't even have to specify a network block. As you say, since the user cannot change the network information (which is true of 99% of nova-network environments), that should translate into Terraform. And it would... if os-tenant-networks wasn't disabled (I mean that lightheartedly).

Are you saying you're seeing crashes? Normally the instance would successfully create, you just won't be able to see many network attributes of it. If you are seeing a crash, could you post either the crash log or the output of TF_LOG=DEBUG terraform apply to a gist (the latter would be preferable... please make sure to sanitize, though).

Edit: Also, could you let me know the results of the following:

$ nova net-list           (should fail)
$ nova network-list       (this uses `os-networks` rather than `os-tenant-networks`)

[gravaton]

@jtopjian What I'm seeing is a little bit interesting. If I have no saved state, Terraform will properly 'plan' and 'apply'. But once I have properly brought up a host with terraform apply, attempting to further terraform plan or terraform apply attempts to refresh state on my infrastructure and errors out with the following:

Error refreshing state: 1 error(s) occurred:

* openstack_compute_instance_v2.test-server: Expected HTTP response code [200 204] when accessing [GET https://redacted.openstack.hostname:8774/v1.1/redacted_api_key/os-tenant-networks], but got 403 instead
{"forbidden": {"message": "Policy doesn't allow compute_extension:os-tenant-networks to be performed.", "code": 403}}

Terraform doesn't seem to be CRASHING per se, it's handling and reporting the errors and exiting gracefully, but it's also not letting me do anything so I'm only mildly pleased with that :smile:

The gist with my sanitized output is here: https://gist.github.com/gravaton/3bfb568dd38a795f59a9

The results of those commands are, respectively: ERROR: Policy doesn't allow compute_extension:os-tenant-networks to be performed. (HTTP 403) and ERROR: Policy doesn't allow compute_extension:networks:view to be performed. (HTTP 403)

It looks like both endpoints are currently disabled.

[jtopjian]

ah-hah! This might be an easy fix.

Would you be able to build from source including the patch in #5432?

General building information can be found in the README file.

[gravaton]

@jtopjian - I'm using a version of Terraform compiled with your patch and so far it's looking good, all use cases are now functional. I'm going to play with it a lot more so I'll let you know if there's any further issue. Thanks so much for the fast turnaround!

[gravaton]

To follow up - after hours of experimentation I have not found any further issues. I would consider this patch to have resolved the issue.

[jtopjian]

Great news! The patch is now merged and will be part of 0.6.13.

[edmondsw]

This should be able to support both neutron and nova-network (which is going away) by checking the service catalog to see if neutron is there or not. If it is, talk to neutron. If it's not, fall back on what you've currently got talking to nova. And then folks won't have to specify network id-to-name mapping manually when nova's os-tenant-networks APIs are disallowed in environments that want everything to run through neutron.

One way or another, this will have to be updated to talk to neutron at some point. The nova os-tenant-networks API is deprecated, and no longer functions starting from microversion 2.36. See https://developer.openstack.org/api-ref/compute/#project-networks-os-tenant-networks-deprecated

[jtopjian]

@edmondsw Thanks for the notes. Yeah, I'm aware that the nova os-tenant-network and os-network Compute APIs are being removed, which puts this in a bit of a priority.

One way or another, this will have to be updated to talk to neutron at some point.

This is something I want to avoid as much as possible. The absolute best case scenario is if each of the OpenStack resource groups (compute, blockstorage, networking, etc) do not require communicating with resources in other groups. I've been able to do this with any compute/blockstorage mixtures found in the resources. Any time you see a blockstorage reference in the resource_openstack_compute_v2 code, it's legacy and will be removed in the next few months.

Networking is the next beast to tackle. I've started this by creating the openstack_compute_floatingip_associate resource which means that all Floating IP code in the instance resource can be removed at some point.

Next it's the network name/uuid code. It should be possible to do this with the introduction of the data_openstack_networking_network_v2 data source for existing networks and simply referencing the exported attribute for networks that are created in the Terraform configuration.

Thanks for the poke on this - this Issue was up for a well deserved update. :)

Let me know if you have any questions or see any problems with the above ideas.

Edit: Just for informational purposes, I'll elaborate more on what I mean by trying to keep resource groups separate:

There are a few OpenStack API calls that act as bridges to other resource groups. For example, Nova has the os-volume_attachments API which will internally contact Cinder on behalf of the user. This is a much better solution than Terraform implementing both Nova and Cinder code in a single resource.

There are similar API calls for associating and disassociating floating IPs from an instance.

It's important to note that while Nova has deprecated (and is starting to remove) some API calls around both volumes and IP addresses, the above two examples are still valid.

IMO, the best case scenario is to always leverage these API calls rather than reinventing them in the application itself. This seems to have proven true so far, but I don't ever claim to be an expert on these things, so corrections are absolutely appreciated! :)

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.