goharbor / community Goto Github PK

View Code? Open in Web Editor NEW

73.0 23.0 78.0 197.72 MB

Harbor community-related material

Home Page: https://goharbor.io

harbor community cncf containers cloud-native hacktoberfest

community's People

Contributors

Stargazers

Watchers

Forkers

nlowe wy65701436 steven-zou bradmeiseles stonezdj munai-das yuanshuhan cd1989 danielzhanghl reasonerjt ywk253100 mmpei annexxb kacole2 zhoumeina zhill heww allencloud bitsf pytimer kofj minsheng-fintech-corp-ltd qiu957919102 erzascarle antoninbas xaleeks michmike markzhang0928 cafeliker prahaladdarkin inspuradmin hyy0322 gaocegege xiechengsheng syerram yhua123 ninjadq devopstoday11 jiaweizhou joschi36 vbasem chlins caiyuewei arslanabbasi jonasrosland jeremy-boo acidburn0zzz hiteshmah-jan imeoer bergwolf yunkunrao sayanta66 infosiftr ekmixon zyyw dentrax richroodbeen jinxingyoung cliftondobrich leonidas-o slushysnowman fossabot akshatdalton wilfredalmeida connectbhawna paarthagarwal yizha1 lengrongfu afrittoli allfornothing shengjiang3 karaguo container-registry oneflyingbanana sungjoon-koh orlinvasilev hainingzhang

community's Issues

clean up labels

I'd like to clean up labels used in gohabror/harbor. We currently have lots of old-ish labels, some that are related to VMware-specific products and projects. Many of these labels are not being used and / or are roughly duplicates of other labels.

Remove

I propose we remove the following labels:

Rename

I propose we rename the following labels:

Merge

I propose we merge the following labels:

area/helm-chart-repo and area/helm-chart

+1s 👍

Would really appreciate some feedback here from the @goharbor/all-maintainers team to make sure this doesn't impact our tooling / workflow.

move to cncf-hosted mailing lists

Dan Kohn reached out and recommended that we move our email discussion to CNCF-managed mailing lists:

I would recommend moving your dev and user mailing lists from Google Groups to lists.cncf.io to make the web interface accessible inside the Great Firewall.

If you're interested in doing so, Ihor would be happy to arrange the migration for you.

I propose we create the following mailing lists:

harbor - general community mailing list
harbor-announcements - notification of new Harbor releases and major news (low-traffic)
harbor-dev - development discussion
harbor-maintianers - for the occasional internal discussion amongst maintainers

If there are no objections by 30nov2018, I will begin working with Ihor and Dan to create the mailing lists and decommission the old Google-group-based lists.

Inactive maintainers and activity levels of maintainers

Hi all, my PR here: #244 brought some super healthy discussions about the activeness of maintainers and their willingness to continue contributing.
We decided to put on-hold that PR so we can discuss it here.
My points are, which were presented in the community meetings:

Improve security stance by reducing the inactive maintainers not required to have access to the project
our maintainers list is SUPER outdated
we have maintainers that haven't interacted with the project, haven't responded to mail, or slack message or even joined community meetings for years
that full and outdated list of maintainers prevents the community of adding new maintainers as we have examples of very very active people which are not maintainers
we must ensure we don't add only maintainers from a orgs(companies) that are having Harbor interested(offering or product)
define an activity levels for contributors and maintainers which we can measure so we can make easier decisions in the future
that's how Kubernetes is taking decisions based on these statistics - https://harbor.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=Last%20year&var-metric=contributions&var-repogroup_name=All&var-country_name=All&var-companies=All
~~- Merge this one - #156~~
setup a dedicated call to discuss this issue!

Create roadmap for Harbor project

The roadmap of Harbor should be defined and keep it in a ROADMAP.md file here.

For the roadmap file in the harbor project code repo, it can link to the ROADMAP file here.

Pierre PÉRONNET changed employment

Hi @holyhope, I see you have left OVHcloud are you still planing to be part of the maintainers team in the new company?

Thanks!

Helm chart maintenance

Not sure where to raise that issue... so I'm trying here.

https://github.com/goharbor/harbor-helm/pulls

There is 35 pull requests pending reviews, many of them seem very legits and actually improve and fix this chart.

The chart is still active, I see commits every few days. But the community PR are ignored. Not even reviewed and changes/rebased asked before merging them.

Is there a community? or the whole point of the maintainers of the helm charts is to solve their own needs and ignore the rest of the world?

test proposal

test

Harbor and Peritus Slack Assistant

/kind proposal

