UNRESOLVED unable to upgrade from 6.18.0 to 7.3.2

[JakeDEvans]

Upgrade from 6.18.0 complains of missing join.key for artifactory-pro

Current: postgres:9.6.11 artifactory-pro:6.18.1 nginx-artifactory-pro:6.18.1

Upgrade: postgres:9.6.11 artifactory-pro:7.3.2 nginx-artifactory-pro:7.3.2

Similar issue mentioned here: https://stackoverflow.com/questions/55142890/join-key-file-not-created-or-deleted-on-upgrade-to-6-8-x-artifactory-pro

but env var JFROG_JOIN_KEY took no effect

UPDATE: also doesn't work between these versions

[eldada]

@JakeDEvans - note that there is currently a known issue with migration from 6.18.0 to 7.2.1. See the release notes. Artifactory 7.3.x is planned to be released in the coming days. Also, note that this repository is deprecated as we now have an official docker-compose distribution of Artifactory.

Let me know if I can close this.

[JakeDEvans]

Yeah that's the issue I've found, nobody else is having this issue.

do you know if I can restore 6.18 back up 7.2.1

[JfrogPrasanna]

@JakeDEvans First of all the current docker examples repo are deprecated with the release of unified platform, and the new installers for compose can be found here - https://jfrog.com/download-jfrog-platform/

The upgrade from 6.18 has an issue, and we are supporting the upgrade only to an upcoming release 7.3.x that is coming soon in the next few days.

Now on missing join key, there are a plenty of structural changes between 6.x and 7.x and hence there is a need to use migration script, which are are detailed here - https://www.jfrog.com/confluence/display/JFROG/Installing+Xray#InstallingXray-InteractiveScriptInstallation(recommended)

Let me know if these helped.

[JfrogPrasanna]

@JakeDEvans please note that Artifactory 7.3.2 has been released and these issues should be resolved. Can you please upgrade and let us know. I am going ahead and closing this issue.

[JakeDEvans]

6.18.0 to 7.3.2 does not work 6.18.1 to 7.3.2 does not work

both attempted with my data, and a clean install

[kb7791]

I'm having a similar issue with upgrading from a docker-compose 6.17.0/postgres 9.6.11 upgrade to artifactory 7.3.2. I find that the instructions on what the config.sh file is doing and how you incorporate your previous docker volumes so that repos and configurations are migrated over are a little vague. You're basically told to run this script to set up directories and proper ownership but it seems as if it creating new directories to as an installation directory. It launched but all the previous content from 6.17 is missing.

[JakeDEvans]

Mine actually upgrades, and then fails to start, complains about the license.

The license is valid with a fresh install of 6.18.1 or 7.3.2, and their update instructions are insane, all you should have to do is swap the image version and docker-compose up

[kb7791]

Are you using docker named volumes or local bind mounts?

[JakeDEvans]

both, I don't get permission issues if I do named mounts

version: '3'
services:
  artifactory:
    image: artifaction_image
    volumes:
     - artifactory_data:/var/opt/jfrog/artifactory

volumes:
  artifactory_data:
    driver_opts:
      type: none
      device: /srv/artifactory/artifactory_data
      o: bind

[kb7791]

I'm using docker volumes that reside in /var/lib/docker/volumesartifactory_data/_data & postgresql_data/_data that seem to work fine using a docker-conmpose file that uses postgres 9.6.11 and artifactory 6.17.0 but this upgrade to 7.3.2 based on jfrog instructions isn't going so smooth.

The config.sh setup is a little confusing as to what its doing under the hood, seems to create a new var directory that has redundant directories my previous volume mount already has along with adding a few other directories to my existing docker volumes.

[JfrogPrasanna]

@JakeDEvans can you share the log you see about the license issue - do you have the .lic in etc folder of artifactory?

[JakeDEvans]

I've given up on attempting to migrate from 6.x to 7.x and have hand-copied over all configurations, it was much faster than tying to work with support and reverse engineer whatever you're trying to do with migrations scripts.

Postgres is docker, just works nginx in docker, just works artifactory in docker....I've lost an entire week trying to get this "New Compose" thing working, there's no reason not to have your entrypoint detect what version the files/database/etc are on, and run the correct migration scripts to update the database schema and file structure.

the artifactory-pro-nginx container no longer provides any benefit to me, I'll just be using the alpine nginx container, my certs and your generated proxy config which has it's on dependencies .

I've also had to start with your image and make changes, as there is zero reason to expose the artifactory container ports to anything outside of nginx, I have no idea how you possibly have any customers using this solution.

@JfrogPrasanna you can get the logs from ticket #129037

[JfrogPrasanna]

@JakeDEvans I am still not sure of the issue you are facing. I would like to see the logs and come back. Expect my reply on Monday.

[JfrogPrasanna]

@JakeDEvans Looks like Nir has given the steps to move from Docker install to Docker compose. Hope that works for you.

[JakeDEvans]

it did not.

[JfrogPrasanna]

@JakeDEvans We were able to simulate this and here is the root cause.

1. The folder structure of data has in-fact changed significantly between 6.x and 7.x
2. The config.sh runs on the host and tries migrated to the new folder structure and also migrate the properties to the new system.yaml. But it fails for docker volumes of the kind above due to permission issues.
3. To handle this, you may want to bring a empty container with the artifactory_data mounted (like a busy box and perform the migration manually as explained in here or perform a upgrade of folder structure via a simple docker run (without compose) as explained here (this is available only from 7.4.1)
4. Once migration is complete, you can run the compose and it should be fine.

Let me know if this works and makes sense.

[JakeDEvans]

you can close this issue unresolved, I did have 30 days for your teams to take me seriously.