goharbor / community Goto Github PK
View Code? Open in Web Editor NEWHarbor community-related material
Home Page: https://goharbor.io
Harbor community-related material
Home Page: https://goharbor.io
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.
I propose we remove the following labels:
I propose we rename the following labels:
I propose we merge the following labels:
Would really appreciate some feedback here from the @goharbor/all-maintainers team to make sure this doesn't impact our tooling / workflow.
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:
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.
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:
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.
Hi @holyhope, I see you have left OVHcloud are you still planing to be part of the maintainers team in the new company?
Thanks!
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
/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:
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.
At this point we don't expose any custom metric.We need discuss a little bit more what we want monitoring.
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).
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.
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 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.
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.
/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.
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。
谢谢,期望能实现。
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.
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.
Would love to have US friendly TZ Community meetings!
Let's try to figure out a way to make it work :)
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
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
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
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!
I find now many company need arm64 OS/ARCH image for harbor install,It is there any plan for that
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.