Applications

Procedure

1. Navigate to Home → Projects.
2. Click Create Project.
3. Enter your project details.
4. Click Create.

1. Click the Project drop-down menu to see a list of all available projects. Select Create Project.

   
2. In the Create Project dialog box, enter a unique name, such as myproject, in the Name field.
3. Optional: Add the Display Name and Description details for the project.
4. Click Create.
5. Use the left navigation panel to navigate to the Project view and see the dashboard for your project.

6. Optional:

   • Use the Project drop-down menu at the top of the screen and select all projects to list all of the projects in your cluster.
   • Use the Details tab to see the project details.
   • If you have adequate permissions for a project, you can use the Project Access tab to provide or revoke administrator, edit, and view privileges for the project.

Procedure

1. Run:

Procedure

1. Navigate to Home → Projects.

2. Select a project to view.

   On this page, click the Workloads button to see workloads in the project.

Procedure

1. To view a list of projects, run:

   $ oc get projects

2. You can change from the current project to a different project for CLI operations. The specified project is then used in all subsequent operations that manipulate project-scoped content:

   $ oc project <project_name>

1. In the Developer perspective, navigate to the Advanced → Project Access page.

2. In the Project Access page, click Add Access to add a new row.

   
3. Enter the user name, click the Select a role drop-down list, and select an appropriate role.
4. Click Save.

Procedure

1. Select Developer from the context selector at the top of the web console navigation menu.
2. Click +Add
3. At the top of the page, select the name of the project that you want to add to.
4. Click on a method for adding to your project, and then follow the workflow.

Procedure

1. Navigate to Home → Projects.
2. Select a project to see its status.

Procedure

1. Run:

   $ oc status

   This command provides a high-level overview of the current project, with its components and their relationships.

Procedure

1. Navigate to Home → Projects.
2. Locate the project that you want to delete from the list of projects.
3. On the far right side of the project listing, select Delete Project from the Options menu .
4. When the Delete Project pane opens, enter the name of the project that you want to delete in the field.
5. Click Delete.

Procedure

1. Run:

   $ oc delete project <project_name>

Procedure

1. Log in as a user with cluster-admin privileges.

2. Generate the default project template:

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. Use a text editor to modify the generated template.yaml file by adding objects or modifying existing objects.

4. The project template must be created in the openshift-config namespace. Load your modified template:

   $ oc create -f template.yaml -n openshift-config

5. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

6. Update the spec section to include the projectRequestTemplate and name parameters, and set the name of your uploaded project template. The default name is project-request.

   Project configuration resource with custom project template

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. After you save your changes, create a new project to verify that your changes were successfully applied.

Procedure

1. Log in as a user with cluster-admin privileges.

2. View the self-provisioners cluster role binding usage by running the following command:

   $ oc describe clusterrolebinding.rbac self-provisioners
   
   Name:		self-provisioners
   Labels:		<none>
   Annotations:	rbac.authorization.kubernetes.io/autoupdate=true
   Role:
     Kind:	ClusterRole
     Name:	self-provisioner
   Subjects:
     Kind	Name				Namespace
     ----	----				---------
     Group	system:authenticated:oauth

   Review the subjects in the self-provisioners section.

3. Remove the self-provisioner cluster role from the group system:authenticated:oauth.

   • If the self-provisioners cluster role binding binds only the self-provisioner role to the system:authenticated:oauth group, run the following command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{"subjects": null}'

   • If the self-provisioners cluster role binding binds the self-provisioner role to more users, groups, or service accounts than the system:authenticated:oauth group, run the following command:

     $ oc adm policy \
         remove-cluster-role-from-group self-provisioner \
         system:authenticated:oauth

4. Edit the self-provisioners cluster role binding to prevent automatic updates to the role. Automatic updates reset the cluster roles to the default state.

   • To update the role binding using the CLI:

     1. Run the following command:

        $ oc edit clusterrolebinding.rbac self-provisioners

     2. In the displayed role binding, set the rbac.authorization.kubernetes.io/autoupdate parameter value to false, as shown in the following example:

        apiVersion: authorization.openshift.io/v1
        kind: ClusterRoleBinding
        metadata:
          annotations:
            rbac.authorization.kubernetes.io/autoupdate: "false"
          ...

   • To update the role binding by using a single command:

     $ oc patch clusterrolebinding.rbac self-provisioners -p '{ "metadata": { "annotations": { "rbac.authorization.kubernetes.io/autoupdate": "false" } } }'

5. Login as an authenticated user and verify that it can no longer self-provision a project:

   $ oc new-project test
   
   Error from server (Forbidden): You may not request a new project via this API.

   Consider customizing this project request message to provide more helpful instructions specific to your organization.

Procedure

1. Edit the project configuration resource using the web console or CLI.

   • Using the web console:

     1. Navigate to the Administration → Cluster Settings page.
     2. Click Global Configuration to view all configuration resources.
     3. Find the entry for Project and click Edit YAML.

   • Using the CLI:

     1. Log in as a user with cluster-admin privileges.

     2. Edit the project.config.openshift.io/cluster resource:

        $ oc edit project.config.openshift.io/cluster

2. Update the spec section to include the projectRequestMessage parameter and set the value to your custom message:

   Project configuration resource with custom project request message

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: <message_string>

   For example:

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestMessage: To request a project, contact your system administrator at projectname@example.com.

3. After you save your changes, attempt to create a new project as a developer or service account that is unable to self-provision projects to verify that your changes were successfully applied.

Procedure

1. In the Add view, click From Git to see the Import from git form.
2. In the Git section, enter the Git repository URL for the codebase you want to use to create an application. For example, enter the URL of this sample Node.js application https://github.com/sclorg/nodejs-ex. The URL is then validated.

3. Optional: You can click Show Advanced Git Options to add details such as:

   • Git Reference to point to code in a specific branch, tag, or commit to be used to build the application.
   • Context Dir to specify the subdirectory for the application source code you want to use to build the application.
   • Source Secret to create a Secret Name with credentials for pulling your source code from a private repository.
4. In the Builder section, after the URL is validated, an appropriate builder image is detected, indicated by a star, and automatically selected. For the https://github.com/sclorg/nodejs-ex Git URL, the Node.js builder image is selected by default. If required, you can change the version using the Builder Image Version drop-down list.

5. In the General section:

   1. In the Application field, enter a unique name for the application grouping, for example, myapp. Ensure that the application name is unique in a namespace.

   2. The Name field to identify the resources created for this application is automatically populated based on the Git repository URL.

      Note

      The resource name must be unique in a namespace. Modify the resource name if you get an error.

6. In the Resources section, select:

   • Deployment, to create an application in plain Kubernetes style.
   • Deployment Config, to create an OpenShift style application.
   • Knative Service, to create a microservice.
   Note

   The Knative Service option is displayed in the Import from git form only if the Serverless Operator is installed in your cluster. For further details refer to documentation on installing OpenShift Serverless.

7. In the Advanced Options section, the Create a route to the application is selected by default so that you can access your application using a publicly available URL. You can clear the check box if you do not want to expose your application on a public route.

