Skip to main content

Upgrading a Validator

How to perform an upgrade on a validator

Helm Chart details:​

Dynamic YAML Badge

validator: A Helm chart for deploying Chronicle Validator on Kubernetes

— Open in Artifact Hub

TL;DR​

If you are upgrading from 0.3.x to 0.3.y, simply updating the chart version will suffice:

ssh <SERVER_IP>
su - <FEED_USERNAME>
export FEED_NAME=my-feed
helm repo update
helm upgrade $FEED_NAME -n $FEED_NAME -f $HOME/$FEED_NAME/generated-values.yaml chronicle/validator --version 0.3.4
danger

If upgrading from 0.2.x to 0.3.x, please read below!

Upgrading from 0.2.x to 0.3.x​

warning

Please be aware that the latest helm chart has been renamed from feed to validator. Please use the upgrade.sh script to upgrade your validator to the latest version. This version embeds musig into the ghost pod. The upgrader script will clean up the generated values.yaml file and remove the unecessary musig values.

In order to upgrade a validator to the latest version, we will need to run a couple helm commands.

Upgrade Helper Script​

To simplify the upgrade process, we have created a helper script that will upgrade your validator to the latest version.

This script will attempt to run helm upgrade <feedname> -n <feedname> chronicle/validator on your feed release, with any updated input variables.

caution

Please use the correct FEED_NAME, which should be the same as your helm release name, if deployed using the install.sh script previously

ssh <SERVER_IP>
su - <FEED_USERNAME>
export FEED_NAME=my-feed
wget -N https://raw.githubusercontent.com/chronicleprotocol/scripts/main/feeds/k3s-install/upgrade.sh
chmod a+x upgrade.sh
./upgrade.sh
You can set the expected variables in the .env file, or export them as environment variables. If the script fails to find any of these values, it will prompt you for them when running the script.

Manual process TL;DR​

ssh <SERVER_IP>
su - <FEED_USERNAME>
export FEED_NAME=my-feed
helm repo update
helm upgrade $FEED_NAME -n $FEED_NAME -f $HOME/$FEED_NAME/generated-values.yaml chronicle/validator
caution

Please use the correct FEED_USERNAME, and FEED_NAME according to your installation

Helm Upgrade Process​

First, ssh on to your server:

ssh <SERVER_IP>

Once you're on the host, make sure your you switch to the `user` that the feeds were installed with

Eg; assuming your user name is feed-user :

$ su - feed-user
feed-user@my_feed_host:~$

Verify that your user can view the k3s cluster resources (eg below assuming the feed is named is my-feed:

export FEED_NAME=my-feed
helm list -n $FEED_NAME
NAME     NAMESPACE    	REVISION	UPDATED                                	STATUS  	CHART     	APP VERSION
my-feed	 my-feed	10      	2023-10-12 08:22:16.725518367 +0000 UTC	deployed	feed-0.2.9	2.0.0

If kubectl/helm commands fail, please ensure you have $KUBECONFIG set correctly. Take a look here for more detail

Prepare values.yaml​

The values.yaml file is used to configure the validator. The file is generated by the install script, and should be updated to reflect the latest version of the feed chart.

With the latest version of the chart, the generated-values.yaml, there are a few changes that need to be made to the values.yaml file:

example values.yaml file:

ghost:
  ethConfig:
    ethFrom:
      existingSecret: 'demo-eth-keys'
      key: "ethFrom"
    ethKeys:
      existingSecret: 'demo-eth-keys'
      key: "ethKeyStore"
    ethPass:
      existingSecret: 'demo-eth-keys'
      key: "ethPass"

  env:
    normal:
      CFG_LIBP2P_EXTERNAL_ADDR: '/ip4/64.46.13.31'
      CFG_WEB_URL: "myuniquetoronionaddress.onion"

  ethRpcUrl: "https://MY_L1_RPC_URL"
  rpcUrl: "https://MY_L1_RPC_URL"

danger

Please ensure your values yaml file is updated to reflect the latest requirements for the validator chart, with the correct values for secrets for ethConfig, ethRpcUrl and rpcUrl.

Notable changes include:​

  • musig is now embedded in the ghost deployment, and all .Values.musig can be removed from the values.yaml file
  • Please remove .Values.ghost.env.CFG_WEB_URL from your values, as this will be dynamically referenced in the Ghost deployment spec.
  • Starting from Chart Version 0.3.4, tor is deployed using the tor-controller operator, which installs some custom resource definitions. The controller will create a new onion key, which will be persisted as a secret. Please delete your previous secrets containing the tor keys, as they won't be needed. Retrieve the Ghost onion address using kubectl get onion -n <namespace> and notify the Chronicle team of your ETH address and the new Ghost onion address.

Update helm repo​

We need to fetch the latest helm chart from the registry:

helm repo update

Run helm upgrade​

Now we can update to the latest version.

The latest chart version is: Dynamic YAML Badge

using this version, we can upgrade our validator:

danger

Please ensure you pin the helm release to the lastest semver ChartVersion of the feed chart. eg 0.3.4 The charts released are production ready, and tested thoroughly

helm upgrade $FEED_NAME -n $FEED_NAME -f $FEED_NAME/generated-values.yaml chronicle/validator --version 0.3.4

You should see output like this:

Release "my-feed" has been upgraded. Happy Helming!
NAME: my-feed
LAST DEPLOYED: Thu Oct 12 08:21:03 2023
NAMESPACE: my-feed
STATUS: deployed
REVISION: 9
NOTES:
1. Get the application URL by running these commands:
  kubectl get pods -n my-feed

Verify the helm release and version​

Verify the chart version has changed and matches what the latest feed version:

helm list -n $FEED_NAME
NAME     	NAMESPACE	REVISION	UPDATED                                	STATUS  	CHART          	APP VERSION
validator	validator	3       	2024-04-30 18:49:58.843309576 +0000 UTC	deployed	validator-0.3.4	0.37.2

View all resources created in the namespace​

kubectl  get pods,deployment,service,secrets,onion -n demo
NAME                                   READY   STATUS    RESTARTS   AGE
pod/ghost-tor-daemon-b77466d7f-flnm7   1/1     Running   0          4m28s
pod/ghost-77b46586d5-fdcgm             1/1     Running   0          4m29s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ghost-tor-daemon   1/1     1            1           4m28s
deployment.apps/ghost              1/1     1            1           4m30s

NAME                            TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                                        AGE
service/ghost-tor-svc           ClusterIP      10.43.197.59   <none>           8888/TCP                                       4m28s
service/ghost-tor-metrics-svc   ClusterIP      10.43.85.148   <none>           9035/TCP                                       4m28s
service/ghost                   LoadBalancer   10.43.21.41    64.46.13.31      8000:31359/TCP,9100:32481/TCP,8080:30963/TCP   4m30s

NAME                                TYPE                                           DATA   AGE
secret/demo-eth-keys                Opaque                                         3      5m2s
secret/ghost-tor-auth               tor.k8s.torproject.org/authorized-clients-v3   0      4m29s
secret/ghost-tor-secret             tor.k8s.torproject.org/onion-v3                5      4m29s
secret/sh.helm.release.v1.demo.v1   helm.sh/release.v1                             1      4m30s

NAME                                        HOSTNAME                                                         AGE
onionservice.tor.k8s.torproject.org/ghost   areallylongonaddressescreatedformebythetorcontrollercrd.onion    4m30s

View pod logs:​

kubectl logs -n demo deployment/ghost
kubectl logs -n demo deployment/ghost-tor-daemon

and you're done!

warning

If you encounter any issues please refer to the Trouble Shooting docs