 Hello, my name is Andrew Sullivan and I'm with the Red Hat Cloud Platforms Business Unit. Today we're going to be looking at the OpenShift 4 image registry. The image registry with OpenShift 4 changes, so that is now managed by a cluster operator. Cluster operators are viewed and managed through the cluster console. By viewing the cluster operators we can see the overall health of the registry operator. On this screen we can see high level information about the operator's health. In particular, when we look at lines 13 through 20 we can see the health of the operator. We can see how it progressed from not being available to having at least minimum availability. In order to view the configuration for our operator we browse to the custom resource definitions. Configuration for the registry is stored in a CRD known as config under the image registry.operator.openshift.io group. Inside of this CRD we can see all kinds of information about our operator. In particular, under the spec section we can see the user configurable options. This example is a default deployment, no modification has been done at this point. Starting at line 27 and below we can see the current status of the specific services for the image registry. Where the cluster operator provided a high level overview of status, the CRD provides low level details as to what may or may not be failing or available for the image registry. The resources for the image registry are kept in a project called openshift-image-registry. This contains not only the image registry deployment but also the operator deployment. We can browse the operator deployment and see that there is a single pod which has been deployed and is available. In the event of errors we would be able to look at this pod's logs in order to determine what may be going wrong. We can also browse to the image registry deployment itself. The number of pods managed by this deployment will match the number of replicas configured in the custom resource definition. Like other services we can view and inspect the status and logs of the image registry service using these pods. However, changing the configuration of the pods or the deployment will be overwritten by the custom resource definition and the operator. Here we can see that a service is created by the operator. However, the operator does not configure a route by default. This means that external access has not been enabled at this point. In order to enable external access we will modify the custom resource definition to request the default route be created. Under the spec section of the document we can add an option. Default route equals true. Custom routes are also an option referred to the documentation on how to configure these correctly. Once the configuration has been changed the operator will automatically take action to match the requested configuration. In this instance a route has been configured enabling public access to the image registry. Here we can see the URL generated by the default route. The operator based deployment of the registry also configures metrics collection automatically. There are no default Grafana dashboards available. However, we can use Prometheus graphs to view individual statistics. The statistics collected from the registry are put into a Prometheus namespace of image registry. For this statistic Prometheus presents a graph of quantiles. The 50th, 90th and 99th percentile. Be sure to create Grafana dashboards that focus on the information you're interested in for registry health and other information. Thank you for joining me today. Please be sure to watch for more videos about OpenShift 4 functionality in the future.