8. Optional: You can use the following advanced options to further customize your application:

   Routing

   Click the Routing link to:

   • Customize the hostname for the route.
   • Specify the path the router watches.
   • Select the target port for the traffic from the drop-down list.

   • Secure your route by selecting the Secure Route check box. Select the required TLS termination type and set a policy for insecure traffic from the respective drop-down lists.

     For serverless applications, the Knative Service manages all the routing options above. However, you can customize the target port for traffic, if required. If the target port is not specified, the default port of 8080 is used.

   Build and Deployment Configuration

   Click the Build Configuration and Deployment Configuration links to see the respective configuration options. Some of the options are selected by default; you can customize them further by adding the necessary triggers and environment variables. For serverless applications, the Deployment Configuration option is not displayed as the Knative configuration resource maintains the desired state for your deployment instead of a DeploymentConfig.

   Scaling

   Click the Scaling link to define the number of Pods or instances of the application you want to deploy initially.

   For serverless applications, you can:

   • Set the upper and lower limit for the number of pods that can be set by the autoscaler. If the lower limit is not specified, it defaults to zero.
   • Define the soft limit for the required number of concurrent requests per instance of the application at a given time. It is the recommended configuration for autoscaling. If not specified, it takes the value specified in the cluster configuration.
   • Define the hard limit for the number of concurrent requests allowed per instance of the application at a given time. This is configured in the revision template. If not specified, it defaults to the value specified in the cluster configuration.

   Resource Limit

   Click the Resource Limit link to set the amount of CPU and Memory resources a container is guaranteed or allowed to use when running.

   Labels

   Click the Labels link to add custom labels to your application.

9. Click Create to create the application and see its build status in the Topology view.

Procedure

1. Create a new project in the OpenShift Container Platform web console for this procedure. This example uses a project called my-etcd.

2. Navigate to the Operators → Installed Operators page. The Operators that have been installed to the cluster by the cluster administrator and are available for use are shown here as a list of ClusterServiceVersions (CSVs). CSVs are used to launch and manage the software provided by the Operator.

   Tip

   You can get this list from the CLI using:

   $ oc get csv

3. On the Installed Operators page, click Copied, and then click the etcd Operator to view more details and available actions:

   Figure 2.1. etcd Operator overview

   

   As shown under Provided APIs, this Operator makes available three new resource types, including one for an etcd Cluster (the EtcdCluster resource). These objects work similar to the built-in native Kubernetes ones, such as Deployments or ReplicaSets, but contain logic specific to managing etcd.

4. Create a new etcd cluster:

   1. In the etcd Cluster API box, click Create New.
   2. The next screen allows you to make any modifications to the minimal starting template of an EtcdCluster object, such as the size of the cluster. For now, click Create to finalize. This triggers the Operator to start up the Pods, Services, and other components of the new etcd cluster.

5. Click the Resources tab to see that your project now contains a number of resources created and configured automatically by the Operator.

   Figure 2.2. etcd Operator resources

   

   Verify that a Kubernetes service has been created that allows you to access the database from other Pods in your project.

6. All users with the edit role in a given project can create, manage, and delete application instances (an etcd cluster, in this example) managed by Operators that have already been created in the project, in a self-service manner, just like a cloud service. If you want to enable additional users with this ability, project administrators can add the role using the following command:

   $ oc policy add-role-to-user edit <user> -n <target_project>

Procedure

1. Create and deploy the MongoDB service to your project as follows:

   1. In the Developer perspective, navigate to the Add view and select the Database option to see the Developer Catalog, which has multiple options that you can add as components or services to your application.
   2. Click on the MongoDB option to see the details for the service.
   3. Click Instantiate Template to see an automatically populated template with details for the MongoDB service, and click Create to create the service.
2. On the left navigation panel, click Topology to see the MongoDB service deployed in your project.
3. To add the MongoDB service to the existing application group, select the mongodb Pod and drag it to the application; the MongoDB service is added to the existing application group.

4. Dragging a component and adding it to an application group automatically adds the required labels to the component. Click on the MongoDB service node to see the label app.kubernetes.io/part-of=myapp added to the Labels section in the Overview Panel.

   

1. To add the MongoDB service to your application, click on the mongodb Pod to see the Overview panel to the right.
2. Click the Actions drop-down menu on the upper right of the panel and select Edit Application Grouping.
3. In the Edit Application Grouping dialog box, click the Select an Application drop-down list, and select the appropriate application group.
4. Click Save to see the MongoDB service added to the application group.

1. Click the application you want to delete to see the side panel with the resource details of the application.
2. Click the Actions drop-down menu displayed on the upper right of the panel, and select Delete Application to see a confirmation dialog box.
3. Enter the name of the application and click Delete to delete it.

