Red Hat OpenShift Quay | OpenShift, 11 Aug 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Red Hat Quay 3.9 demo: New Storage Consumption Tracking

Description

In this demo we will demonstrate how the new storage consumption tracking implementation in Red Hat Quay 3.9 leads to more accurate and more correct representation of the storage used up by your container images.

Learn more: https://www.redhat.com/en/technologies/cloud-computing/quay

A

Hello, my name is Dave O'connor and in this demo, I'm going to show off the new quota features in quay39 quota was originally released in quay37, but with three nine we've made a few adjustments and improvements in order to access these changes in three nine, please make sure to configure the following four options in the config yaml.

A

These options include feature quota management, feature, garbage collection, garbage collection, frequency and quota total delay seconds.

A

For this demo, I have a Quay 39 instance already running to begin. Let's review the fixes. First up is empty repositories. Previously empty repositories were erroneously, showing something was taking up space. Let's create a new organization and verify that this has been fixed.

A

And just as we expect, no storage is calculated.

A

Next up quota has previously counted duplicate layers, meaning that a larger total was reported than what was actually stored on disk. Let's create a new repository for Claire and push up some duplicate images.

A

A

Here we see the size of each tag is the same, but if we navigate navigate to the organization view, the overall storage is equal to only one of the images. This is because we are no longer counting duplicate layers. Now, let's see what happens if we push an image with a shared layer.

A

So from the tags list, we see that the image size is similar to the other tags. However, if we look at the total storage- that's now consumed by the organization, it doesn't add up. This is because we are no longer counting duplicate layers.

A

Next up is Manifest lists. When we originally implemented quota, it did not calculate storage for manifest lists. In practice, this meant that the storage value we showed was smaller than it should have been. We have fixed this and multi-arc images are now calculated correctly. Let's use scopio to copy the Manifest list into our registry.

A

First, we should create our org and our repo, we'll use Alpine.

A

We can see seven different architectures each about three megabits in size, but if we go back to the organization, the total is about 21 megabits, just as we'd expect.

A

Lastly, something we've previously something new that we've provided is a way to view storage for the entire koi instance. It's important to know that this feature is only available to Super users and may be resource intensive, depending on the amount of images present in Quay in order to prevent potential disruption to The Quay instance. We've made it so that this calculation is only available on demand in the super user panel. Let me sign out and log in as a super user.

A

All you need to do is Click calculate and then refresh the page for the total to update this may take some time to calculate, depending on the size of the instance.

A

Perfect and as you can see, the Claire and the Alpine organizations have both been summed up and it's about 92 megabits. That concludes this demo.