This section is applicable only if you are self-hosting the control-plane. In case Truefoundry is hosting the control-plane, all upgrades are managed by Truefoundry automatically.
Truefoundry control-plane is usually released twice a week to our hosted control-plane. Releases for self-hosted control-plane are usually a week behind our managed saas control-plane. All the releases can be found in our Changelog page.Each version is tagged with a version number and date. It also contains the instructions to upgrade the control-plane.
Release Changelog
In case there is any breaking chnage or the values.yaml of the control-plane helm chart needs to change, it will be clearly mentioned in the changelog.
Truefoundry team can also help you in the upgrade process. We can come on a screen share and be available during the upgrade. We usually recommend upgrading the control-plane atleast once a month to keep it up to date.
The control-plane is compatible with older versions of the compute-plane unless mentioned in the changelog. We do however have a recommended version of the different components of the compute-plane that you should try to maintain since that is the most tested configuration that we maintain. You can track the dependencies here: https://releases.truefoundry.com/control-plane-versionsThis will highlight the versions of ArgoCD, GPU Operator, and other addons that the control-plane version is tested with.
The control-plane chart has a dependency on the gateway-plane chart. Every control-plane version is compatible with the gateway plane that is part of the control-plane chart. You can find the gateway-plane version in the control-plane Chart.yaml file.
Control-plane newer versions are compatible with older versions of the gateway-plane unless mentioned in the changelog. However, newer features in the control-plane might not be available in the older gateway-plane versions.
Migrating to tfy-proxy
The migration can be done based on what type of routing configuration you have
Istio: Virtual Service
ALB Ingress
Nginx Ingress
Migrating from frontendapp managed virtual service to the new proxy service, has to be done in multiple phases to ensure minimal downtime.
1
Enable tfy-proxy service
Migrating from frontendapp managed virtual service to the new proxy service, has to be done in multiple phases to ensure minimal downtime.
The first step is to deploy the proxy service and it’s associated services are running and healthy.
From the UI navigate to the helm section under deployments and search for truefoundry. Click on edit and navigate to the values section
Enable the tfyProxy in the truefoundry chart by adding the following
Copy
Ask AI
tfyProxy: enabled: true
Confirm that the service is running, you should see a pods with tfy-proxysuffix running or you can check from the cluster;
Copy
Ask AI
kubectl get pods -n <namespace> | grep tfy-proxy
2
Enable Global Virtualservice
Enable the global virtual service which will replace the frontendapp virtualservice by updating the following;
Copy
Ask AI
global: proxy: enabled: true virtualservice: enabled: true # update the gateway that your virtualservice will connect to e.g `istio-system/tfy-wildcard` # ideally, this will be gotten from `truefoundryFrontendApp.istio.virtualservice.gateways` gateways: - istio-system/tfy-wildcard # also update your host here from Values.truefoundryFrontendApp.istio.virtualservice.hosts hosts: []
After the virtualservice has been created, you can now now disable the frontend virtualservice
Test your endpoint to ensure it is still reachable, after your test are done, you can disable frontendapp altogether by replacing the entire truefoundryFrontendApp section with this;
Copy
Ask AI
truefoundryFrontendApp: enabled: false
1
From the UI navigate to the helm section under deployments and search for truefoundry. Click on edit and navigate to the values section
2
Enable tfy-proxy
Enable the tfyProxy in the truefoundry chart by adding the following;
Copy
Ask AI
tfyProxy: enabled: true
Confirm that the service is running, you should see a pods with tfy-proxy suffix running or you can check from the cluster;
This will create another loadbalancer in aws, update the A record of the dns to the new loadbalancer created.
4
Test your endpoint to ensure it is still reachable
5
After your tests are done, you can disable frontendapp altogether by replacing the entire truefoundryFrontendApp section with this
Copy
Ask AI
truefoundryFrontendApp: enabled: false
Nginx ingress controller doesn’t allow multiple ingresses with the same host and path to exist simultaneously due to that you won’t be able to run the former frontendapp ingress and the new global ingress at the same time this switch might cause a bit of downtime.
1
From the UI navigate to the helm section under deployments and search for truefoundry. Click on edit and navigate to the values section
2
The migration is to be done in one sync to avoid conflicts between two Ingress objects with the same host.
Copy
Ask AI
global: ingress: enabled: true ingressClassName: <your-ingress-class> # Copy from: truefoundryFrontendApp.ingress.hosts hosts: - <your-host> # Copy from: truefoundryFrontendApp.ingress.tls (if TLS is used) tls: {} proxy: enabled: true # disable only the frontend ingress for now truefoundryFrontendApp: ingress: enabled: false
3
Test your endpoint to ensure it is still reachable.
4
After your tests are done, you can disable frontendapp altogether by replacing the entire truefoundryFrontendApp section with this