Procedure

1. Enable the service catalog API server.

   1. Use the following command to edit the service catalog API server resource.

      $ oc edit servicecatalogapiservers

   2. Under spec, set the managementState field to Managed:

      spec:
        logLevel: Normal
        managementState: Managed

   3. Save the file to apply the changes.

      The Operator installs the service catalog API server component. As of OpenShift Container Platform 4, this component is installed into the openshift-service-catalog-apiserver namespace.

2. Enable the service catalog controller manager.

   1. Use the following command to edit the service catalog controller manager resource.

      $ oc edit servicecatalogcontrollermanagers

   2. Under spec, set the managementState field to Managed:

      spec:
        logLevel: Normal
        managementState: Managed

   3. Save the file to apply the changes.

      The Operator installs the service catalog controller manager component. As of OpenShift Container Platform 4, this component is installed into the openshift-service-catalog-controller-manager namespace.

1. Create a namespace.

   1. Navigate in the web console to Administration → Namespaces and click Create Namespace.

   2. Enter openshift-template-service-broker in the Name field and click Create.

      Note

      The namespace must start with openshift-.

2. Navigate to the Operators → OperatorHub page. Verify that the openshift-template-service-broker project is selected.
3. Select Template Service Broker Operator.
4. Read the information about the Operator and click Install.
5. Review the default selections and click Subscribe.

Procedure

1. Navigate in the web console to Operators → Installed Operators and select the openshift-template-service-broker project.
2. Select the Template Service Broker Operator.
3. Under Provided APIs, click Create New for Template Service Broker.
4. Review the default YAML and click Create.

5. Verify that the Template Service Broker has started.

   After the Template Service Broker has started, you can view the available template applications by navigating to Catalog → Developer Catalog and selecting the Service Class checkbox. Note that it may take a few minutes for the Template Service Broker to start and the template applications to be available.

   If you do not yet see these Service classes, you can check the status of the following items:

   • Template Service Broker Pod status

     • From the Workloads → Pods page for the openshift-template-service-broker project, verify that the Pod that starts with apiserver- has a status of Running and readiness of Ready.

   • Cluster service broker status

     • From the Catalog → Broker Management → Service Brokers page, verify that the template-service-broker service broker has a status of Ready.

   • Service catalog controller manager Pod logs

     • From the Workloads → Pods page for the openshift-service-catalog-controller-manager project, review the logs for each of the Pods and verify that you see a log entry with the message Successfully fetched catalog entries from broker.

Procedure

1. Create a project.

   1. Navigate in the web console to Home → Projects and click Create Project.
   2. Enter test-postgresql in the Name field and click Create.

2. Create a service instance.

   1. Navigate to the Catalog → Developer Catalog page.
   2. Select the PostgreSQL (Ephemeral) template application and click Create Service Instance.
   3. Review the default selections and set any other required fields, and click Create.

   4. Go to Catalog → Provisioned Services and verify that the postgresql-ephemeral service instance is created and has a status of Ready.

      You can check the progress on the Home → Events page. After a few moments, you should see an event for postgresql-ephemeral with the message "The instance was provisioned successfully".

3. Create a service binding.

   1. From the Provisioned Services page, click postgresql-ephemeral and click Create Service Binding.

   2. Review the default service binding name and click Create.

      This creates a new secret for binding using the name provided.

4. Review the secret that was created.

   1. Navigate to Workloads → Secrets and verify that a secret named postgresql-ephemeral was created.
   2. Click postgresql-ephemeral and review the key-value pairs in the Data section, which are used for binding to other apps.

1. Uninstall the Template Service Broker.

   1. Navigate to Operators → Installed Operators and select the openshift-template-service-broker project from the drop-down menu.
   2. Click Template Service Broker Operator.
   3. Select the Template Service Broker tab.
   4. Click template-service-broker.
   5. From the Actions drop-down menu, select Delete Template Service Broker.

   6. Click Delete from the confirmation pop-up window.

      The Template Service Broker is now uninstalled, and template applications will soon be removed from the Developer Catalog.

2. Uninstall the Template Service Broker Operator.

   1. From the Operators → Installed Operators page, scroll or type a keyword into the Filter by name to find the Template Service Broker Operator, then click on it.
   2. On the right-hand side of the Operator Details page, select Uninstall Operator from the Actions drop-down menu.
   3. When prompted by the Remove Operator Subscription window, optionally select the Also completely remove the Operator from the selected namespace check box if you want all components related to the installation to be removed. This removes the CSV, which in turn removes the Pods, Deployments, CRDs, and CRs associated with the Operator.
   4. Select Remove. This Operator will stop running and no longer receive updates. The Template Service Broker Operator is no longer installed in your cluster.

1. A user requests the list of available applications from the service catalog using the OpenShift Container Platform web console.
2. The service catalog requests the list of available applications from the OpenShift Ansible Broker.
3. The OpenShift Ansible Broker communicates with a defined container image registry to learn which APBs are available.
4. The user issues a request to provision a specific APB.
5. The OpenShift Ansible Broker fulfills the user’s provision request by invoking the provision method on the APB.

1. Create a namespace.

   1. Navigate in the web console to Administration → Namespaces and click Create Namespace.

   2. Enter openshift-ansible-service-broker in the Name field and openshift.io/cluster-monitoring=true in the Labels field and click Create.

      Note

      The namespace must start with openshift-.

2. Create a cluster role binding.

   1. Navigate to Administration → Role Bindings and click Create Binding.
   2. For the Binding Type, select Cluster-wide Role Binding (ClusterRoleBinding).
   3. For the Role Binding, enter ansible-service-broker in the Name field.
   4. For the Role, select admin.
   5. For the Subject, choose the Service Account option, select the openshift-ansible-service-broker namespace, and enter openshift-ansible-service-broker-operator in the Subject Name field.
   6. Click Create.

3. Create a secret to connect to the Red Hat Container Catalog.

   1. Navigate to Workloads → Secrets. Verify that the openshift-ansible-service-broker project is selected.
   2. Click Create → Key/Value Secret.
   3. Enter asb-registry-auth as the Secret Name.
   4. Add a Key of username and a Value of your Red Hat Container Catalog user name.
   5. Click Add Key/Value and add a Key of password and a Value of your Red Hat Container Catalog password.
   6. Click Create.
4. Navigate to the Operators → OperatorHub page. Verify that the openshift-ansible-service-broker project is selected.
5. Select OpenShift Ansible Service Broker Operator.
6. Read the information about the Operator and click Install.
7. Review the default selections and click Subscribe.

Procedure

1. Navigate in the web console to Operators → Installed Operators and select the openshift-ansible-service-broker project.
2. Select the OpenShift Ansible Service Broker Operator.
3. Under Provided APIs, click Create New for Automation Broker.

4. Add the following to the spec field in the default YAML provided:

   registry:
     - name: rhcc
       type: rhcc
       url: https://registry.redhat.io
       auth_type: secret
       auth_name: asb-registry-auth

   This references the secret that was created when installing the OpenShift Ansible Service Broker Operator, which allows you to connect to the Red Hat Container Catalog.

5. Set any additional OpenShift Ansible Broker configuration options and click Create.

6. Verify that the OpenShift Ansible Broker has started.

   After the OpenShift Ansible Broker has started, you can view the available service bundles by navigating to Catalog → Developer Catalog and selecting the Service Class checkbox. Note that it may take a few minutes for the OpenShift Ansible Broker to start and the service bundles to be available.

   If you do not yet see these Service classes, you can check the status of the following items:

   • OpenShift Ansible Broker Pod status

     • From the Workloads → Pods page for the openshift-ansible-service-broker project, verify that the Pod that starts with asb- has a status of Running and readiness of Ready.

   • Cluster service broker status

     • From the Catalog → Broker Management → Service Brokers page, verify that the ansible-service-broker service broker has a status of Ready.

   • Service catalog controller manager Pod logs

     • From the Workloads → Pods page for the openshift-service-catalog-controller-manager project, review the logs for each of the Pods and verify that you see a log entry with the message Successfully fetched catalog entries from broker.

