Component scripts

[jeff-mccoy]

For my work on #16 I've run into some issues with the lifecycle of installing K3s (also see #17) and how the package deploy code works. The cleanest way to solve this is to move the k3s installer stages out of the codebase and into the zarf.yaml as well, this way I can keep the business logic inline during the component deployment. Basically it would function like this:

• the required components (k3s in this case) would deploy first
• there would be a "scripts" "finalizer" "executables" or similar key for that component that would run at the end
• other component would wait for those scripts to finish before installing

My question is around 1. What should we call that key? 2. What should the format look like for the scripts? These will be passed to utils.ExecCommand().

or more explicitly:

[RothAndrew]

I like this a lot. It's definitely more transparent as to what is happening, rather than doing everything under the hood.

I like the syntax of the first way better.

I would try to find a way to have the word after be part of the yaml key, since they run after the deployment of the component.

[RothAndrew]

Assuming the "first way" syntax, do you know if multiline string will be supported for free, or will we need to do more work to get that?

Example:

script: |
  echo "foo"
  echo "bar"
  echo "baz"

[RothAndrew]

other component would wait for those scripts to finish before installing

Would want it to wait for them to finish successfully before moving on, and fatal if they returned an exit code of anything but 0

[jeff-mccoy]

thanks those are all good points, I like the idea of communicating these are required scripts that run at the end of the component deployment. Def. agree they should just be fatal if non-zero, they can always tweak the output if they want to make it a soft failure. I think multiline will be a little tricky, but I'm not totally sure as I haven't played with the yaml parsing library for that yet. I do personally feel that multiline can be confusing for ppl and has it's own set of dragons.

[jeff-mccoy]

We could do something like "postInstall", "finalizer", "completionScript", 🦄 ?

[jeff-mccoy]

I like that format a lot, but what about commands vs args? Worried about parsing errors if we just try to do it on whitespace.

[jeff-mccoy]

And we use deploy vs install for terminology elsewhere in zarf, thoughts?

[RothAndrew]

I like that format a lot, but what about commands vs args? Worried about parsing errors if we just try to do it on whitespace.

From a user experience standpoint, I hate having to separate out commands and args into different arrays. It's super annoying. I'd much rather just pass a string that gets run just like I can on the terminal.

If there's a technical limitation there though that I'm not aware of, then commands vs args in different arrays still works, I just really dislike it.

And we use deploy vs install for terminology elsewhere in zarf, thoughts?

postDeploy preDeploy 👍

[jeff-mccoy]

Yeah I can play with it, I supposed I could just split on the first whitespace, just worried me a little that could be brittle. The alternative is we could pipe the whole string into a shell eg: “sh -c ‘commands’”

[jeff-mccoy]

There have been a couple times I’ve seen that necessary in go execs

[jeff-mccoy]

This is now WIP as a part of the native apply stuff: 56adb74. Pre/post were easy to implement.