Harbor Graduation Review

[michmike]

SIG-Storage Graduation review request of Harbor as per cncf/toc#311

[saad-ali]

/assign

[saad-ali]

Harbor is a DIY environment-agnostic container registry. Goal of my review is to evaluate the Harbor project for graduation purely from the storage perspective. Any non-storage concerns should be be in cncf/toc#311

From the storage perspective, I want to see a tight integration with Kubernetes and the ability to deploy in an HA way on an arbitrary cluster (without tight coupling with underlying storage).

Based on https://github.com/goharbor/harbor/blob/master/docs/1.10/install-config/harbor-ha-helm.md#usage Harbor has the following storage dependencies:

• Application Data
  • StorageClasses/PVCs OR Object Storage
• Images & Charts Data
  • PostgreSQL database
  • Redis cluster

My observations:

• Uses of StorageClasses/PVCs for Application Data is good. It ensures the deployment of Harbor is independent of any specific storage implementation.
• Optionally use of an object store instead of PVCs is a nice option for users. While it does tie the user to a specific implementation, based on https://github.com/goharbor/harbor-helm#configure-the-way-how-to-persistent-data the following object stores are supported: azure, gcs, s3, swift and oss, and object storage is not required and is only provided to make it easier for users who can't provide multi-writer file, which seems reasonable.
• The dependence of Harbor on PostgreSQL database and a Redis cluster could be problematic. I know the TOC has had some concerns about the neutrality of dependencies (while I don't have an issue with that, it may come up in the main review). I am concerned that based on this, the deployment and set up of these required dependencies is left as an exercise for the user. @michmike can you verify if that is the case?

[michmike]

@saad-ali thank you for the review. To answer your question, the Harbor Helm Chart (or our docker-compose deployment method) will deploy single instance of redis and postgres automatically. To deploy a HA redis/postgres, users need to set up them externally. We are currently working on a Harbor operator that will help setup automatically HA redis and HA postgres.

[michmike]

we are also working in the near future to possibly replace postgresql with CockroachDB

[dankohn]

I would predict that the TOC would look negatively on a requirement on a non-open source project like CockroachDB. Having a pluggable DB layer with multiple options (some open source, and some proprietary) could make sense. But actually replacing PostgreSQL (a well-regraded open source database) with CockroachDB (a source available database) would be problematic.

[michmike]

Having a pluggable DB layer with multiple options (some open source, and some proprietary) could make sense

hi Dan, that's why i mentioned "possibly" in my comment. we would first have to do our due diligence, and this has not happened yet. of course we value the opinion of the TOC in this matter.

[saad-ali]

Thank you to the Harbor team for providing more information.

CNCF SIG Storage Due Diligence Report

Observations

The due diligence observations are summarized above in #52 (comment)

Recommendation

After completing due diligence, members of CNCF SIG Storage have raised some concerns that are outlined below. Some members of the SIG believe that we should hold off on graduation until they are addressed, others don't see them as blocking concerns. We leave the ultimate decision up to the CNCF TOC.

Areas of Concern

Lack of Out-of-Box HA

Deployment of the dependencies, Redis and Postgres, in high availability configuration is left up to the user (not supported by the Harbor Helm chart).

Counter Argument

The harbor team had two counter arguments

• Postgres and Redis have their own Helm charts that support HA deployments.
  • The argument is that for customers that desire this, they either already have their own HA deployment or can use the Postgres and Redis Helm charts to achieve HA.
• Application-Level Async Replication
  • Two harbor instances can be set up to asynchronously replicate a registry.
  • This makes a harbor instance more tolerant to whole cluster/site failure.
  • Since replication is async (not sync), there is still a chance for data loss, but this may be sufficient for some (based on desired SLO).

Dependence on Postgres and Redis

In the past, members of the CNCF TOC have expressed some concerns about the neutrality of dependencies, in general extensibility is desired.

Counter Argument

• Given that both dependencies are open source, it's unclear what the concerns are.

[saad-ali]

/close

[raravena80]

Can SIG-Storage update the consolidated SIG review template with its assessment http://bit.ly/harbor-graduation-dd? Thx!