1. Navigate in the web console to Operators → Installed Operators and select the ansible-service-broker project.
2. Select the OpenShift Ansible Service Broker Operator.
3. On the Automation Broker tab, select ansible-service-broker.

4. On the YAML tab, add or update any OpenShift Ansible Broker configuration options under the spec field.

   For example:

   spec:
     keepNamespace: true
     sandboxRole: edit

5. Click Save to apply these changes.

Procedure

1. Create the role.

   1. Navigate to Administration → Roles and click Create Role.

   2. Replace the YAML in the editor with the following:

      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: prometheus-k8s
        namespace: openshift-ansible-service-broker
      rules:
      - apiGroups:
        - ""
        resources:
        - services
        - endpoints
        - pods
        verbs:
        - get
        - list
        - watch

   3. Click Create.

2. Create the role binding.

   1. Navigate to Administration → Role Bindings and click Create Binding.
   2. For the Binding Type, select Namespace Role Binding (RoleBinding).
   3. For the Role Binding, enter prometheus-k8s in the Name field and openshift-ansible-service-broker in the Namespace field.
   4. For the Role, select prometheus-k8s.
   5. For the Subject, choose the Service Account option, select the openshift-monitoring namespace, and enter prometheus-k8s in the Subject Name field.
   6. Click Create.

Procedure

1. Create a project.

   1. Navigate in the web console to Home → Projects and click Create Project.
   2. Enter test-postgresql-apb in the Name field and click Create.

2. Create a service instance.

   1. Navigate to the Catalog → Developer Catalog page.
   2. Select the PostgreSQL (APB) service bundle and click Create Service Instance.
   3. Review the default selections and set any other required fields, and click Create.

   4. Go to Catalog → Provisioned Services and verify that the dh-postgresql-apb service instance is created and has a status of Ready.

      You can check the progress on the Home → Events page. After a few moments, you should see an event for dh-postgresql-apb with the message "The instance was provisioned successfully".

3. Create a service binding.

   1. From the Provisioned Services page, click dh-postgresql-apb and click Create Service Binding.

   2. Review the default service binding name and click Create.

      This creates a new secret for binding using the name provided.

4. Review the secret that was created.

   1. Navigate to Workloads → Secrets and verify that a secret named dh-postgresql-apb was created.
   2. Click dh-postgresql-apb and review the key-value pairs in the Data section, which are used for binding to other apps.

1. Uninstall the OpenShift Ansible Broker.

   1. Navigate to Operators → Installed Operators and select the openshift-ansible-service-broker project from the drop-down menu.
   2. Click OpenShift Ansible Service Broker Operator.
   3. Select the Automation Broker tab.
   4. Click ansible-service-broker.
   5. From the Actions drop-down menu, select Delete Automation Broker.

   6. Click Delete from the confirmation pop-up window.

      The OpenShift Ansible Broker is now uninstalled, and service bundles will soon be removed from the Developer Catalog.

2. Uninstall the OpenShift Ansible Service Broker Operator.

   1. From the Operators → Installed Operators page, scroll or type a keyword into the Filter by name to find the OpenShift Ansible Service Broker Operator, then click on it.
   2. On the right-hand side of the Operator Details page, select Uninstall Operator from the Actions drop-down menu.
   3. When prompted by the Remove Operator Subscription window, optionally select the Also completely remove the Operator from the selected namespace check box if you want all components related to the installation to be removed. This removes the CSV, which in turn removes the Pods, Deployments, CRDs, and CRs associated with the Operator.
   4. Select Remove. This Operator will stop running and no longer receive updates.

1. The elements of a ReplicationController definition.
2. Triggers for creating a new deployment automatically.
3. The strategy for transitioning between deployments.
4. Lifecycle hooks.

1. Executes any pre lifecycle hook.
2. Scales up the new ReplicationController based on the surge count.
3. Scales down the old ReplicationController based on the max unavailable count.
4. Repeats this scaling until the new ReplicationController has reached the desired replica count and the old ReplicationController has been scaled to zero.
5. Executes any post lifecycle hook.

1. Executes any pre lifecycle hook.
2. Scales down the previous deployment to zero.
3. Executes any mid lifecycle hook.
4. Scales up the new deployment.
5. Executes any post lifecycle hook.

1. In the Actions drop-down menu, select Edit Deployment Config to see the deployment configuration details of the application.
2. In the YAML editor, change the spec.strategy.type to Recreate and click Save.
3. In the Topology view, select the node to see the Overview tab in the side panel. The Update Strategy is now set to Recreate.

4. Use the Actions drop-down menu to select Start Rollout to start an update using the Recreate strategy. The Recreate strategy first terminates Pods for the older version of the application and then spins up Pods for the new version.

   

Procedure

1. Define the quota in a file.

2. Use the file to create the quota and apply it to a project:

   $ oc create -f <file> [-n <project_name>]

   For example:

   $ oc create -f core-object-counts.yaml -n demoproject

Procedure

1. Get the list of quotas defined in the project. For example, for a project called demoproject:

   $ oc get quota -n demoproject
   NAME                AGE
   besteffort          11m
   compute-resources   2m
   core-object-counts  29m

2. Describe the quota you are interested in, for example the core-object-counts quota:

   $ oc describe quota core-object-counts -n demoproject
   Name:			core-object-counts
   Namespace:		demoproject
   Resource		Used	Hard
   --------		----	----
   configmaps		3	10
   persistentvolumeclaims	0	4
   replicationcontrollers	3	20
   secrets			9	10
   services		2	10

Procedure

1. Add a resource quota definition to a project request template:

   • If a project request template does not exist in a cluster:

     1. Create a bootstrap project template and output it to a file called template.yaml:

        $ oc adm create-bootstrap-project-template -o yaml > template.yaml

     2. Add a resource quota definition to template.yaml. The following example defines a resource quota named 'storage-consumption'. The definition must be added before the parameters: section in the template:

        - apiVersion: v1
          kind: ResourceQuota
          metadata:
            name: storage-consumption
          spec:
            hard:
              persistentvolumeclaims: "10" 1
              requests.storage: "50Gi" 2
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
              bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

        1

        The total number of persistent volume claims in a project.

        2

        Across all persistent volume claims in a project, the sum of storage requested cannot exceed this value.

        3

        Across all persistent volume claims in a project, the sum of storage requested in the gold storage class cannot exceed this value.

        4

        Across all persistent volume claims in a project, the sum of storage requested in the silver storage class cannot exceed this value.

        5

        Across all persistent volume claims in a project, the total number of claims in the silver storage class cannot exceed this value.

        6

        Across all persistent volume claims in a project, the sum of storage requested in the bronze storage class cannot exceed this value. When this value is set to 0, the bronze storage class cannot request storage.

        7

        Across all persistent volume claims in a project, the sum of storage requested in the bronze storage class cannot exceed this value. When this value is set to 0, the bronze storage class cannot create claims.

     3. Create a project request template from the modified template.yaml file in the openshift-config namespace:

        $ oc create -f template.yaml -n openshift-config

        Note

        To include the configuration as a kubectl.kubernetes.io/last-applied-configuration annotation, add the --save-config option to the oc create command.

        By default, the template is called project-request.

   • If a project request template already exists within a cluster:

     Note

     If you declaratively or imperatively manage objects within your cluster by using configuration files, edit the existing project request template through those files instead.

     1. List templates in the openshift-config namespace:

        $ oc get templates -n openshift-config

     2. Edit an existing project request template:

        $ oc edit template <project_request_template> -n openshift-config

     3. Add a resource quota definition, such as the preceding 'storage-consumption' example, into the existing template. The definition must be added before the parameters: section in the template.

