Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jfrog artifactory helm upgrade to newer version best practice ? #1923

Open
hamedsa-78 opened this issue Sep 16, 2024 · 19 comments
Open

jfrog artifactory helm upgrade to newer version best practice ? #1923

hamedsa-78 opened this issue Sep 16, 2024 · 19 comments

Comments

@hamedsa-78
Copy link

hamedsa-78 commented Sep 16, 2024

Is this a request for help?:
Yes

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
This is a request for help.

Version of Helm:

Helm: v7.90.9

What happened:
I have JFrog Artifactory version 7.16.2 installed via Helm in my Kubernetes cluster, and I want to upgrade it to version 7.90.9 While following the official documentation,
(https://jfrog.com/help/r/jfrog-installation-setup-documentation/artifactory-version-7.x-to-7.x-helm-upgrade.)
I encountered an issue during the upgrade process. I scaled down the StatefulSet resources to 0 and attempted to install the new version using the existing persistent volume claims (PVC) for both PostgreSQL and Artifactory. However, I got an error stating that the existing PostgreSQL volume was initialized with PostgreSQL 14, which is not compatible with the PostgreSQL 15 version used by the newer JFrog Helm chart.

What you expected to happen:
I expected the new version of JFrog Artifactory to be deployed while using the existing persistent volumes and PostgreSQL database, allowing a seamless upgrade process without database compatibility issues.

How to reproduce it (as minimally and precisely as possible):

Install JFrog Artifactory version 7.16.2 using the Helm chart in a Kubernetes cluster.
Configure the chart to use PostgreSQL 14.
Attempt to upgrade to version 7.90 of the JFrog Helm chart.
Use the same PVCs for PostgreSQL and Artifactory.
Observe the PostgreSQL compatibility error related to PostgreSQL 15.

Anything else we need to know:

I considered modifying the Helm chart to continue using PostgreSQL 14, but I'm unsure if the existing data in PV would be compatible with the newer version of JFrog Artifactory.

I would appreciate guidance on whether it’s better to modify the Helm chart to use PostgreSQL 14 or to follow a process to upgrade the database to PostgreSQL 15 without data loss.

@Alexhha
Copy link

Alexhha commented Sep 16, 2024

Do you use builtin database or external one ? What helm chart did you use for 7.16.2 installation ?

@hamedsa-78
Copy link
Author

hamedsa-78 commented Sep 16, 2024

Do you use builtin database or external one ? What helm chart did you use for 7.16.2 installation ?

Actually, the version is 7.16.3, available here. I am using the built-in database, and version 7.90.9 works with PostgreSQL 14 as well. However, when I define existingClaim in the Helm chart for artifactory section pointing to the PVC from version 7.16.3, my pod gets stuck in an error state with the message "wait for db."

I am not sure if using the existing PVC (provided by openebs-hostpath) for the newer version is valid. Does the data storage format change between versions, and should I expect this method to work at all ? If not, would the best upgrade approach be to download all repositories from the previous version and upload them into the newer version after installation?

@RobinDuhan
Copy link

@hamedsa-78 Postgres 14 should work, and you don't have to upgrade it. Set the postgres tags same as 14 in the chart, and set databaseUpgradeReady as true. Please try this once in a non-production environment.

@hamedsa-78
Copy link
Author

hamedsa-78 commented Sep 17, 2024

@RobinDuhan
I cannot find databaseUpgradeReady. Could you please specify exactly which sections and subsections I should define it in?

@RobinDuhan
Copy link

RobinDuhan commented Sep 19, 2024

Please find the reference for the flag here -

databaseUpgradeReady: false
- for platform charts.

If you are using individual charts, the configuration for this flag stays same, something like -


global:
  ***

databaseUpgradeReady: true

artifactory:
  ***

@45parth
Copy link

45parth commented Oct 17, 2024

Hi @RobinDuhan I do have same question. We have Artifactory version 7.77.11 with bundled PSQL 13 deployed with helm chart. We want to upgrade Artifactory to 7.90.x which now supports PSQL 15. Along with upgrading Artifactory we want to upgrade PSQL from 13 to 15.
Would you mind sharing detailed steps, along with estimated DT (if any) where we have around 7TB of data?

From what I found, I need to follow below steps-

  1. Current helm chart version of JFrog Platform is 10.17.4 which is less than 10.18 which introduced support for PSQL 15.
  2. Upgrade only Artifactory to say 10.19.4 chart version with adding below parameters
    gaUpgradeReady: true databaseUpgradeReady=true postgresql.image.tag=13.x (same as current)
  3. Confirmation needed is here. Say suppose I upgrade from 10.19.4 to 10.19.6 with same procedure as above, but here I also want to upgrade PSQL to 15, how should I do?
    gaUpgradeReady: true databaseUpgradeReady=false postgresql.image.tag=15.x

Please do share the detailed steps or approach to upgrade Artifactory and PSQL.

@45parth
Copy link

45parth commented Oct 18, 2024

Hi @Alexhha @oumkale If you can help for above query that would be great as well.

@RobinDuhan
Copy link

Hi @45parth, Postgres major upgrades cannot be done directly. The instructions to keep the tag same (postgresql.image.tag=13.x (same as current)) is to avoid any failures, and we recommend that customers update their databases manually. Instructions for the manual upgrade process would be available with postgres.

@45parth
Copy link

45parth commented Oct 22, 2024

@RobinDuhan As I mentioned above, it is the bundled PSQL and not the external database. If you can provide a document stating the PSQL upgrade of the container or the image used by the JFrog that will be great, I was not able to find any.
I doubt, this can be done inside the running container.

@RobinDuhan
Copy link

@45parth We use bitnami's postgres image. Meanwhile, could you please tell me what your license type is? Pro/E+ etc.

@45parth
Copy link

45parth commented Oct 24, 2024

@RobinDuhan But is there any procedure to upgrade, if helm chart does not have the provision?
We have Enterprise license.

@RobinDuhan
Copy link

@45parth In that case, please open a support ticket and our support engineers will work with you up to resolution.

@45parth
Copy link

45parth commented Oct 24, 2024

@RobinDuhan I had already opened the support ticket for this, but the response was not that appropriate and clear.
So, I am asking here.
Please do share if there is some other way.

@RobinDuhan
Copy link

@45parth Will you please share the support reference number?

@45parth
Copy link

45parth commented Oct 25, 2024

@RobinDuhan Sure. The Case/Ticket number is 316219, which is currently closed.

@RobinDuhan
Copy link

RobinDuhan commented Oct 28, 2024

@45parth Thanks, - I am late to respond but we are working internally and should have an update for you soon.

@45parth
Copy link

45parth commented Nov 4, 2024

@RobinDuhan Any update here, please?

@gitta-jfrog
Copy link
Collaborator

gitta-jfrog commented Nov 7, 2024

Hi @45parth

The upgrade of PostgreSQL application version is not part of JFrog documentation. We recommend to follow the official instructions of PostgreSQL.

Additional method is to migrate Artifactory content from old to new database instance by using Artifactory System Export / Import.

@45parth
Copy link

45parth commented Nov 7, 2024

@gitta-jfrog Thanks for the update!
As I mentioned, the PostgreSQL is internal which comes built in with helm chart and not external.
We cannot follow the PostgreSQL official documentation to upgrade the containerized or inbuilt PSQL as it is totally different process.

Using Artifactory Export/Import, we already followed while upgrading Artifactory from version 6.x to 7.x. But this is not the feasible way to do it every time where you have more than 7 TB of data.
If there is no other way, unfortunately we will have to follow same and before proceeding need to make architectural changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants