this implements two new resource types:
* openstack_networking_secgroup_v2 - create a neutron security group
* openstack_networking_secgroup_rule_v2 - create a newutron security
group rule
Unlike their nova counterparts the neutron security groups allow a user
to specify the target tenant_id allowing a cloud admin to create per
tenant resources.
Official OpenStack clients commonly support specifing a client
certificate/key to enable SSL client authentication when communicating
with OpenStack services. This patch enables such feature in Terraform
with new parameters and environment variables:
* 'cert' provider parameter or OS_CERT env variable to specify client
certificate file,
* 'key' provider parameter or OS_KEY env variable to specify client
certificate private key file.
This commit patches a few acceptance tests in order to get them to
pass under OpenStack Mitaka.
The devstack dev environment script has also been updated to reflect
OpenStack Mitaka as well as the new Terraform dependency vendoring.
This commit enables the ability to authenticate to OpenStack by way
of a Keystone Token. Tokens can provide a way to use Terraform and
OpenStack with an expiring, temporary credential. The token will need
to be generated out of band from Terraform.
This commit adds a no_gateway attribute. When set, the subnet will
not have a gateway. This is different than not specifying a
gateway_ip since that will cause a default gateway of .1 to be used.
This behavior mirrors the OpenStack Neutron command-line tool.
Fixes#6031
Previously, resizing would only work if the flavor_id changed and
would create an error if the flavor_name changes. This commit fixes
this behavior.
It also quickly refactors the getFlavorID function to use
Gophercloud's IDFromName function. getFlavorID was the basis of
IDFromName so the exact same code is used.
Fixes#5780
This is to just catch possible breakage in the future. The actual
support was done in Gophercloud.
Previously, values of 0 were not allowed since there's no such port
as 0. However, there are ICMP codes of 0.
GH-4812 removed reading server.AccessIPv4 and server.AccessIPv6
because, AFAICT, they are not set by Nova. After removal, a user
reported that they were no longer able to read IPs from access_ip_v4
and access_ip_v6 on Rackspace. It's possible that Rackspace sets
the AccessIPv* attributes, and if that's true, other cloud providers
might as well through custom extensions.
The priority of how access_ip_v* is set might require some tweaks in
the future.
This commit allows "detaching" to be a valid pending state when
detaching a volume. Despite being obvious pending state, it also
helps in race situations when a volume is implicitly being detached
by Nova.
This commit fixes and cleans up instance block_device configuration.
Reverts #5354 in that `volume_size` is only required in certain
block_device configuration combinations. Therefore, the actual
attribute must be set to Optional and later checks done.
Doc upates, too.
This commit adds the ability to create instances with multiple
ephemeral disks. The ephemeral disks will appear as local block
devices to the instance.
The `volume_size` of a `block_device` was originally set to Optional,
but it's a required parameter in the OpenStack/Nova API. While it's
possible to infer a default size of the block device, making it required
more closely matches the Nova CLI client as well as provides consistent
experience when working with multiple block_devices.
Official OpenStack clients support specifing custom CA certificate file
that should be used when communicating with OpenStack server. This patch
adds similar behavior to Terraform OpenStack provider, by:
- Using OS_CACERT environmental variable, if available
- Using cacert_file provider parameter, if configured
This commit adds the ability to associate a Floating IP to a specific
network. Previously, there only existed a top-level floating IP
attribute which was automatically associated with either the first
defined network or the default network (when no network block was
used).
Now floating IPs can be associated with networks beyond the first
defined network as well as each network being able to have their own
floating IP.
Specifying the floating IP by using the top-level floating_ip
attribute and the per-network floating IP attribute is not possible.
Additionally, an `access_network` attribute has been added in order
to easily specify which network should be used for provisioning.
Kirill Shirinkin