 Hello, I'm Daojun, the host of the base group conversation. I'm somewhere in the near in Wilmware, Beijing. Spend 50% of my time working on carbon all-over-sales project. Chen Yu, could you please introduce yourself? Yeah, thank you. Hello, everyone. My name is Chen Yu Zhang. I'm from Wilmware, and I work for Harvard about one year. I focus on the area of replication, performance and observability. So, Vadim? Yes. Hello, everyone. My name is Vadim Bauer. I'm the founder of 8G Container Root 3, where we're using Harvard as our foundation to make container management or container image management easier for enterprises and SMEs. Today, we will introduce Hubble and its key features. The project update in ECL include the Harvard new features in 2006 and the Harvard 2007 plan. In the end, we will introduce how to participate in our project. Some of you might be unfamiliar with the Hubble. Let me quickly go through some of the key features in Hubble. Access control. User could access resources by different roles, such as system administrators, project admin, maintainer, and developer and guest roles. It is support different authenticator, such as local user management, active directory, ADAP, or IDC user management, and also support robot account to access Harvard resources. Robocon is widely used in the CI-CD platform as a service account. The next is the management policy. Admin could set up a retention policy and immutable policies on different projects. It helps the administrator to manage the artifact and storage space. And next is the artifact verification. Now, Harvard already support most of the public card registries, such as Doc Hub, DCR, DCR and Azure, ACR, etc. It could help replicate images from or to these registries and also can publicize these registries. Nowadays, there are more and more concerns on the area of the security. Harvard plays a prominent role in the security of the cloud-making software supply chain. It provides the following features, standing image feature could help to secure the images from development to production. Make sure the image is coming from a trusted source. Image scan feature could help the user to identify the vulnerability in the artifact. In recent days, we support to export this severe information into a file for download. You will see it in the following demo. Meanwhile, Harvard provide a set of integration feature, such as the authentication with different back-end LDAP or OIDC, and also provide adapter mechanism which allow user to integrate different image scanner. For image replication, there are many adapters could be used to connect to different registries. Webhook event notification makes the event-based integration more easier. It's all the key features in Harvard. In August of this year, we have released Harvard 2006. Let me introduce new feature in this release. The first is the cache file. We are adding cache layer to improve the performance of high-concerned core requests. And the second is the audio log approach and forward. And the next is the CVX part feature. And WebAssembly artifact support. The last one we backup or use the last one feature is the backup restore hub with Valelo. Meanwhile, we also upgraded some component in 2006. We bomb up the big O version and upgrade the Angular version in the UI and also bomb up the Golan version into 1.18. And we compatible with the Docker Compose V2 version. And we bomb up the CV and the CV adapter to the latest version. OK, let's go through these features. First, Cheng Yu, could you please introduce the cache layer and see the install feature? Hi, this is the introduction for cache layer in the Harvard 2.6. Firstly, I want to introduce the background. You know, with the development of cloud-native related technologies, more and more applications and CICD pipelines being implemented, Harvard as an imagery registry needs to be able to handle thousands or more requests at one time. And actually in the real world, the poor requests often more than push. Hell, a big challenge is sometimes Harvard needs to handle the high-concurrent pulling requests in the same time. If as an enterprise registry, it's very important to guarantee the performance and availability in any time. Become to the enterprise-grade registry is Harvard's goal. So in Harvard 2.6, around the scenario of high-concurrent pulling images, we introduce the cache layer, what stores some mostly used resources in the reddish. From that, Harvard no longer need to query from PG and the distribution when user pulling the image manifest because now they can raise them from reddish directly. So it's faster than before. OK, this is the background. And enable this feature is very easy. You can just refer to Harvard documentation for more details. Next, let's do a quick overview about the performance improvement. Our test based on the performance of pulling image manifest because our design is around this scenario. The first diagram is a compilation of response time. The blue bar represents cache disabled and the green bar represents cache enabled. And the x-axis is the number of the concurrent from 1,000 to 20,000. The y-axis is the time of response. The time unit is seconds. For example, when the concurrent is 1,000, not enable cache needs about nine seconds. But after enable cache, the time is only less than half a second. The effect is very obvious. We can see from the diagram when the concurrency less than 8,000 cache enable can improve about 10 to 30 times. And when the concurrency over than 8,000, the improvement can be about 3 to 10 times. Here I want to explain why with concurrency increase the response time of cache disabled have decreased from one point. That is there are many requests failed fast. We will discuss this later in the last diagram. OK, then let's move you to the second diagram. The second diagram is the compilation of the TPS. The TPS means the transaction every second. This metric represents the number of requests that harbor can handle every second. In the different concurrency, if not enable cache, harbor can only handle about 600 requests every second. But if enable cache, harbor can process over 4,000 requests. The improvement is about seven times. OK, let's move to the last diagram. Last but not least, the last diagram is the success rate. This metric reflects the availability of harbor. And it's very valuable. From the chart, we can see if not enable cache, the success rate will continue to decrease when the concurrency over than 8,000. But if enable cache, even with 20,000 concurrency, harbor can still handle all these requests successfully. But in the same condition, not enable cache will have over half failed requests because the success rate is only 38%. This result can also reflect to first two diagrams. The response time and the TPS seems to be better in the 20,000 concurrency. But that's not the truth because the mass failed requests improve the average. Besides above improvement, the database connection also less than before if enable cache, as well as the CPU usage of the database registry and the call also have the obvious improvement. OK, that's all about cache layer in the harbor 2.6. And we will continue to improve the performance of harbor to make it more enterprise. Thank you. The demo for export CVE, it's a new feature introduced in the harbor 2.6. And this feature can help user export vulnerabilities from project to a CSV file. Here I have one project named the library. And in this project, I have pushed two artifacts, one is ready and another is NGIX. And I have scanned them before, so you can find some vulnerabilities in the ready image. And in the NGIX image, we also scanned some vulnerabilities. And then let's go back to the project page. You just need to click the check box before the project name, and then click the action and click the export CVE. There are two sections for set exporting conditions. One is projects. Currently, we only spot export one project for the performance concern, but maybe we will do some improvement and open for more projects. The next section is filters. Currently, we spot four filters in the project. The first one is repository. You can specify the repository name of artifact, for example, NGIX or Redis. Also, you can use DoubleStar for Fuzing Match. And the next is tags. You can specify your tag name, for example, V1, V2, and so on. And the next one is labels. You can just choose the labels which attach to your artifacts, for example, DEV. And the last filter is CVE ID. You can just input the CVE ID for filter, for example, CVE1234. Then let's keep these filters empty to export all CVEs. Then click the export button. And then you can see the information in the top trigger exporting CVE successfully. And then you can find the execution from the right-side bar event log. You can see the export CVE job is done and successfully. So we can download the file by clicking the icon. Once you download the file, the execution will be cleaned automatically. Then let's open the CSV file. You can see some columns in the CSV file, such as repository, artifact digest, CVE, and package current version and fixed-in version, severity, CVE ID, and additional data and scanner name. The additional data is GSM format column, because different scanners maybe have different outputs. So we put some custom data in this column. Here, in CVE, we put the CVSS file, CVSS information in this column. You can see repository, content index, and radius, because we export all, but we can just export one CVE by specifying the CVE ID. For example, we just want to export this CVE. So let's copy it. And then let's input the CVE ID in the CVE ID. And then let's export it. Let's wait a moment for the execution ready. Okay, it's done. Then let's download it. You can see from the CSV file, there is only one CVE in the different package exported in the CSV file. The CVE is the ID we input in the filters. Okay, so this is the filter for export CVE. Thank you. Thank you, Tanyu. Next item, let me introduce the port and forward audio log. We'll share that screen. As we know, the audio log will allow easy push, pull and delete operations from previous user feedback in GitHub. In a high-concurrent environment, it will allow huge amount of audio logs in the database and consume disk space. In order to save the disk space, the administrators have to manually delete the list record periodically. In 2006, we introduced a new feature named audio log and purge and forward. It helps to create a job service schedule to purge the audio log. Okay, let's go through this feature by demo. In 2006, we introduced a new feature, audio log purge and forward. It helps create a job service schedule to purge the audio log. The previous garbage collection was renamed to cleanup. In the cleanup section, there are two tabs, garbage collection and log location. In log rotation panel, we can select a schedule to purge audio log or run it manually. Also could configure the purge audio log settings. And by default, it will delete all operations. And we can schedule it run by weekly and keep a record in the last one week. And we can run it with dry run. After dry run, we can take logs. Now, 500,000 of the raw will be removed. We can also uncheck the create and delete. Just delete the poor and check the logs after the schedule complete. The only one rows of audio log will be removed. Besides the purge feature, we have a configuration to forward audio log to another log endpoint. It is in a configuration system settings. Let's forward the current log to our Syslog service in another VM. And we are going to delete some repositories. We will generate some audio log. Let's check the audio log in the database. Almost 10 audio logs are created because there are 10 tags in the repository. And we can check it in the remote VM. There is an audio log which contains the information. Now we can see there are a lot of audio log generated for repository 100. Now we are going to delete another repository to generate more audio log. There are audio log generated for the project 002. After configuring the audio log forward endpoint, then you could skip to write the audio log in database. When this option is enabled, then the audio log is no longer logged in the database table. Let's delete some repository in project 003. We will generate some audio log. Now the audio log for project 003 are generated. The logs in the Hub UI displays the audio log in the database. Now we can see that there is no audio log for project 003. It means that when we enable to disable the audio log in the database, we cannot find the audio log in the database anymore. This is the feature for project and forward audio log. Another feature I need to share is the WebAssembly artifact support. It is an experimental feature contributed by community. We need to download a tool named Watson2OCI to push WebAssembly artifact to Harbor. Then we first log in to Harbor with Docker log in. And then we can use the Watson OCI to push the image to Harbor. Okay, it is pushed. Then we can download. We can check it in Harbor. There is a Watson artifact. And we can pull out this by Watson2OCI. It is already in the local. We can compare it with the original one. Hello, Watson2OCI. And here are some test data. Hello, Watson2OCI. They are identical. And we can verify it as all for the WebAssembly artifact support. The last item, backup restore Harbor with Valelo. Let's check it by demo. We have a Harbor instance deployed in Azure Kubernetes. And now we push some images into a library project. Before backup, we should make some changes in current environment. First, we should change the Harbor into read-only mode. Second, because we don't have to backup the readies part, we should exclude readies part PVC and PV by adding labels. Now everything is ready, run a backup command. Once backup complete, we delete the Harbor instance and its PVC, recovered by Valelo restore. Let's check the recovered Harbor instance. Turn off the read-only mode. Previous container image is restored. This is all the new features in Harbor 2006. We are planning the Harbor 2007. It's Vadim to talk about the Harbor 2007 plan. Hi, Vadim. Do you please talk? Should I share my screen? Yeah. All right, so that's good. Let's take a look at what we can expect from Harbor 2007. And on the agenda for 2.7, we have a few new features that were highly demanded from our community. And one of the big chunk in 2.7 is going to be the job service dashboard, which is a new function, completely new functionality that will export or expose the metrics that we currently only expose in Prometoes and that are not actionable. We're going to expose this in the Harbor UI and making them not only visible to the user or administrator, but also actionable. It means that you can overview all the background jobs that are always growing, which at least we have more and more background jobs. So you can now monitor the background job. You can see what is the queue size, the pool size, and you can predict and manage and act upon the jobs that are running in the background. So you're able to stop jobs and pause jobs. And then you can see also your queue and predict if some task will be finished at a certain time. So this allows the administrator to predict the workloads and scale accordingly their instance. So there's going to be a major improvement in Harbor management for the administrators. The next functionality is also towards the management of Harbor and it's about chunk replication. And chunk replication means that when we replicate images from other registries, from ECR or ACR or Docker Hub, we currently replicate by layers. So we replicate one layer after each other. And if there's an error during the replication, it's going to be retried. And so far this has the problem if we see ever-growing image layers for Windows, for example, those layers can be easily in one gigabyte of size. And this means that they're going to be often retry if there is an error and to avoid the retries and also the queue length, we are going to introduce a chunk replication, which means we can resume a failed replication attempt at the point where it failed and not the whole layer. And the next step, we're going to also introduce the replication of GCP artifactory and replication and other... Thank you. What do you? You're welcome. Okay. Could you please let me share a screen? Yeah. Thank you, Vardin. That's all updated from Hubbell Project. If you are Hubbell developers or users, there are a lot of ways to participate in our project. Welcome to open your issues for requests in our project. Ask questions in our Slack channel or join our email group. Thank you for joining this meeting.