Error: parse error at (gitlab-agent/templates/observability-secret.yaml:1): unclosed action

Problem

You are trying to install the gitlab kubernetes agent (kas) after getting the installation instructions from the Gitlab registration, but you are getting the following error:

Error: parse error at (gitlab-agent/templates/observability-secret.yaml:1): unclosed action

Solution

This is caused by the helm version used, so upgrading the helm version works with no issues.

 helm version
version.BuildInfo{Version:"v3.5.3", GitCommit:"041ce5a2c17a58be0fcd5f5e16fb3e7e95fea622", GitTreeState:"dirty", GoVersion:"go1.15.8"}

so trying to install gives the previous error.

Changing the helm version (ie with asdf)

asdf global helm 3.70


Checking the version

helm version
version.BuildInfo{Version:"v3.7.0", GitCommit:"eeac83883cb4014fe60267ec6373570374ce770b", GitTreeState:"clean", GoVersion:"go1.16.8"}

And running the helm installation again

helm upgrade --install gitlab-kas-agent gitlab/gitlab-agent \

--namespace gitlab-agent --set image.tag=v15.6.0 \

--set config.token=token_from_gitlab-registration \

--set config.kasAddress=wss://kas.domain_name.tld


Release "gitlab-kas-agent" does not exist. Installing it now.
NAME: gitlab-kas-agent
LAST DEPLOYED: Mon Dec  5 13:38:33 2022
NAMESPACE: gitlab-agent
STATUS: deployed
REVISION: 1

TEST SUITE: None

Restic index invalid data returned error

Problem

It is possible after a broken network connection to get the restic error about invalid data returned for the index (maybe when using check).

Solution

You would need to rebuild the index, but using the –read-all-packs flag as described [here](https://forum.restic.net/t/fatal-load-index-xxxxxxxxx-invalid-data-returned/3596/27) which does the rebuild from scratch

restic rebuild-index -r $REPO --read-all-packs

PostgreSQL connection string for Percona PostgreSQL K8S operator

Since the documentation does not contain any information about how you can connect an existing application to the newly created percona pgo cluster, you can use something like the following in your pod postgresql connection string.

postgresql://username:password@cluster1.pgo-perc-production.svc.cluster.local/production

where cluster1.pgo-perc-production.svc.cluster.local points to your newly created cluster and the /production is the database to connect to.

googlecloudsdk.calliope.exceptions.HttpException: ResponseError: code=400, message=Autopilot clusters must be regional clusters.

Problem

Trying to create an auto-cluster either using terraform or gcloud cli, and specifying the region name returns the error that ‘Autopilot clusters must be regional clusters.

So with gcloud this is the command and output

kosmas: (master %)$ gcloud container clusters create-auto test-cluster --region=europe-west6-b
Note: The Pod address range limits the maximum size of the cluster. Please refer to https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr to learn how to optimize IP address allocation.
ERROR: (gcloud.container.clusters.create-auto) ResponseError: code=400, message=Autopilot clusters must be regional clusters.

Solution

Using the actual region name (that can be taken from the list of available zones/regions)

gcloud compute zones list

NAME                       REGION                   STATUS  NEXT_MAINTENANCE  TURNDOWN_DATE
us-east1-b                 us-east1                 UP
us-east1-c                 us-east1                 UP
...
europe-west6-b             europe-west6             UP
...

And using the correct region name (without the b)

gcloud container clusters create-auto test-cluster --region=europe-west6 --verbosity debug

...
Created [https://container.googleapis.com/v1/projects/gitlab-runner-343714/zones/europe-west6/clusters/test-cluster].
...
NAME          LOCATION      MASTER_VERSION   MASTER_IP     MACHINE_TYPE  NODE_VERSION     NUM_NODES  STATUS
test-cluster  europe-west6  1.21.6-gke.1503  xxx.xxx.xxx.xxx  e2-medium     1.21.6-gke.1503  3          RUNNING

Kubectl using -l a=something -l b=other or -l a=something,b=other

When you have two pods with different labels, let’s say one with two labels a=something and b=other, and the second one with label b=other, when you use kubectl to get them there is a difference in the way that the -l selector is used.

So using kubectl -n namespace get pods -l a=something -l b=other it will give you back both pods as it works as an OR operator.

If you wanted to get only the first one that has both labels, but not the second, you would need to use it as in kubectl -n namespace get pods -l a=something,b=other.

In other words the comma separator acts as a logical AND operator in selecting the labels.

Using exo cli to display your vm templates in Exoscale

To display your vm templates, as opposed to all available templates in Exoscale using the exo CLI, use the following (you should have already the environment variables set up to be able to use exo):

exo vm template list --mine
?????????????????????????????????????????????????????????????????????????????????????????????????????????
?                  ID                  ?     NAME      ?      CREATION DATE       ?  ZONE   ? DISK SIZE ?
?????????????????????????????????????????????????????????????????????????????????????????????????????????
? a58f0180-689d-4663-aa53-91111111111  ? my-ubuntu     ? 2020-08-12T13:44:01+0000 ? ch-dk-2 ? 50 GiB    ?
?????????????????????????????????????????????????????????????????????????????????????????????????????????