Playing catch up with Grafana versions, (Kubernetes v1.16.15 clusters)
Currently running in PRODUCTION is very out of date (v4)
I'm only upgrading now, and refactoring all my configs for the "new" provisioning.
Should I just upgrade to v5 and release in PROD, and then incrementally upgrade again to v6?
or skip v5 just straight to v7?
According to the official docs there are some functions/solutions that went deprecated from one version to another. You should take a look when upgrading to make sure that you are ready for it.
Other than that, there are two ways to get your Grafana to v7:
Step by step upgrade:
Backup Database
Backup Grafana configuration file (i.e grafana.ini)
Perform the update/upgrade depending on the chosen method.
If that won't work, you can also do a fresh install on top of an existing one or remove the current version, install the latest one and than check grafana.ini file.
If you choose the 1st option than please notice that it is considered safer to upgrade one major version at the time. Also, the database/configuration backup is always recommended.
EDIT:
If you are using Grafana Community Kubernetes Helm Charts than notice that Upgrading an existing Release to a new major version requires the Helm v3 (>= 3.1.0) starting from Grafana v6.0.0.
Thanks #Wytrzymały Wiktor
I'm taking the "safe route" upgrading v4->v5 first. New functions and configuration change impacts are too great (as I said system is very out of date!)
Re-factoring all my helm charts, and getting old dashboards re-imported to v5 DB,and backing up everything as you advise.
v5 will be released to PROD users, and then will start looking at v6 upgrade soon after.
Related
I am newly hired engineer who started working with istio recently. My application is currently running on istio 1.4.3 and having issues when i tried to upgrade to latest using istioctl upgrade.
Below are the steps i tried
1) Verified the versions using istioctl version and saw that control plane and data plane are running on 1.4.3 whereas client version is 1.5.1 (the version i planned to upgrade).
2) Tried istioctl upgrade and seen a message “cannot upgrade because of mismatch of versions in istio components”.
3) As it was my dev environment, i decided to reinstall using istioctl manifest apply --profile default
4) Above step cost me a lot of time, because i lost all the settings related to ingress gateway connected to AWS ALB, instead ingress controller created a classic load balancer which is not part of our previous set-up.
5) I also lost setting related to prometheus, grafana, kiali.
6) Now i am planning upgrade my prod without messing the current settings, please suggest a correct way to upgrade istio to latest version with zero downtime.
what is the best way to do this upgrade, can you point out any link to documentation apart from what is mentioned in istio website ? Help is much appreciated
can you point out any link to documentation apart from what is mentioned in istio website
https://istio.io has the most comprehensive information on the topic.
There are some prerequisites for the Istio upgrade as well.
- Istio version 1.4.4 or higher is installed.
- Your Istio installation was installed using istioctl.
It looks like your Istio version is a tiny step below minimum supported one :)
what is the best way to do this upgrade,
Usually it is recommended to go 1.4 --> 1.5 and only then 1.5 --> 1.6.
I have found the following document that describes an "experimental feature, which is intended for evaluation purposes only".
But the minimal version for it is 1.3.3 or higher, which might do the trick for you.
I hope that helps.
We're running an older version of artifactory in a kubernetes cluster that uses the postgresql database chart included with artifactory. The chart 7.18.3 was used to standup the artifactory instance. With the latest vulnerabilities report, we decided to upgrade our artifactory to the latest version. It was recommended to step up through the various revisions to make sure that the postgresql gets the necessary changes to go to the latest version. So I decided to upgrade to the 8.4.7 chart before upgrading to the 9.2.9 chart. I've read the README included with the charts and made sure that my database was ready for the upgrade. I didn't pass in a password for the database when I initially setup the artifactory instance so I pulled the existing password before upgrading. I then perform the upgrade as directed by the readme with the flags --set databaseUpgradeReady=yes and --set postgresql.postgresqlPassword=${POSTGRES_PASSWORD}. I'm getting a 404 error after the upgrade:
Message /artifactory/webapp/
Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
One thing that I noticed is that prior to the upgrade there is only one artifactory-postgresql service and after the upgrade I have two postgresql services: artifactory-postgresql and artifactory-postgresql-headless.Digging into it, the headless service is created when a clusterIP is not passed in, but I haven't seen a way to pass the clusterIP to the artifactory-postgresql chart included in artifactory. Any help would be appreciated.
Artifactory Upgrade using postgresql from 7.x to 9.x chart versions is a two step process
First upgrade 7.x to 8.x (Manual process involves export/import of data)
Then upgrade 8.x to 9.x chart versions
Please refer below for detailed steps :
https://github.com/jfrog/charts/blob/master/stable/artifactory/UPGRADE_NOTES.md
Note: For faster responses for your issues , Feel free to raise issues directly here
As explained in the article Controlling the fabric version that runs on your Cluster, you can choose which version of Service Fabric you want Azure to create for you.
The ServiceFabric nuget package seem to have the same version numbers as the clusters, but older versions of the packages work just fine with newer versions of the cluster.
Now, the release notes for version 5.4.145 state a list of improvements, and mentions that some older versions won't be supported anymore.
What I'm failing to understand is -
Will I get the list of improvements just by upgrading my cluster, or do I also have to upgrade my nuget packages?
Similarly, does it mean I have to upgrade my nuget packages soon, otherwise I'm at risk of running deprecated code?
Would also be nice to get some clarification of what exactly is upgraded when I upgrade a cluster, what's upgraded when I upgrade my packages, and how the two upgrades relate to each other.
There's a difference between the Runtime and the SDK. When the cluster is upgraded, it gets a new runtime. Any improvements in that runtime will be available to existing services running in the cluster.
Upgrading the SDK (or the Nuget packages) will result in new functionality to become available to applications (services/actors) built on top of the cluster runtime.
I'd recommend updating Nuget packages soon after upgrading the cluster to keep them in sync.
Using Ansible for deploying Kubernetes according to the official contrib repository, it installed a Kubernetes 1.2 for me, although 1.3.x is current. How can I specify the version?
Default value for roles is kube_version: 1.2.4.
You can override it by calling: ./deploy-cluster.sh -e kube_version=1.3.5
In principle, one could simply add
kube_version: 1.3.5
to the all.yml file. However, at least on RedHat, this does nothing. This is because other settings affect the Kubernetes version number, too. In case of RedHat,
kube_version: 1.3.0
kube_source_type: distribution-rpm
kube_rpm_url_base: https://kojipkgs.fedoraproject.org/packages/kubernetes/1.3.0/0.2.git507d3a7.fc26/x86_64
kube_rpm_url_sufix: 1.3.0-0.2.git507d3a7.fc26.x86_64.rpm
does the trick of upgrading the current playbooks (as of August 2016) to Kubernetes 1.3.0. (The kube_version may be even superfluous here.) Another possibility, which should work for all flavours of Linux, is
kube_version: 1.3.5
kube_source_type: github-release
However, at least as of August 2016, this leads to a deployment error, possibly because the directory structure of the Kubernetes source tree has changed between 1.2.0 and 1.3.5.
Other possible combinations of these settings can be found in the comments of Kubernetes' main.yml file, however, all this trouble suggests that it is best to wait for the Ansible Kubernetes files to be updated instead of forcing a newer version.
I use grafana 2.1 and created multiple dashboards, templates etc.
I would like to upgrade to grafana 2.6. Is there any way to upgrade to 2.6 without affecting the existing dashboards?
There are no breaking changes between 2.1 and 2.6. In theory upgrading should be a simple matter of installing the new packages. I personally have upgraded from 2.1.3 to 2.5 to 2.6 with no issues.
For windows version, I just had to copy the data/grafana.db and the data/plugins directory from the old installation to the new installation directory. Just make sure the newer version does not have any breaking changes.
You can upgrade Grafana to higher versions for better features and also import your previous dashboard to the new version without any problem by using Import/Export feature.