 Hello and welcome to this What's New in Quay 3.3 session, where I would like to briefly show you all the great stuff which is coming out with our most recent version of Redhead Quay. I hope that you are as excited as I am because there is really something for everybody in this new release. Let me start with a high-level overview of all the stuff we were introduced with this newer version. The two big features are we will ship an entirely overalled and new version of Clare, the vulnerability scanner, which is used by Clare. We will ship the initial Clare v4 version as a tech preview feature together with Quay. The other thing is the Quay Bridge operator, which runs on all the OpenShift cluster Quay is serving content to and integrates Quay into the various OpenShift workflows and user experience somewhat similar to the existing internal registry user experience. And then there are a couple of other great features we added to the release, such as the elder filtering and the Quay builder enhancements for a better tagging support. We also added a couple of things on the locking side and we introduced two other features as marked as tech preview or experimental, which are probably pretty important for the open source community and for OpenShift and we plan to stabilize and extend them in future releases of Quay as well. And then there's one item we only shipped with the most recent version of OpenShift, we again enhanced the container security operator and the console integration of Rated Quay into the OpenShift console. So let me start with Clare v4. In case you don't know, Clare is not only used by Quay, Crater.org and Project Quay, it's also used by various other products and offerings out there, such as AWS, ECR or VMVarival. We are using Clare as the scaling backend for both Crater.org and Rated Quay. And that's why scalability and sustainability is probably really important for us. And effectively, we obviously skipped the version three because the current version we are using in Quay's V2 is V2. And this has been caused by a decision we made pretty early, basically saying that if we want to support all the items we plan to support or all the support today, then we probably need to change Clare in such a significant way that it might make sense to really refactor the entire application. And that's exactly what we did, right? So we introduced an entirely new manifest oriented API instead of the layer based one we had in the past. And we also introduced an entirely new architecture consisting of Clare Core and the service wrapper. There's a great recording out there which explains the technology changes we did underneath a little bit more detail. We also introduced from an end user perspective, probably the most important thing is that we introduced the support for programming languages. And initially we will start to support Python, probably because Quay has been written in Python. And initial languages are planned for future releases of both Quay and Clare, of course. And another change we did is the way how Clare is integrated or speaks to Quay. And this is now based on content addressable ID to really ensure that it's uniquely identifies the image as a whole in contrast to what we did in previous versions of Quay. So from a side by side comparison, there are a couple of big differences. If you just look at what we've done with Clare version two versus what we do now with version four. So it's no longer in monolithic application. So we extended the reports of the content of the content significantly extended them. We introduced the package manager support. We introduced the support for source RPM package, which is required in order to leverage other security metadata than the ones we've used before. And this finally helps us to detect more vulnerabilities than we found in the previous version of Clare. So those are two screenshots from a demo, which is also available out there, where you can basically see what happens if I scan exactly the same image first using Clare v2 and then as a second step using Clare v4. And you might notice that there is a huge difference in the number of vulnerabilities which have been found. And this is not only caused by the Python application vulnerabilities which have been found, but also it includes a couple of vulnerabilities on the OS level stack because we are now using the extended security metadata provided by the vendors of those distributions. And this effectively helps us to have a broader content coverage than we had before. Another big thing we introduced is the Quay Bridge Operator. In the past, we sometimes called it the Quay OpenShift Integration Operator. We just readied it. And this is an operator we really built in very strong collaboration with both our internal communities and the customer community as well. So out of the box, it supports, of course, multi-cluster setup. It has to because the primary purpose of Quay is to serve content to multiple OpenShift clusters and it also features an OpenShift built integration to change a couple of things which otherwise you would have to configure manually. So from a very high level perspective, an OpenShift namespace or the equivalent to an OpenShift namespace is a Quay organization and there are a couple of downsides associated with this simple mapping. So an organization is also used as a tenant, which means in order to create a new organization, we need to ensure that the different users and teams in this organization are mapped to the corresponding permissions on the OpenShift side. So basically what we do here is if it was in OpenShift, somebody creates a new project, we automatically create the corresponding organization within Quay and then automatically creates three different robot accounts in this organization. One was wide permission and two others was big permission. The support for multi-cluster setups is, of course, important because we need to avoid that there are any name collisions because obviously the organization name within a Quay registry needs to be unique. And we also do all the magic which is required in order to have the secrets management on the OpenShift side. So the robot account tokens are stored as a secret, automatically the service accounts are configured. And we also change the built configuration in order to leverage now Quay as the output destination for all images which have been built on OpenShift. And the key takeaway is if you're using the Quay Bridge operator, then you probably don't need to use the OpenShift internal registry anymore, at least not for those builds which are executed in this way using the Quay Bridge operator. Yeah, so it runs on all the OpenShift clusters Quay serving content to it. So it's not limited to the OpenShift cluster where Quay is running on, but it's really about all the other clusters Quay is serving content. So in a couple of sample use cases are shown here. So I already explained the new project, of course, the same applies to a new application or to a new deployment and so on and so on. So there are plenty of use cases we will cover with the Bridge operator and we will extend the list and amount of those use cases over time in future versions. It's important to call out that in its current version, so the initial version we will ship as part of 3.3, there are a couple of manual steps required before you can initially deploy the Quay Bridge operator on an OpenShift cluster. All of them are called out in the operator description shown in the embedded operator hub. So you just need to go through those description. We also did a recording explaining those a little bit in further detail as well. The other operator we already introduced with Quay Sweeter 2 is the Quay operator, formerly known as the Quay setup operator. But since operators are primarily to ensure a better day to experience, we effectively renamed it because obviously the Quay operator has not been written just for the initial deployment, but it's also supposed to take care on their two aspects. And this is exactly the thing we changed now with the newer version of the Quay operator. Now the operator becomes aware of the changes which happen in the background either using the Quay config app or if really needed the changes directly happen in the Quay config Yama file as well. So the operator now is responsible for managing a couple of Quay specific items, which means in the future versions those files will even be marked as read-only in the config app to really reflect those items have to be managed via the operator. We simplified a couple of things. We changed a couple of things. We extended the capabilities. But the biggest change is really that now both the config app and the operator doesn't need to be stopped or killed anymore. So you can continue to run both and use both side by side. Again, you also can directly edit the config Yama file, which is absolutely not recommended, but it's still an option. And for some of the changes which either happen while the config app or the config Yama file, the operator even does a reconciliation loop for those changes, which is pretty thoughtful. And as I said, we will continue the list of all those changes and a better management over time. And then there are two features on the log management side. So one is the log exporter and the other one is the log square elastic search. So let me start with the log exporter. What the log exporter feature provides, you can basically go through the query UI or you can also use the API and you can define what kind of logs I wanna export. So you can define a date range and whether you're using the export, the log exporter feature on a repository or on an accession level. This of course has an impact on the amount of log files which are captured and then exported. So there are two main export methods. The first one is email, then you get effectively a chase and output attached to the email. This of course requires that the email have been configured properly in your query deployment. And the other method is using a callback URL and then you get notified how and where to pull those export and log files from it as three buckets, which is pretty powerful as well. On the road where we have another item which hasn't found its way into the sweet.swe release, which is that those log exporting functions are triggered or tracked in the audit log as well. Another feature we originally developed for Quater.io is instead of storing all the audit logs in the database, we basically move them out into an elastic search stack which allows us to of course, way better scale than we did before. And this is especially required for large scale query deployments and we have plenty of customers who are using Quater.io at scale. And that's why this feature is really pretty important. So from an end user standpoint, looking at UI, nothing changes, it's just a change which happens in the backend. Instead of pushing the logs to post squares, we are pushing them to elastic, but still in the UI, you can see the same audit logs, you can see the same information, the same statistics, nothing really changes from a user perspective. In addition to just moving the logs out to elastic search, you can also use an alternative log producer. So currently it's Kinesis only. In future version, we consider to also support Kafka based deployment as well. So basically you just need to configure the log storage configuration. So there's a new section in the query config app and then you need to follow the data and the same for Kinesis if you plan to use it and that's it and starting from there, the logs are no longer stored in the database and it's that pushed to elastic search. As I mentioned, we already shipped together with the newest version of OpenShift, a couple of changes and extensions for the OpenShift console. Effectively, we now have a couple of additional list views. We have the pod views, really the vulnerability information associated with a particular pod and we also have a couple of other views we added to the OpenShift console and there's a very good blog post out there written by our user experience team, which describes all those changes and new things we added with OpenShift's newest version. Another feature we introduced is elder filtering. So users who are using elder or active directory as their authentication backend can now restrict the access to Quay with a couple of things they can specify so that they can specify a specific elder filter and then the result is stored in the config file and starting from there, only the users which are matching those filter rules can log in into Quay. Another feature we introduced, which is pretty powerful as well, is a custom tagging for the builders. So it's important to note that in the past we have been very opinionated on the way how we defined the resulting tags of an image which has been built while Quay built automation. So it has been either the branch name of what the branch which has triggered the build or it has been the latest tag if it was the default branch. And now we're allowed to specify custom tags. So you can deselect the default rules and then you can specify your custom tags and this could be a static tag or a dynamically template tag. So it's pretty powerful in order to have more sophisticated ways to tag. And of course you can combine them and use multiple of them side by side. Another feature which is marked as tag preview as of today, simply because the OCI distribution spec is still not an official standard yet. We introduced the full support of the OCI distribution spec as it exists today. And this probably makes us the first open source registry both hosted on on-prem, which does support the OCI distribution spec in its current form. And this also allows us to do a couple of things. So the OCI minetime support has been pretty important for us because we are driving a couple of things on the Reddit side such as source container which require the minetime support. Initially some of the OCI provided tests didn't pass and we submitted PRs in order to fix them. In the meantime, most of those PRs have been, have got accepted by the OCI initiative and that's why we are really proud that this has been passed now and we don't expect any really big changes before the final OCI distribution spec comes out. So probably from day one, we will be able to support the OCI spec after it has been finalized and published. Another feature which is not even experimental but which is not even tech preview but experimental is the support for the OCI artifact spec. So this is another initiative driven by OCI which is primarily driven by Microsoft, IBM, Red Hat and Docker. And the goal here is that the goal of the spec is to allow that you can store arbitrary content types in the registry so it's no longer limited to images which also includes home charts, senior bundles, companies deployment templates, open ship deployment templates, whatever else. So one of the co-founders and the lead architect of Reddit Quay is one of the maintainers of the spec and this of course enabled us to have a very early implementation and effectively working closely with the home community allowed us to introduce an initial home v3 chart support as an experimental feature and experimental really on both the Quay and the home client side. It's not available on Quader yet because Quader was a production environment and we do not enable experimental or even tech preview features or even the OCI mine type support is only enabled on selected namespace. So which means you need to enable or switch on a feature which is clearly marked as experimental on both the Quay side in the Config Yama file and on the home client side. And as of today, it's just for us, it's a very early pilot. We wanna get it out as early as we can in order to gather additional feedback and input from the community and our end users. We don't have any specific UI support which means if you go to the Quay UI and push a home chart there, then from a UI perspective, the home chart looks similar like an image but if you try to docker pull the home chart, obviously it will fail. Of course, we will change and improve this over time but keep in mind, there is a certain risk that there won't be any upgrade path from the experimental status to the final production version. We hopefully ship in one of the future versions of Quay. So technically, you should be able to run a couple of commands against Quay for home charts as you previously did for container images. You can log in and log out to the registry. You can push and pull those home charts as you do for container images. Again, it's experimental feature. We are working closely with the Upsun community in order to improve this over time. And this is the last slide. In addition to all the stuff we introduced, we continue to deprecate a couple of features which are no longer used, no longer maintainable or just they are not needed anymore. With the previous version, we already started the deprecation of rocket conversion, bit torn distribution and the Docker V1 push support and with this release now for the Upsun, for the downstream product, we started to deprecation of squashing the application registry, which is hopefully being replaced with the artifact spec support. We just talked about it. We deprecated the images API. Obviously this has been replaced by the manifest API and we started to deprecate the commercial support for NFS with this newest version of Reddit Quay. And this brings me to an end. Thanks for watching and enjoy our newest version of Reddit Quay.