search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.6k stars 9.54k forks source link

openstack_networking_port_v2 issue when tenant does not have fixed_ip permissions #4541

Closed cliffpracht closed 8 years ago

cliffpracht commented 8 years ago

HI,

It appears that there might be a bug in Terraform that stops users from using the openstack_networking_port_v2 resource if the tenant does not have privileges to create fixed_ips.

The resource call that I am trying to run is the following:

resource "openstack_networking_port_v2" "port_1" {
  name = "port_1"
  network_id = “b0c63885-431a-4975-bfd1-cc9f8d53e8c6”
  admin_state_up = "true"
}

The tenant that I am connecting as does not have admin privileges or is not the network owner. The tenant has the ability to create ports on this network, but not the ability to specify fixed IPs. This is a snip of the policy file on the Openstack server

 "create_port:fixed_ips": "rule:admin_or_network_owner"

I can confirm this by running neutron directly from the command line using same tenant. 

>  neutron port-create b0c63885-431a-4975-bfd1-cc9f8d53e8c6
Created a new port:
+-----------------------+------------------------------------------------------------------------------------+
| Field                 | Value                                                                              |
+-----------------------+------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                               |
| allowed_address_pairs |                                                                                    |
| binding:vnic_type     | normal                                                                             |
| device_id             |                                                                                    |
| device_owner          |                                                                                    |
| fixed_ips             | {"subnet_id": "b4033930-131c-4972-8097-bb60f16114fd", "ip_address": "10.80.2.150"} |
| id                    | 7140398e-4818-4aab-a6c9-bb4c0aa79789                                               |
| mac_address           | fa:16:3e:21:2f:f9                                                                  |
| name                  |                                                                                    |
| network_id            | b0c63885-431a-4975-bfd1-cc9f8d53e8c6                                               |
| security_groups       | dd48a1bb-f136-4f7c-9cdb-00032afec550                                               |
| status                | DOWN                                                                               |
| tenant_id             | be6c136dafb746d997b86e7971b4e871                                                   |
+-----------------------+------------------------------------------------------------------------------------+

Running terraform apply I get the following error. Notice that I am not actually setting fixed_ip

Error applying plan:

1 error(s) occurred:

* openstack_networking_port_v2.sdc_port_1: Error creating OpenStack Neutron network: Expected HTTP response code [201 202] when accessing [POST http://10.80.51.66:9696/v2.0/ports], but got 403 instead
{"NeutronError": {"message": "Policy doesn't allow create_port to be performed.", "type": "PolicyNotAuthorized", "detail": ""}}

Tracing the request for Terraform, this is what the POST request JSON looks like. Notice that fixed_ips is being sent as empty array:

{"port":.{"network_id":."b0c63885-431a-4975-bfd1-cc9f8d53e8c6",."name":."for_mels_testing",."admin_state_up":.true,"fixed_ips”:[],"security_groups":[]}}

The same POST using the neutron CLI looks like this.

{"port":.{"network_id":."b0c63885-431a-4975-bfd1-cc9f8d53e8c6",."name":."for_mels_testing",."admin_state_up":.true}}

So it appears that we are sending fixed_ip parameter (as well as security_id) when they are not specified. This causes the request to fail because the tenant does not have fixed_ip permissions.

Cliff

cliffpracht commented 8 years ago

Hi,

So I made a fix to my forked branch, I was looking for some feedback as to if this is the right solution to this problem. We are not sure if there was a reason to using []ports.IP originally instead of using interface{}, which is what Gophercloud is initializing it as.

https://github.com/ebsco/terraform/commit/1de2fde147558fc10600638c29e9340651424d14

jtopjian commented 8 years ago

Seems like the right approach to me. Feel free to submit a PR! :smile:

jtopjian commented 8 years ago

@jimmycliff I ran your patch through the acceptance tests that utilize the openstack_networking_port_v2 resource and everything passes. If you'd like to submit a PR for this fix, I'd be happy to merge it. Or if you'd like, I can go ahead and take care of making a PR.

cliffpracht commented 8 years ago

Thanks @jtopjian submitted PR

jtopjian commented 8 years ago

Awesome!

matthughes commented 8 years ago

What version was this fixed in? 0.6.11 was cut after this fix was merged, but I still seem to have the same issue. Just as the original poster pointed out, I can neutron port create; but attempting to do the same thing in vagrant fails even if I don't specify the fixed_ips.

jtopjian commented 8 years ago

@matthughes Ouch... sorry to hear you're still seeing this. The fix was included in 0.6.10, so 0.6.11 would include it, too.

Can you run TF_LOG=DEBUG terraform apply... and post a sanitized version to a gist?

matthughes commented 8 years ago

I think it's actually a different issue; not related to fixed_ips at all. I opened a new issue up in #5171

jtopjian commented 8 years ago

okie dokie :)

ghost commented 4 years ago

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.