Thanks for the opportunity to present and demonstrate Peritus.AI to the Harbor Community on Wednesday, October 20, 2021. Pursuant to the recommendation at the meeting, I am opening this GitHub Issue to request the inclusion of the Peritus Slack Applications in the Harbor Channels on the CNCF Slack Workspace. Since these applications are already installed on the CNCF Slack Workspace, the Harbor channel admins need to enable the Applications (instructions are attached).

Peritus.AI is an ML platform for community-led growth. We are focused on cloud-native technologies to provide community intelligence for developer success. Peritus provides an ML assistant that provides recommendations for questions from Slack users. Peritus is currently offering our platform for free for all non-profit OSS projects.

On-boarding time is typically less than 2 weeks. The sources of the recommendations are Product documentation, Blogs, Slack Channels, StackOverflow, Community Forums, GitHub Issues, etc.

A short video that demonstrates the Peritus Assistant for Slack.

Ask for the Harbor community:

Validate the Harbor published content source list with Peritus

Product Documentation: https://goharbor.io/docs/
Blog: https://goharbor.io/blog/
GitHub: https://github.com/goharbor
StackOverflow Tags: harbor (https://stackoverflow.com/questions/tagged/harbor?tab=Newest)
Community Forum URL: No community hosted Q&A platform (e.g.: https://discuss.kubernetes.io/)

Enable the Peritus Connector on selected active Slack channels for sourcing Slack conversations

Installation of the Peritus Connector
- Reason: Sourcing Harbor community channel content
- URL for installation: https://slack.com/apps/A027CU2L7P0-peritus-connector
- Requirements: Admin/owner rights for the Slack workspace

Enable and promote the Peritus Assistant to community users

Installation of the Peritus Assistant for Slack
- Reason: Enablement of Peritus Assistant for Slack
- URL for installation: https://slack.com/apps/A0245BNBC0G-peritus-assistant
- Requirements: Admin/owner rights for the Slack workspace

Provide feedback on product experience

Peritus Assistant and Connector for Slack - Installation Guide.pdf

As the Assistant learns, its answers improve. Peritus will actively monitor the performance, and provide periodic updates to the Community. If the Community decides to disconnect the Assistant, Peritus will use their best effort to disconnect the Assistant and all related processes in a reasonable time period and there will be no impact on the Community's slack. The disconnect process can be initiated, approved, and tracked via another Harbor GitHub issue.

Proposal: add support of exposing Prometheus format metrics

At this point we don't expose any custom metric.We need discuss a little bit more what we want monitoring.

community meeting calendar links broken

hi there, I noticed that the calendar link on MEETING_SCHEDULE.md in this repo seems to be broken.

When trying to open it Google Calendar shows the error:

This email address isn't associated with an active Google Calendar account: NjdjNWRlMXNxdDRkNXQzNzlvaTByMXJ1YzRAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ. Please check the email address and try again.

Also the invite.ics that new subscribers to the harbor-users mailing list are being sent seems to have had its last recurring event:

This makes it hard for new users to find out the date of the next community meeting. I'm not sure who owns these accounts, hope this is the right place to post this (apologies if not).

Update the CII status of Harbor main project to reasonable stage

On the last TOC call there was a call to look at updating the graduation requirements and also to look at the various CII levels:
cncf/toc#196

One idea was to potentially have the incubating level require the "silver" level for CII and graduated require the "gold" level:

https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/other.md#silver-passing1-criteria
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/other.md#gold-passing2-criteria

On the next TOC call, we will have one of the main CII authors to go over the levels and answer any questions from the community. This should be a useful exercise to see if we can leverage the hard work that has been done in CII along with giving them feedback on the criteria they have developed.

Update master branch to main

We should update the default branch to be main, instead of master. This is part of our continued efforts to use inclusive language.

Once this is updated, we should check the main harbor code repo and website to make sure that all links to content in this repo point to main instead of master.

Harbor and CDEvents

Harbor recently introduced support for CloudEvents (kudos!), which makes it possible for consumers to watch those events, react to them and/or store them for records.

The CDEvents project, incubated at the CD Foundation, aims to standardise the content of events in the continuous delivery space, thus introducing interoperability across different tools.

CDEvents is being implemented by a number of tools like Jenkins, Spinnaker, Tekton, Testkube, Argo, and more.

One interesting feature of Argo CD is its ability to react to a new tag being published for an artifact, and automatically trigger a new deployment as well as a new PR to keep the git repo up to date as well. Argo CD today has to rely on polling only - a standard event sent by a registry on PUSH would allow Argo CD to react instantaneously.

Having all tools generating CDEvents allows organisations to collect all those events, and use them to build audit trails, and visualisations and trigger the next step in event-driven workflows.

I would like to author, with some help from the Harbor community, a proposal to integrate CDEvents in Harbor.
I started a draft proposal in an hackmd document, feedback and input are welcome. Once the draft proposal looks ok, I can submit a PR - but please let me know if I should follow I different workflow.

The "Proxy Cache" type of project supports access through subdomains without the projectName path.

Is your feature request related to a problem? Please describe it.

The address of a Docker image consists of FQDN + namespace + imageName:tagName, which we commonly understand as being composed of domain + path.
Since projects in Harbor represent the concept of namespaces, when using Harbor to proxy third-party images, a better solution would be to only change the FQDN, rather than adding an extra projectName. Having to include a projectName has caused practical problems for me, and many others have encountered the same issue in community forums and issues.
Real-world scenario: When I was deploying Kubernetes with Rancher, I encountered a problem. Rancher's private registry only allows entry of valid FQDNs and does not allow configuration of paths with a projectName suffix, such as allowing only harbor.test.com, but not harbor.test.com/dockerhub-proxy. Since the namespace + imageName:tagName for Kubernetes to build and pull base images is fixed, when I can only configure harbor.test.com, I cannot proceed. I had to manually create a project in Harbor with the same name as the namespace and then manually push dozens of required images before I could use it. This completely defeats the purpose of automatic proxying and is very troublesome.

Describe the solution you want

Desired solution: For all types of proxy projects, automatically assign a subdomain based on the main FQDN, with the subdomain automatically using the projectName. For example, if the main FQDN is harbor.test.com and the project name for proxying Docker Hub is dockerhub-proxy, then the proxy project can be accessed using dockerhub-proxy.harbor.test.com. Accessing dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 is equivalent to accessing harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0.

Advantages: After proxying a third-party repository, besides the change in FQDN, the path part does not need to include the projectName, and the path remains unchanged, which is more suitable for practical application needs and easier to understand.

Describe the main design/architecture of the solution

HTTPS certificate issue: Harbor's default certificate uses the wildcard domain *.test.com, which can automatically cover second and third-level domains like dockerhub-proxy.harbor.test.com.
Creating a project: The UI adds an automatic assignment of subdomains display.

This subdomain is automatically generated by the project name + main FQDN, with a question mark added afterward to indicate that when accessing the project via the subdomain, the path part can omit the projectName.

Code modification: When receiving necessary HTTP requests such as /v2 and /service, read the hostName and main FQDN for comparison, determine if it is a subdomain of the main FQDN, and obtain the projectName.

You can add the projectName to the URL routing through rewrite, or directly handle the request response at the code level with the projectName.

I am a Java engineer and do not understand the programming language of Harbor, so I cannot contribute a PR, sorry.

Only image proxy type projects need this; ordinary projects do not need an independent subdomain. Because an independent subdomain fits the logic of proxying third-party images, and ordinary projects consist of projectName + imageName, which conforms to common image path specifications.

Expected final effect

Accessing dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 via docker pull should be consistent with accessing harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0. Equivalent to accessing docker.io/xzxiaoshan/frpc:v0.59.0 .

The difference between dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 and docker.io/xzxiaoshan/frpc:v0.59.0 lies solely in the FQDN.

Thank you, I hope to achieve it.

以下问中文，我不确定上面英文翻译表达的是否准确。

您的功能请求是否与问题有关？请描述一下
对问题的清晰简洁的描述。例如，当[…]

1、docker镜像的地址由FQDN+namespace+imageName:tagName 组成，我们通俗的把它理解为 domain+path组成。

2、因为 harbor 中项目为单位来指代namespace的概念，当我们使用 harbor 来代理第三方镜像时，更好的方案是只变更 FQDN，而不应该多出一个 projectName，必须带有 projectName 它给我带来了实际问题，再社区圈子里和 issue 里也有很多人遇到一样的问题。

3、实际场景：我在使用 rancher 部署 Kubernetes 时，就遇到了问题。rancher 的私服只能输入合法规范的 FQDN，不允许配置带有 projectName 后缀的路径，例如它只允许写 harbor.test.com，而不允许写 harbor.test.com/dockerhub-proxy。因为 Kubernetes 构建拉取的基础镜像的 namespace+imageName:tagName 是固定的，所以当我只能配置 harbor.test.com 时，我无法进行下去。我手工在harbor中创建了一个 namespace同名的项目，然后手工将所需要的几十个镜像push进去后才可以使用，这样完全失去了自动代理的意义，非常麻烦。

描述您想要的解决方案

期望的解决方案：所有代理类型的项目，自动分配基于主 FQDN 的子域名，子域名自动使用 projectName。例如主 FQDN 是 harbor.test.com，代理 dockerhub 的项目名称为 dockerhub-proxy，那么该代理类型的项目支持使用 dockerhub-proxy.harbor.test.com 来访问。访问 dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 相当于访问 harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0

优点：代理第三方仓库后，除了FQDN发生了变更，path 部分不需要可以增加 projectName，path 没有发生任何改变，更加适合实际应用需求，也更容易理解。

描述解决方案的主要设计/架构

1、https证书问题：harbor 默认证书使用 *.test.com 通配符域名。能自动覆盖二级、三级域名 dockerhub-proxy.harbor.test.com。

2、创建项目：UI 新增自动分配子域名显示。

该子域名为自动规则，由项目名称 + 主 FQDN 组成，后面增加一个问号提示解释通过子域名访问该项目时，path部分可以省略projectName。

3、代码修改：接收到 /v2 和 /service 等必要 http 请求时，读取 hostName 和主 FQDN 进行对比，判断是否为主 FQDN 的子域名，并获取 projectName。

可以通过 rewrite 的方式增加 projectName 进行 url 路由，或者直接在代码底层通过 projectName 直接处理请求的响应。

我是Java工程师，不了解 harbor 的编程语言，无法贡献 PR，很抱歉。

4、只有镜像代理类型的项目才需要，普通项不需要有独立子域名的需求。因为独立子域名符合代理第三方镜像的逻辑，并且普通项目由 projectName+imageName 组成，符合镜像路径常用规范。

期望最终效果

通过 docker pull 访问 dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 和访问 harbor.test.com/dockerhub-proxy/xzxiaoshan/frpc:v0.59.0 是一致的。等同于访问 docker.io/xzxiaoshan/frpc:v0.59.0 。

dockerhub-proxy.harbor.test.com/xzxiaoshan/frpc:v0.59.0 和 docker.io/xzxiaoshan/frpc:v0.59.0 的区别，只有 FQDN。

谢谢，期望能实现。

Harbor

maintainers: Promote Tianon Gravi maintainer

This issue holds the voting process to promote him to a maintainer.

Current maintainers, please indicate your approval of this with a comment on this issue.

Support for new artifact types over OCI

Hello, this is related to goharbor/harbor#7773 (cc @reasonerjt)

Harbor should introduce support for new artifact types over OCI.

Some examples may include Helm charts, CNAB bundles, OPA bundles, as well as other artifact types that are sure to arise out of the cloud-native ecosystem. You can see a complete list of all artifact types that are recognized by Azure Container Registry (ACR) here.

As Harbor is built atop Docker Distribution, this is actually already supported out-of-the-box.

The only difference at a low-level is in the image manifest's config.mediaType field. Here is a snip of a Docker image manifest:

{
    "schemaVersion": 2,
    "config": {
        "mediaType": "application/vnd.docker.container.image.v1+json", // <-----
        "size": 7023,
        "digest": "sha256:b5b2b2c507a0944348e0303114d8d93aaaa081732b86451d9bce1f432a537bc7"
    },
    "layers": [
...

Here is a example of a Helm chart stored in distribution:

{
    "schemaVersion": 2,
    "config": {
        "mediaType": "application/vnd.cncf.helm.chart.config.v1+json", // <-----
        "size": 2,
        "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a"
    },
    "layers": [
...

Harbor may wish to restrict allowed values for mediaType. This may be something that can even be configured on distribution (or should be). Defining which artifacts are supported will allow Harbor to build rich UIs atop specific supported artifacts as it has done with Helm charts.

Alternating Community Meeting for US friendly TZ

Would love to have US friendly TZ Community meetings!

Let's try to figure out a way to make it work :)

Switch from GitHub Wiki pages to hackmd.io for community meetings notes

Hello Community!
On our last community meeting we discussed the possibility to use hackmd.io instead of the GH wiki pages.
The pros are that we have better visual and editing experience and in particular parallel edits.

Example here: https://hackmd.io/CyQk5FdVQwWObMLVNqxW1w?view
Please vote with +/-
Orlix

How do you use Harbor? Let us know!

This really isn't an issue, but we'd love to hear about your use of Harbor so we thought we'd post this to find out more from you.

Some key things of interest may be

Number of container images and Helm Charts under management
Storage size consumed by Harbor
Number of end users (i.e. developers)
If you have multiple Harbor environments set up with replication
Are you using Harbor today in production or pre-production/sandbox/dev-test (or all of the above)

Please feel free to add a comment below and let us know. We will keep this issue open, making it a posting board for Harbor usage.

thank you in advance,

@michmike
Harbor Core Maintainer

Migrate from CNCF mailing lists to Google Groups

Would like to propose a migration from CNCF mailing lists to Google groups for better and easier management of the calendar events and people involvement! Please vote bellow!

harbor image support amd64 and arm64

I find now many company need arm64 OS/ARCH image for harbor install，It is there any plan for that