goharbor / community Goto Github PK

test

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

/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:

1. 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/)

2. 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

3. 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

4. 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.

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 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

Would love to have US friendly TZ Community meetings!

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

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:

• 0.5.0-defer
• 1.1.0-defer
• 1.2.0-defer
• 1.4.0-defer
• 1.5.0-defer
• 1.6.0-defer
• area/tile
• candidate/1.5.1
• candidate/1.5.2
• candidate/1.6.0
• candidate/1.7.0
• candidate/1.8.0
• cla-not-required
• cla-rejected
• COBD
• DB change
• found-in/pks-0.8
• found-in/pks-1.0
• kind/advanced
• kind/impact-ova
• kind/ux-fit-and-finish (use area/ui or area/ux instead)
• make
• message
• needs/validation
• new-ui
• product/pks
• product/standalone
• product/vic
• RFC
• target/pks-0.8
• target/pks-1.0
• target/pks-1.1-stretch
• target/pks-1.2
• target/post-1.2.0
• target/post-1.3.0
• target/post-1.5.0
• target/vic-1.3
• target/1.2.0-stretch
• target/1.2.0
• target/1.5.0
• target/1.5.1
• target/1.5.4
• target/1.6.0
• target/1.6.1
• target/1.7.0
• target/1.8.0
• UX (use area/ux instead)
• waiting-for-verify (use needs/repro instead)
• with-admiral

Rename

I propose we rename the following labels:

• area/devops-support -> area/ops
• area/test automation -> area/test-automation
• env_issue -> env-issue
• external_integration -> external-integration
• kind/customer-found -> found/customer
• kind/automation-found -> found/automation
• kind/longevity-found -> found/longevity (do we run longevity tests?)
• kind/nightly-blocker -> found/nightly
• need-document -> needs/documentation
• need-test-case -> needs/test-case
• need-triage -> needs/triage
• need-reproduction -> needs/repro
• pending-more-info -> pending/info
• pending-ux-review -> pending/ux-review
• photon:2.0 -> area/base-linux
• security -> area/security

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.

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

hi Team,

We have installed harbor (1.14.2) using the helm chart in Kubernetes cluster (1.27.10), configuring certSource as auto, but only one cert, either hub or notary cert, is getting autogenerated. Can anyone please help us resolving this.

Below is our values file(expose section):

expose:
type: ingress
tls:
enabled: true
certSource: auto
auto:
commonName: ""
secret:
secretName: ""
notarySecretName: ""
ingress:
hosts:
core: hub-testcert.
notary: notary-testcert.
controller: default
kubeVersionOverride: ""
className: ""
annotations:
ingress.kubernetes.io/ssl-redirect: "true"
ingress.kubernetes.io/proxy-body-size: "0"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/proxy-body-size: "0"
cert-manager.io/cluster-issuer: incommon
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"

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.

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.

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.

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

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?

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 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!

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.

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).