We're currently using Artifactory 2.3.3.1 and want to upgrade to V 4.14.3
As per the findings on web the usual approach is a 2 phase upgrade i.e
V 2.3.3.1 ->> V 3.9 ->> V 4.14
I'm aware of the steps mentioned in the JFrog documentation but the issue is over the time the current artifactory has grown in size in TBs. It's not feasible to do an export and Import which as per documentation is one of the steps of upgrading from V 2.3.3.1 ->> V 3.9.
Is there any other way around ?
You can upgrade from 2.6.7 to 3.x without exporting the artifacts. Take a look at the "Upgrading from v2.6.7 and Above to v3.x" section of the upgrade instructions. Notice that you check the "Exclude Content" checkbox, which means you will only export the metadata and not the artifacts themselves.
You can upgrade from 2.3.3.1 to 2.6.7 using the regular upgrade procedure, without the need to export data.
One thing you must assure is having a full backup of Artifactory before starting this procedure!
Related
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.
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
So the official documentation states:
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.14.x to version 1.15.x, and from version 1.15.x to 1.15.y (where y > x).
So the latter point about moving from say 1.15.1 to 1.15.4 makes sense.
What I am confused about is the 1.14.x to 1.15.x...
should I always upgrade to the latest in the 1.14 line before attempting upgrade to 1.15?
does x have to the same? ie i have to do 1.14.5 to 1.15.5? (i assume not... but x -> x seems to state so...)
is it okay to upgrade directly to the latest 1.15? (1.15.4 at time of writing), or should we start from 1.15.0?
I was able to search Google for the string in your question:
This page explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.14.x to version 1.15.x, and from version 1.15.x to 1.15.y (where y > x)
to find which official docs you were referring to (I've updated your post with a link as well). I searched that page for the word "skip" and found:
You only can upgrade from one MINOR version to the next MINOR version, or between PATCH versions of the same MINOR. That is, you cannot skip MINOR versions when you upgrade. For example, you can upgrade from 1.y to 1.y+1, but not from 1.y to 1.y+2.
So that answers your first question, i.e.
should i always upgrade to the latest in the 1.14 line before attempting upgrade to 1.15?
Yes.
For your second question:
does x have to the same? ie i have to do 1.14.5 to 1.15.5? (i assume not... but x -> x seems to state so...)
No, x doesn't have to be the same.
Finally:
is it okay to upgrade directly to the latest 1.15? (1.15.4 at time of writing), or should we start from 1.15.0?
Yes, it's okay, in fact it's probably recommended to go to the latest. Patch versions often fix bugs and security vulnerabilities, so you should always go to the latest patch of whatever minor version you're trying to go to.
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.
I am planning to upgrade our GitHub Enterprise from 2.2.4 to the latest 2.3.3. Reviewing the upgrade document here:https://help.github.com/enterprise/2.3/admin/guides/installation/upgrading-the-github-enterprise-virtual-machine/
I have two questions so far:
"Download the upgrade package", the official download page for
VMWare 2.3.3 is a full .ova file, not a .pkg file as in the doc.
Do I need to create the "target root partition" /dev/xvda2 as in the doc beforehand?
I have a 3rd question:
As the backup solution, I am taking a VM snapshot before upgrade, shall I put the GitHub into Maintenance Mode before taking the VM snapshot?
Thanks
Jirong
The upgrade was successful. Here is the answers:
1. Copy the URL from the Upgrade tab, not Install.
2. No.