Skip to content
Snippets Groups Projects
Unverified Commit e0b24a16 authored by Marco Emilio "sphakka" Poleggi's avatar Marco Emilio "sphakka" Poleggi
Browse files

More instructions for Task #10

parent cdde425d
No related branches found
No related tags found
No related merge requests found
......@@ -862,6 +862,12 @@ The solution might be something like:
``` hcl
resource "terraform_data" "kind_cluster" {
# run only when a given resource processing has terminated
depends_on = [...]
# rerun when something else has changed, e.g., a conf file
triggers_replace = [...]
connection {
type = "ssh"
user = ...
......@@ -880,11 +886,20 @@ resource "terraform_data" "kind_cluster" {
provisioner "remote-exec" {
inline = [
"shell command",
...
# force the script to terminate at the first failure
"set -o errexit",
"other shell command",
...,
# allow background jobs (Docker, kernel, etc.) to terminate
"sleep 30"
]
}
}
resource "terraform_data" "metallb_service" {
# same structure as above
...
}
```
:bulb: Please mind that:
......@@ -896,18 +911,18 @@ can test the creation of the two resources separately.
- Since the lines of a `remote-exec` are merged into a script, it is wise to
start it with the command `set -o errexit`, so that the whole script exits
at the first error.
:warning: You will probably hit some thorny issues:
- Depending on how you code the `terraform_data` block(s), the resource(s)
might get processed too soon or in the wrong order. So, be sure of using
*variable references* so as to induce indirect dependencies. You might also
need to explicitly declare a `depends_on` list.
- Using *variable/resource references* imposes implicit processing of changed
resources. However, to ensure the correct processing flow, some dependencies
should be explicitly imposed via arguments `depends_on` and
`triggers_replace`. Failing to do so might cause the `terraform_data`
resource processing to start before the `app_server` has been finalized.
- Before doing anything, you must wait for Cloud-init to finish its tasks:
this can take several minutes (at least 4-5).
this can take several minutes (at most 4-5). You can probe it with a
remote-exec command `cloud-init status --wait`.
- KinD and K8s are very complex and, during set up, might fail in unexpected
ways, chiefly because of system/network issues. Thus, it is wise to wait a
bit (at least 20-30 seconds) after each `kind/kubectl` command.
bit (at least 20-30 seconds) after each `kind/kubectl` command (use `sleep
...`).
<!--
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment