Version check on OpenShift

[djjudas21]

If you are reporting a problem, please make sure the following information are provided:

Expected behavior and actual behavior:
I am trying to install Harbor on OpenShift 4.6.0-0.okd-2021-02-14-205305 which packages Kubernetes v1.19.2. However the operator instructions fail with the error:

Release "harbor-operator" does not exist. Installing it now.
Error: chart requires kubeVersion: >= 1.16.0 which is incompatible with Kubernetes v1.19.2-1049+f173eb4a83e557-dirty
make: *** [Makefile:130: helm-install] Error 1

Steps to reproduce the problem:

git clone git@github.com:goharbor/harbor-operator.git
cd harbor-operator/
oc new-project harbor-operator
make helm-install

Versions:
Please specify the versions of following systems.

• harbor operator version: v2.2.0-rc3
• kubernetes version: v1.19.2

[djjudas21]

This also fails on MicroK8s 1.20

Release "harbor-operator" does not exist. Installing it now.
Error: chart requires kubeVersion: >= 1.16.0 which is incompatible with Kubernetes v1.20.2-34+350770ed07a558
make: *** [Makefile:130: helm-install] Error 1

[holyhope]

Hello @djjudas21 ,

Not sure what is the version 2.2.0-rc3 of HarborOperator. We just released the 1.0.
I tried to reproduce it with the HarborOperator master branch and OpenShift 4.7.8 (using CRC):

$ oc version
Client Version: 4.7.8
Server Version: 4.7.8
Kubernetes Version: v1.20.0+7d0a2b2

It worked after I ran make install-dependencies (got issue with Security Context Constraints but not during installation):

$ helm list
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
harbor-database harbor-operator 2               2021-05-16 00:05:38.777294 +0200 CEST   deployed        postgresql-10.3.17              11.11.0    
harbor-operator harbor-operator 2               2021-05-16 00:12:58.179203 +0200 CEST   deployed        harbor-operator-0.0.0-dev       0.0.0-dev  
harbor-redis    harbor-operator 2               2021-05-16 00:05:48.529638 +0200 CEST   deployed        redis-12.10.0                   6.0.12

The kubeVersion field you are mentioning is probably the one in the chart.
If I am not wrong kubeVersion: '>= 1.16.0' should match k8s 1.19 and 1.20.

Can you please send me the result of helm version and kubectl version?
Mine is:

1. $ helm version
   version.BuildInfo{Version:"v3.5.4", GitCommit:"1b5edb69df3d3a08df77c9902dc17af864ff05d1", GitTreeState:"dirty", GoVersion:"go1.16.3"}
   

2. $ kubectl version
   Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.0", GitCommit:"cb303e613a121a29364f75cc67d3d580833a7479", GitTreeState:"clean", BuildDate:"2021-04-08T21:16:14Z", GoVersion:"go1.16.3", Compiler:"gc", Platform:"darwin/amd64"}
   Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0+7d0a2b2", GitCommit:"7d0a2b269a27413f5f125d30c9d726684886c69a", GitTreeState:"clean", BuildDate:"2021-04-16T13:08:35Z", GoVersion:"go1.15.7", Compiler:"gc", Platform:"linux/amd64"}
   

[steven-zou]

@djjudas21

Any follow-up?

[djjudas21]

Hi, sorry for the delay. When I said v2.2.0-rc3 I must have been referring to the Harbor app version.

My team has abandoned implementation work on Harbor so this isn't relevant to me any more, but I think it is the same bug as NetApp/trident#530 where the fix was to format kubeVersion as 1.16.0-0 instead of 1.16.0

[steven-zou]

Hi, sorry for the delay. When I said v2.2.0-rc3 I must have been referring to the Harbor app version.

My team has abandoned implementation work on Harbor so this isn't relevant to me any more, but I think it is the same bug as NetApp/trident#530 where the fix was to format kubeVersion as 1.16.0-0 instead of 1.16.0

Thanks for replying.

May I know why does your team abandon implementation work on Harbor? What're the considerations?

[djjudas21]

We require high scale, geo-resilient image registry service which will be deployed in multiple data centres around the world for high availability, using BGP to direct clients to the nearest registry.

We found Harbor's built-in replication/clustering quite limited as it was able to replicate images but not users/groups. So we were looking at handling the replication ourselves and effectively running several standalone Harbor instances, and replicating the storage and database oruselves. We've got good options for distributed/replicated S3 storage for the images, but it's always difficult working with HA Postgres at scale.

We haven't given up on Harbor but we are also looking at other options, including Quay and also self-developed options.