2. If you created a project request template, reference it in the cluster’s project configuration resource:

   1. Access the project configuration resource for editing:

      • By using the web console:

        1. Navigate to the Administration → Cluster Settings page.
        2. Click Global Configuration to view all configuration resources.
        3. Find the entry for Project and click Edit YAML.

      • By using the CLI:

        1. Edit the project.config.openshift.io/cluster resource:

           $ oc edit project.config.openshift.io/cluster

   2. Update the spec section of the project configuration resource to include the projectRequestTemplate and name parameters. The following example references the default project request template name project-request:

      apiVersion: config.openshift.io/v1
      kind: Project
      metadata:
        ...
      spec:
        projectRequestTemplate:
          name: project-request

3. Verify that the resource quota is applied when projects are created:

   1. Create a project:

      $ oc new-project <project_name>

   2. List the project’s resource quotas:

      $ oc get resourcequotas

   3. Describe the resource quota in detail:

      $ oc describe resourcequotas <resource_quota_name>

Procedure

1. To select projects based on annotations, run the following command:

   $ oc create clusterquota for-user \
        --project-annotation-selector openshift.io/requester=<user_name> \
        --hard pods=10 \
        --hard secrets=20

   This creates the following ClusterResourceQuota object:

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     name: for-user
   spec:
     quota: 1
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: 2
         openshift.io/requester: <user_name>
       labels: null 3
   status:
     namespaces: 4
     - namespace: ns-one
       status:
         hard:
           pods: "10"
           secrets: "20"
         used:
           pods: "1"
           secrets: "9"
     total: 5
       hard:
         pods: "10"
         secrets: "20"
       used:
         pods: "1"
         secrets: "9"

   1

   The ResourceQuotaSpec object that will be enforced over the selected projects.

   2

   A simple key-value selector for annotations.

   3

   A label selector that can be used to select projects.

   4

   A per-namespace map that describes current quota usage in each selected project.

   5

   The aggregate usage across all selected projects.

   This multi-project quota document controls all projects requested by <user_name> using the default project request endpoint. You are limited to 10 pods and 20 secrets.

2. Similarly, to select projects based on labels, run this command:

   $  oc create clusterresourcequota for-name \ 1
       --project-label-selector=name=frontend \ 2
       --hard=pods=10 --hard=secrets=20

   1

   Both clusterresourcequota and clusterquota are aliases of the same command. for-name is the name of the ClusterResourceQuota object.

   2

   To select projects by label, provide a key-value pair by using the format --project-label-selector=key=value.

   This creates the following ClusterResourceQuota object definition:

   apiVersion: v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

Procedure

1. To view quotas applied to a project, run:

   $ oc describe AppliedClusterResourceQuota

   For example:

   Name:   for-user
   Namespace:  <none>
   Created:  19 hours ago
   Labels:   <none>
   Annotations:  <none>
   Label Selector: <null>
   AnnotationSelector: map[openshift.io/requester:<user-name>]
   Resource  Used  Hard
   --------  ----  ----
   pods        1     10
   secrets     9     20

Procedure

1. To idle a single service, run:

   $ oc idle <service>

Procedure

1. Create a file containing a list of the services, each on their own line.

2. Idle the services using the --resource-names-file option:

   $ oc idle --resource-names-file <filename>

Procedure

1. To see what a pruning operation would delete:

   1. Keeping up to three tag revisions, and keeping resources (images, imagestreams and Pods) younger than sixty minutes:

      $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m

   2. Pruning every image that exceeds defined limits:

      $ oc adm prune images --prune-over-size-limit

2. To actually perform the prune operation with the options from the previous step:

   $ oc adm prune images --keep-tag-revisions=3 --keep-younger-than=60m --confirm

   $ oc adm prune images --prune-over-size-limit --confirm

1. The recommend solution is to secure the registry. Otherwise, you can force the client to use an insecure connection by appending --force-insecure to the command, however this is not recommended.