This commit adds further work to the OpenStack port resource:
* Makes relevant fields computed
* Adds state change functions
* Adds acceptance tests
* Adds Documentation
This commit cleans up areas that configure the image_id and image_name.
It enables the ability to not have to specify an image_id or image_name
when booting from a volume.
It also prevents Terraform from reporting an error when an image name is no
longer able to be resolved from an image ID. This usually happens when the
image has been deleted, but there are still running instances that were based
off of it.
The image_id and image_name parameters no longer immediately take a default
value from the OS_IMAGE_ID and OS_IMAGE_NAME environment variables. If no other
resolution of an image_id or image_name were found, then these variables will
be referenced. This further supports booting from a volume.
Finally, documentation was updated to take into account booting from a volume.
This commit cleans up the volume and block device handling in the instance
resource. It also adds more acceptance tests to deal with different workflows
of attaching and detaching a volume through the instance's lifecycle.
No new functionality has been added.
This commit fixes the previously broken "boot from volume" feature. It also
adds an acceptance test to ensure the feature continues to work.
The "delete_on_termination" option was also added.
This commit enables security groups to be deleted in a safe way by
checking their state over a period of time.
This fixes occurrences when the API says the instance is deleted but
it is still in the process of being deleted by OpenStack and thus the
security group returns an error saying that there are still instances
attached to the group.
When using an image as the source of new volume the state 'downloading'
prior to the state 'available' is fine.
It is also fine to destroy a volume in the state 'downloading'.
Closes-bug: #2865
Co-Authored-By: Joe Topjian <joe@topjian.net>
These two provider options are optional though if they are not set,
the user will be prompted to enter values.
By changing them to use the envDefaultFuncAllowMissing, the values
are still passed in the environment if they are set and safely
discarded if they are not.
This commit converts the openstack compute instances security groups to
a set from a list.
This fixes ordering problems which forces or indicates change to security
groups where none exist, and mimics the functionality in the aws
provider's compute resource.
Includes fixes from dupuy addressing crashes due to an empty state.
This commit follows suit of #1897 by fixing volume-related
parameters which allow the volume attach acceptance test
to work. It also re-enables the volume attach test.
This commit adds a server group resource. Users can create server
groups with different policies. If a server is launched in a certain
group, the server will adhere to that policy. For example, servers
can be made to all launch on the same compute node or different compute
nodes.
This commit resolves an issue where the tenant-network api extension
does not exist. The caveat is that the user must either specify no
networks (single network environment) or can only specify UUIDs for
network configurations.
This commit changes how the network info is read from OpenStack.
It pulls all relevant information from server.Addresses and merges
it with the available information from the networks parameters.
The access_v4, access_v6, and floating IP information is then
determined from the result.
A MAC address parameter is also added since that information is
available in server.Addresses.
This commit allows the user to specify a network by name rather than
just uuid. This is done via the os-tenant-networks api extension.
This works for both neutron and nova-network.
This commit causes the resource to manage floating IPs by way of the
os-floating-ips API.
At the moment, it works with both nova-network and Neutron environments,
but if you use multiple Neutron networks, the network that supports the
floating IP must be listed first.
The `getFirstNetworkID` does not work correctly because the first
network is not always the private network of the instance.
As long as the `GET /networks` gives a list containing also public
networks we don't have any guarantee that the first network is the
one we want. Furthermore, with a loop over the network list we are
not able to determine which network is the one we want.
Instead of retrieving the network ID and then finding the port ID,
it's better to basically take the first port ID of the instance.
Joe Topjian