Add repo & env var inputs to kubevirt-talos template

[hh]

When creating a new instance in pair we can provide repositories and environment vars.

• https://pair.sharing.io/instances/new

This should allow us to expose more features from our pair image to the coder workspace cluster/pod.

[BobyMCbobs]

To clarify, is this referring to the automated cloning of repositories upon instance creation?

[hh]

Yes, and the env vars we set in the environment pod.

…

On Wed, 7 Dec 2022 at 5:22 PM, Caleb Woodbine ***@***.***> wrote: To clarify, is this referring to the automated cloning of repositories upon instance creation? — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHUYYBFY5OQHY2F37ZMUDWMEL5BANCNFSM6AAAAAASWYEEGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[hh]

In pair webui at https://pair.sharing.io/instances/new we can input a list of repos:

This gets populated to the environment StatefulSet in .sharing.io/cluster-api/manifests/environment.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: environment
spec:
  template:
    spec:
      containers:
        - command:
            - pair-init.sh
          env:
            - name: INIT_DEFAULT_REPOS
              value: "${SHARINGIO_PAIR_INSTANCE_SETUP_REPOS}"

INIT_DEFAULT_REPOS is used by the environment pod via pair-init.sh to check out the repos.

# Clone all projects
(
    if [ -n "$INIT_DEFAULT_REPOS" ]; then
        mkdir -p "${INIT_DEFAULT_REPOS_FOLDER}"
        for repo in ${INIT_DEFAULT_REPOS}; do
            if [ "$PROJECT_CLONE_STRUCTURE" = "structured" ]; then
                git-clone-structured "$repo" || true
            elif [ "$PROJECT_CLONE_STRUCTURE" = "plain" ]; then
                git clone -v --recursive "$repo" || true
            fi
        done
    fi
    cd
    eval "$INIT_PREFINISH_BLOCK"
)

Please add a coder_parameter to the kubevirt-talos template allowing INIT_DEFAULT_REPOS to be set during creation.

[hh]

In pair webui at https://pair.sharing.io/instances/new we can input a list of environment vars:

This form is created by https://github.com/sharingio/pair/blob/aab8af9f0447e1b0725f9f348a8abb4f1467cb24/apps/client/src/client/views.clj#L164-L167:

   [:div.form-group
    [:label {:form "envvars"} "Environment Variables"]
    [:textarea {:name "envvars"
                :id "envvars"
                :placeholder "PAIR=sharing\nSHARE=pairing"}]
    [:p.helper "Add env vars as KEY=value, with each new variable on its own line."]]

Processed by packet.clj#text->env-map which is called by launch() when creating an instance spec as :env:

        instance-spec {:type type
                       :facility facility
                       :name name
                       :kubernetesNodeCount (Integer. (or kubernetesNodeCount 0))
                       :setup {:user username
                               :guests (if (empty? guests)
                                         [ ]
                                         (clojure.string/split guests #" "))
                               :githubOAuthToken (if (empty? noGitHubToken) "" token)
                               :env (if (empty? envvars) [] (text->env-map envvars))
                               :timezone timezone
                               :repos (if (empty? repos)
                                        [ ]
                                        (clojure.string/split repos #" "))
                               :fullname fullname
                               :email email
                               :extraEmails emails}}

Currently this may get written to /root/.sharing-io-pair-init.env
via KubernetesTemplateResources()

However it's fine to just add these directly to the environment Stateful itself similar to the * INIT_DEFAULT_REPOS* above.

[hh]

We should be able to process the new coder_parameters into a terraform templated version of the environment StatefulSet.

[BobyMCbobs]

check out #14

[hh]

We should loop back to ENV vars as well: #12 (comment)

It'll be very similar.

[BobyMCbobs]

We should loop back to ENV vars as well: #12 (comment)

It'll be very similar.

@hh, it is unclear to me why the two topics are grouped together.

The way that Pair has performed the templating in the past (through bash variables) is simply not possible with the way that Terraform works. I am currently unsure how the dynamic assigning of environment various could be done

[hh]

Both options need us to set env vars for the pod.
It's templating within terraform. Here is a working example:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: environment
spec:
  template:
    spec:
      containers:
        - command:
            - pair-init.sh
          env:
            %{for v in split(" ",env_vars)}
            - name: "${split("=",v)[0]}"
              value: "${split("=",v)[1]}"%{ endfor}

echo 'templatefile("${path.module}/env_t.yaml", { env_vars = "FOO=bar BAZ=boo"})' | terraform console

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: environment
spec:
  template:
    spec:
      containers:
        - command:
            - pair-init.sh
          env:
            
            - name: "FOO"
              value: "bar"
            - name: "BAZ"
              value: "boo"

[hh]

Bringing in the vars as a terraform variable, but you can do the same with coder_input:

variable "env_vars" {
  description = "A list of FOO=BAR style shell env"
  default     = "FOO=BAR BIP=BOP"
}

echo 'split("=",var.env_vars)' | terraform console

tolist([
  "FOO",
  "BAR BIP",
  "BOP",
])