cc_staff
44
edits
Terraform: Difference between revisions
m
Fixing em-dashes
(Fixed images) |
m (Fixing em-dashes) |
||
| Line 253: | Line 253: | ||
It will not. Terraform has no knowledge of resources already defined in the project and does not attempt to determine existing state. (There is nascent functionality in Terraform to handle this but it is incomplete and varies widely from provider to provider. Support in OpenStack is very limited.) Terraform bases its actions on the given configuration and previously determined state relevant to that configuration. Any existing resources are not represented in either and are invisible to Terraform. | It will not. Terraform has no knowledge of resources already defined in the project and does not attempt to determine existing state. (There is nascent functionality in Terraform to handle this but it is incomplete and varies widely from provider to provider. Support in OpenStack is very limited.) Terraform bases its actions on the given configuration and previously determined state relevant to that configuration. Any existing resources are not represented in either and are invisible to Terraform. | ||
It is possible to pull existing OpenStack resources into Terraform but [https://dleske.gitlab.io/posts/terraform-import-manually/ it is not a trivial amount of work] and way outside the scope of this tutorial. The important thing here is that any existing resources in your OpenStack project are safe from inadvertent mangling from | It is possible to pull existing OpenStack resources into Terraform but [https://dleske.gitlab.io/posts/terraform-import-manually/ it is not a trivial amount of work] and way outside the scope of this tutorial. The important thing here is that any existing resources in your OpenStack project are safe from inadvertent mangling from Terraform—but just to be on the safe side, why don’t you make sure you read the output plans carefully? :) | ||
=== Applying the configuration === | === Applying the configuration === | ||
| Line 438: | Line 438: | ||
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source> | Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source> | ||
Yay. So now I have a floating IP | Yay. So now I have a floating IP allocate—but I haven’t associated it to anything, is it just sort of dangling there? No, it’s allocated to the project now, and Terraform knows about it, so when we add the next piece, even though we aren’t creating either resource, we are creating an association between the compute instance and floating IP. | ||
That looks like the following. We’re introducing something new here: | That looks like the following. We’re introducing something new here: | ||
| Line 525: | Line 525: | ||
delete_on_termination = true | delete_on_termination = true | ||
}</source> | }</source> | ||
The <code>uuid</code> attribute is actually the UUID of the image we want to use. This is just moved from the resource definition where it already resided and given a different name (instead of <code>image_id</code>). The other attributes are self-explanatory, except for <code>destination_type</code>, which is here set to <code>volume</code> to indicate this is to be stored with an OpenStack-provided volume rather than using disk on the hypervisor. <code>delete_on_termination</code> is | The <code>uuid</code> attribute is actually the UUID of the image we want to use. This is just moved from the resource definition where it already resided and given a different name (instead of <code>image_id</code>). The other attributes are self-explanatory, except for <code>destination_type</code>, which is here set to <code>volume</code> to indicate this is to be stored with an OpenStack-provided volume rather than using disk on the hypervisor. <code>delete_on_termination</code> is important—for testing, you will probably want this to be <code>true</code> so you don’t have to remember to constantly clean up leftover volumes, but for real use you should consider setting it to <code>false</code> as a last defence against accidental deletion of resources. | ||
<blockquote>Do ''not'' leave the <code>image_id</code> attribute defined in the outer compute instance definition! This will work, but Terraform will see a change from “boot from volume” to “boot directly from image” on every run, and so will always attempt to rebuild your instance. (This is probably a flaw in the OpenStack provider.) | <blockquote>Do ''not'' leave the <code>image_id</code> attribute defined in the outer compute instance definition! This will work, but Terraform will see a change from “boot from volume” to “boot directly from image” on every run, and so will always attempt to rebuild your instance. (This is probably a flaw in the OpenStack provider.) | ||