Task status, heavy write fix and aws ips

[0x2b3bfa0]

• Closes task status field is not consistent enough #319; see #318 for an explanation of the ExecStart=- syntax.
• closes task Write and Read to S3 is heavy #321 with (guess it) pure bash
• closes task tfstate shows all the ips from other tasks #297 with b7520b0 unless proven otherwise.
• partially fixes task creation does not complete #330

[DavidGOrtega]

I would put all that logic inside tpi stop. That would examine the logs and determine if we are OK, failed, etc...

[0x2b3bfa0]

Tests

terraform {
  required_providers {
    iterative = {
      source = "github.com/iterative/iterative"
    }
  }
}

provider "iterative" {}

resource "iterative_task" "succeeded" {
  name  = "succeeded"
  cloud = "aws"
  script = "#!/bin/sh\nexit 0"
}

resource "iterative_task" "failed" {
  name  = "failed"
  cloud = "aws"
  script = "#!/bin/sh\nexit 1"
}

resource "iterative_task" "running" {
  name  = "running"
  cloud = "aws"
  script = "#!/bin/sh\nsleep infinity"
}

Results

$ terraform show

# iterative_task.succeeded:
resource "iterative_task" "succeeded" {
    ···
    status          = {
        "running"   = 0
        "succeeded" = 1
    }
}

# iterative_task.failed:
resource "iterative_task" "failed" {
    ···
    status          = {
        "failed"  = 1
        "running" = 0
    }
}

# iterative_task.running:
resource "iterative_task" "running" {
    ···
    status          = {
        "running" = 1
    }
}

[DavidGOrtega]

@0x2b3bfa0 running == 1 is during the whole cycle? I mean... when it starts but not yet running the user's code is running==1?

[0x2b3bfa0]

Yes, running is about the machine, not about the script. We assume that a running machine will eventually run the user script.

[DavidGOrtega]

Sounds good. A nitpick would be that I prefer one status vs a composed status... but both are equivalent to some extend

[DavidGOrtega]

Fast nitpicks while finishing review

[DavidGOrtega]

success sounds better and a more widely used word in APIs

[0x2b3bfa0]

Tell that to Kubernetes developers. 😈 I'm being a bit facetious, of course, and agree that succeeded sounds a bit strange, but it's probably the only grammatically consistent option for that term. 😅

🔔 @casperdcl and your dictionary of synonyms.

[DavidGOrtega]

but it's probably the only grammatically consistent option for that term.

Also success

[0x2b3bfa0]

I prefer one status vs a composed status

How would that “one status” look like? Sounds interesting.

[DavidGOrtega]

I prefer one status vs a composed status

How would that “one status” look like? Sounds interesting.

We have already design this previously. As stated in #319
running, terminated, failed and migrating... something like that we defined

It could even be codes like HTTP status codes... so extensible, more at least than two booleans

[DavidGOrtega]

• opens task Chosen design is enforced to repeat same code for every vendor #356
• opens task code field in status #357