When the stack infrastructure is up-to-date, you can proceed to the next task for downloading Terraform configuration and state files.
Task 2: Download the Configuration and State 🔗
Note
If the stack's Terraform configuration is stored in a source code control system, such as GitLab, then check out and download the Terraform configuration from there.
If the stack's Terraform configuration is stored in a bucket, then download the Terraform configuration from there.
This task uses the Console. For CLI and API instructions for a step, see the associated link.
On a computer that can run command line tools, create a folder to store the downloaded Terraform configuration and state.
Example folder name: c:\StackUpgrade
In the Console: On the Stacks list page, select the stack that you want to work with. If you need help finding the list page or the stack, see Listing Stacks.
Update the provider configuration to add arguments such as user_ocid, fingerprint and private_key_path. You might have commented out these arguments before.
If a source code control system (such as GitHub) is used for the stack's Terraform configuration, then commit the upgraded Terraform configuration there.
The most recent commit is used when you run jobs on the stack.
If an Object Storage bucket is used for the stack's Terraform configuration, then change the contents of that bucket to correspond with the upgraded Terraform configuration.
Note
Back up the current bucket before changing it to correspond to the upgraded Terraform configuration. Limit the bucket to files that are intended for use with Terraform.
The most recent contents of the bucket are used when you run jobs on the stack.
When the Terraform configuration is successfully upgraded to the target Terraform version, then you can proceed to the next task for upgrading the stack.
Task 4: Upgrade the Stack 🔗
This task uses the Console. For CLI and API instructions for updating a stack, see Updating a Stack.
In the Console, reopen the details page for the stack that you're upgrading: On the Stacks list page, select the stack that you want to work with. If you need help finding the list page or the stack, see Listing Stacks.
From the Actions menu () for the stack, select Edit.
You can either drag the file onto the dialog's control or select Browse and navigate to the location of the file or folder.
Example file path: c:\StackUpgrade\MyConfigUpgraded.zip
The dialog box is populated with information contained in the Terraform configuration.
Note
Skip this uploading step if the stack's Terraform configuration is stored in a source code control system (such as GitHub) or in an Object Storage bucket, then the stack was configured to use the upgraded Terraform configuration in Task 3: Upgrade the Configuration when you committed the change to source code or uploaded the file to the bucket.)
Specify the target Terraform version: Change the Terraform version.
Select Next twice, then select Save changes.
The stack is now synchronized with the upgraded Terraform configuration and specified Terraform version. You can now proceed to the next task for importing the state file.
In the Console, reopen the details page for the stack that you're upgrading: On the Stacks list page, select the stack that you want to work with. If you need help finding the list page or the stack, see Listing Stacks.
Go to More actions and select Import state.
In the Import panel, add the downloaded Terraform state file.
You can either drag the file onto the dialog's control or select Browse and navigate to the location of the file or folder.
Example file path: c:\StackUpgrade\terraform.tfstate
Select Import.
The import job is created. The new job is listed under Jobs.
When the job finishes, the Job details page opens.
On the details page for the stack, select Edit, then upload the newly updated Terraform configuration to the stack.
You can either drag the file onto the dialog's control or select Browse and navigate to the location of the file or folder.
Example file path: c:\StackUpgrade\MyConfigUpgraded.zip
The dialog box is populated with information contained in the Terraform configuration.
Note
Skip this uploading step if the stack's Terraform configuration is stored in a source code control system (such as GitHub) or in an Object Storage bucket, then the stack was configured to use the upgraded Terraform configuration in Task 3: Upgrade the Configuration when you committed the change to source code or uploaded the file to the bucket.)
Select Next twice, then select Save changes.
Run the plan action again to confirm that the issues are no longer listed in the associated log contents.
Select Plan.
When the action finishes, the details page for the related job opens.
Following are some issues you might see in logs while upgrading a stack to a new Terraform version. This list is limited to a few issues that the Resource Manager service team knows about.
Error: Failed to install providers 🔗
The log shows an error message similar to the following.
Error: Failed to install providers
Could not find required providers, but found possible alternatives:
hashicorp/gitlab -> gitlabhq/gitlab
If these suggestions look correct, upgrade your configuration with the following command:
terraform 0.13upgrade .
The configuration doesn't meet requirements for the specified Terraform version. Version 0.13.x and later don't use this syntax for providers. Example configuration causing this error:
provider "gitlab" {
token = "glpat-_abcd"
}
# Add a project owned by the user
resource "gitlab_project" "sample_project" {
name = "example"
}
Add a required_providers block and explicitly mention the source information for the provider. For more information, see Requiring Providers. Example update:
The log shows an error message similar to the following.
Error: Invalid quoted type constraints on variables.tf line 18, in variable "vcn_dns_label"
18: type = "string"
Terraform 0.11 and earlier required type constraints to be given in quotes,
but that form is now deprecated and will be removed in a future version of
Terraform. Remove the quotes around "string".
The configuration doesn't meet requirements for the specified Terraform version. Version 1.0.x and later don't use quotes for type declarations of variables. Example configuration causing this error:
variable "vcn_dns_label" {
type = "string"
default = "vcn"
}
Remove the quotes from type declarations of variables. Example update:
variable "vcn_dns_label" {
type = string
default = "vcn"
}
Error: Error in function call (map) 🔗
The log shows an error message similar to the following.
Error: Error in function call
on main.tf line 44, in resource "oci_core_subnet" "this":
44: display_name = lookup(map("a", "b", "c", "d"), "a", "default")
────────────────
while calling map(vals...)
Call to function "map" failed: the "map" function was deprecated in Terraform v0.12 and
is no longer available; use tomap({ ... }) syntax to write a literal map.
The configuration doesn't meet requirements for the specified Terraform version. Version 1.0.x and later don't use this syntax for maps. Example configuration causing this error:
The log shows an error message similar to the following.
Error: Error in function call
on main.tf line 35, in resource "oci_core_subnet" "this"
35: count = length(list("phx-ad-1"", ""phx-ad-2"))
Call to function "list"" failed: the ""list" function was deprecated in
Terraform v0.12 and is no longer available; use tolist([ ... ]) syntax to
write a literal list.
The configuration doesn't meet requirements for the specified Terraform version. Version 1.0.x and later don't use this syntax for lists. Example configuration causing this error:
Error: The ["*"] form of ignore_changes wildcard is deprecated 🔗
The log shows an error message similar to the following.
Getting providers from registry and/or custom terraform providers
resource "oci_core_subnet" "this"
44: ignore_changes = ["*"]
The ["*"] form of ignore_changes wildcard is was deprecated and is now
invalid. Use "ignore_changes = all" to ignore changes to all attributes.
The configuration doesn't meet requirements for the specified Terraform version. Version 1.0.x and later don't use this syntax for ignore_changes wildcards. Example configuration causing this error: