Procedure

1. To view a list of projects, enter the following command:

   $ oc get projects

   Copy code to clipboard

2. To change from the current project to a different project for CLI operations, enter the following command. The specified project is then used in all subsequent operations that manipulate project-scoped content.

   $ oc project <project_name>

   Copy code to clipboard

Procedure

1. In the Developer perspective, navigate to the Project page.
2. Select your project from the Project menu.
3. Select the Project Access tab.

4. Click Add access to add a new row of permissions to the default ones.

   Figure 2.2. Project permissions

   
5. Enter the user name, click the Select a role drop-down list, and select an appropriate role.
6. Click Save to add the new permissions.

7. Optional: You can complete any of the following additional tasks:

   • The Select a role drop-down list, to modify the access permissions of an existing user.

   • The Remove Access icon, to completely remove the access permissions of an existing user to the project.

     Note

     Advanced role-based access control is managed in the Roles and Roles Binding views in the Administrator perspective.

Procedure

1. In the Administrator perspective, navigate to Administration → Cluster settings.
2. Click the Configuration tab.
3. From the Configuration resource list, select Console operator.openshift.io.
4. Navigate to the YAML tab to view and edit the YAML code.

5. In the YAML code under spec, customize the list of available cluster roles for project access. The following example specifies the default admin, edit, and view roles:

   apiVersion: operator.openshift.io/v1
   kind: Console
   metadata:
     name: cluster
   # ...
   spec:
     customization:
       projectAccess:
         availableClusterRoles:
         - admin
         - edit
         - view

   Copy code to clipboard
6. Click Save to save the changes to the Console configuration resource.

Verification

1. In the Developer perspective, navigate to the Project page.
2. Select a project from the Project menu.
3. Select the Project access tab.
4. Click the menu in the Role column and verify that the available roles match the configuration that you applied to the Console resource configuration.

Procedure

1. Navigate to the +Add page.
2. Select your project from the Project menu.

3. Click an item on the +Add page and then follow the workflow.

   Note

   You can also use the search feature in the +Add page to find additional items to add to your project. Click + under Add at the top of the page and type the name of a component in the search field.

Procedure

1. Navigate to Home → Projects.
2. Select a project from the list.
3. Review the project status in the Overview page.

Procedure

1. Switch to your project:

   $ oc project <project_name>

   Copy code to clipboard
   • Replace <project_name> with the name of your project.

2. Obtain a high-level overview of the project:

   $ oc status

   Copy code to clipboard

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

   Copy code to clipboard
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

   Copy code to clipboard

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

   • Using the web console, complete the following tasks:

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

   • Using the CLI, complete the following tasks:

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

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

        Copy code to clipboard

6. Update the spec section to include the projectRequestTemplate and name parameters. Ensure you 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>
   # ...

   Copy code to clipboard

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

   Copy code to clipboard

   Example output

   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

   Copy code to clipboard

   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}'

     Copy code to clipboard

   • 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

     Copy code to clipboard

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 by using the CLI, complete the following steps:

     1. To edit the self-provisioners cluster role binding, enter the following command:

        $ oc edit clusterrolebinding.rbac self-provisioners

        Copy code to clipboard

     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"
        # ...

        Copy code to clipboard

   • To update the role binding, run the following single command:

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

     Copy code to clipboard

5. Log in as an authenticated user and verify that the user can no longer self-provision a project:

   $ oc new-project test

   Copy code to clipboard

   Example output

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

   Copy code to clipboard

   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.

   • By using the web console, complete the following steps:

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

   • By using the CLI, complete the following steps:

     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

        Copy code to clipboard

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>
   # ...

   Copy code to clipboard

   The following example uses actual values:

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

   Copy code to clipboard
3. After saving your changes, attempt to create a new project by using a developer or service account that cannot self-provision projects. By doing this task, you can verify that your changes were successfully applied.

Procedure

1. In the +Add view, click the Samples tile to see the Samples page.
2. On the Samples page, select one of the available sample applications to see the Create Sample Application form.

3. In the Create Sample Application Form:

   • In the Name field, the deployment name is displayed by default. You can modify this name as required.
   • In the Builder Image Version, a builder image is selected by default. You can modify this image version by using the Builder Image Version drop-down list.
   • A sample Git repository URL is added by default.
4. Click Create to create the sample application. The build status of the sample application is displayed on the Topology view. After the sample application is created, you can see the deployment added to the application.

Procedure

1. In the +Add view, click the Getting Started resources → Build with guided documentation → View all quick starts link to view the Quick Starts page.
2. In the Quick Starts page, click the tile for the quick start that you want to use.
3. Click Start to begin the quick start.
4. Perform the steps that are displayed.

Procedure

1. In the +Add view, click From Git in the Git Repository tile 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. Optional: You can import a Devfile, a Dockerfile, Builder Image, or a Serverless Function through your Git repository to further customize your deployment.

   • If your Git repository contains a Devfile, a Dockerfile, a Builder Image, or a func.yaml, it is automatically detected and populated on the respective path fields.
   • If a Devfile, a Dockerfile, or a Builder Image are detected in the same repository, the Devfile is selected by default.
   • If func.yaml is detected in the Git repository, the Import Strategy changes to Serverless Function.
   • Alternatively, you can create a serverless function by clicking Create Serverless function in the +Add view using the Git repository URL.
   • To edit the file import type and select a different strategy, click Edit import strategy option.
   • If multiple Devfiles, a Dockerfiles, or a Builder Images are detected, to import a specific instance, specify the respective paths relative to the context directory.

5. After the Git URL is validated, the recommended builder image is selected and marked with a star. If the builder image is not auto-detected, select a builder image. For the Content from github.com is not included.https://github.com/sclorg/nodejs-ex Git URL, by default the Node.js builder image is selected.

   1. Optional: Use the Builder Image Version drop-down to specify a version.
   2. Optional: Use the Edit import strategy to select a different strategy.
   3. Optional: For the Node.js builder image, use the Run command field to override the command to run the application.

6. 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 if there are no existing applications. If there are existing applications, you can choose to deploy the component within an existing application, create a new application, or keep the component unassigned.

      Note

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

7. In the Resources section, select:

   • Deployment, to create an application in plain Kubernetes style.
   • Deployment Config, to create an Red Hat OpenShift Service on AWS style application.

   • Serverless Deployment, to create a Knative service.

     Note

     To set the default resource preference for importing an application, go to User Preferences → Applications → Resource type field. The Serverless Deployment option is displayed in the Import from Git form only if the OpenShift Serverless Operator is installed in your cluster. The Resources section is not available while creating a serverless function. For further details, refer to the OpenShift Serverless documentation.

8. In the Pipelines section, select Add Pipeline, and then click Show Pipeline Visualization to see the pipeline for the application. A default pipeline is selected, but you can choose the pipeline you want from the list of available pipelines for the application.

   Note

   The Add pipeline checkbox is checked and Configure PAC is selected by default if the following criterias are fulfilled:

   • Pipeline operator is installed
   • pipelines-as-code is enabled
   • .tekton directory is detected in the Git repository

9. Add a webhook to your repository. If Configure PAC is checked and the GitHub App is set up, you can see the Use GitHub App and Setup a webhook options. If GitHub App is not set up, you can only see the Setup a webhook option:

   1. Go to Settings → Webhooks and click Add webhook.
   2. Set the Payload URL to the Pipelines as Code controller public URL.
   3. Select the content type as application/json.
   4. Add a webhook secret and note it in an alternate location. With openssl installed on your local machine, generate a random secret.
   5. Click Let me select individual events and select these events: Commit comments, Issue comments, Pull request, and Pushes.
   6. Click Add webhook.

10. Optional: In the Advanced Options section, the Target port and the Create a route to the application is selected by default so that you can access your application using a publicly available URL.

    If your application does not expose its data on the default public port, 80, clear the check box, and set the target port number you want to expose.

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

    Routing

    By clicking the Routing link, you can perform the following actions:

    • 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.

      Note

      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.

    Domain mapping

    If you are creating a Serverless Deployment, you can add a custom domain mapping to the Knative service during creation.

    • In the Advanced options section, click Show advanced Routing options.

      • If the domain mapping CR that you want to map to the service already exists, you can select it from the Domain mapping drop-down menu.
      • If you want to create a new domain mapping CR, type the domain name into the box, and select the Create option. For example, if you type in example.com, the Create option is Create "example.com".

    Health Checks

    Click the Health Checks link to add Readiness, Liveness, and Startup probes to your application. All the probes have prepopulated default data; you can add the probes with the default data or customize it as required.

    To customize the health probes:

    • Click Add Readiness Probe, if required, modify the parameters to check if the container is ready to handle requests, and select the check mark to add the probe.
    • Click Add Liveness Probe, if required, modify the parameters to check if a container is still running, and select the check mark to add the probe.

    • Click Add Startup Probe, if required, modify the parameters to check if the application within the container has started, and select the check mark to add the probe.

      For each of the probes, you can specify the request type - HTTP GET, Container Command, or TCP Socket, from the drop-down list. The form changes as per the selected request type. You can then modify the default values for the other parameters, such as the success and failure thresholds for the probe, number of seconds before performing the first probe after the container starts, frequency of the probe, and the timeout value.

    Build Configuration and Deployment

    Click the Build Configuration and Deployment links to see the respective configuration options. Some options are selected by default; you can customize them further by adding the necessary triggers and environment variables.

    For serverless applications, the Deployment option is not displayed as the Knative configuration resource maintains the desired state for your deployment instead of a DeploymentConfig resource.

    Scaling

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

    If you are creating a serverless deployment, you can also configure the following settings:

    • Min Pods determines the lower limit for the number of pods that must be running at any given time for a Knative service. This is also known as the minScale setting.
    • Max Pods determines the upper limit for the number of pods that can be running at any given time for a Knative service. This is also known as the maxScale setting.
    • Concurrency target determines the number of concurrent requests desired for each instance of the application at a given time.
    • Concurrency limit determines the limit for the number of concurrent requests allowed for each instance of the application at a given time.
    • Concurrency utilization determines the percentage of the concurrent requests limit that must be met before Knative scales up additional pods to handle additional traffic.
    • Autoscale window defines the time window over which metrics are averaged to provide input for scaling decisions when the autoscaler is not in panic mode. A service is scaled-to-zero if no requests are received during this window. The default duration for the autoscale window is 60s. This is also known as the stable window.

    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.

12. Click Create to create the application and a success notification is displayed. You can see the build status of the application in the Topology view.

Procedure

1. In the +Add view, click Container images to view the Deploy Images page.

2. In the Image section:

   1. Select Image name from external registry to deploy an image from a public or a private registry, or select Image stream tag from internal registry to deploy an image from an internal registry.
   2. Select an icon for your image in the Runtime icon tab.

3. In the General section:

   1. In the Application name field, enter a unique name for the application grouping.
   2. In the Name field, enter a unique name to identify the resources created for this component.

4. In the Resource type section, select the resource type to generate:

   1. Select Deployment to enable declarative updates for Pod and ReplicaSet objects.
   2. Select DeploymentConfig to define the template for a Pod object, and manage deploying new images and configuration sources.
   3. Select Serverless Deployment to enable scaling to zero when idle.
5. Click Create. You can view the build status of the application in the Topology view.

Procedure

1. In the Topology view, right-click anywhere to view the Add to Project menu.
2. Hover over the Add to Project menu to see the menu options, and then select the Upload JAR file option to see the Upload JAR file form. Alternatively, you can drag the JAR file into the Topology view.
3. In the JAR file field, browse for the required JAR file on your local machine and upload it. Alternatively, you can drag the JAR file on to the field. A toast alert is displayed at the top right if an incompatible file type is dragged into the Topology view. A field error is displayed if an incompatible file type is dropped on the field in the upload form.
4. The runtime icon and builder image are selected by default. If a builder image is not auto-detected, select a builder image. If required, you can change the version using the Builder Image Version drop-down list.
5. Optional: In the Application Name field, enter a unique name for your application to use for resource labelling.
6. In the Name field, enter a unique component name for the associated resources.
7. Optional: Use the Resource type drop-down list to change the resource type.
8. In the Advanced options menu, click Create a Route to the Application to configure a public URL for your deployed application.
9. Click Create to deploy the application. A toast notification is shown to notify you that the JAR file is being uploaded. The toast notification also includes a link to view the build logs.

Procedure

1. Navigate to Developer Perspective → +Add → Developer Catalog → All Services. A list of all the available services in the Developer Catalog is displayed.
2. Under Type, click Devfiles to browse for devfiles that support a particular language or framework. Alternatively, you can use the keyword filter to search for a particular devfile using their name, tag, or description.
3. Click the devfile you want to use to create an application. The devfile tile displays the details of the devfile, including the name, description, provider, and the documentation of the devfile.
4. Click Create to create an application and view the application in the Topology view.

Procedure

1. In the Developer perspective, navigate to the +Add view and from the Developer Catalog tile, click All Services to view all the available services in the Developer Catalog.
2. Under All Services, select the kind of service or the component you need to add to your project. For this example, select Databases to list all the database services and then click MariaDB to see the details for the service.

3. Click Instantiate Template to see an automatically populated template with details for the MariaDB service, and then click Create to create and view the MariaDB service in the Topology view.

   Figure 3.1. MariaDB in Topology

   

Procedure

1. Create a new project in the Red Hat OpenShift Service on AWS web console for this procedure. This example uses a project called my-etcd.

2. Navigate to the Ecosystem → Installed Operators page.

   The Operators installed on the cluster by the dedicated-admin and available for use are shown here as a list of cluster service versions (CSVs). Each CSV launches and manages the software provided by the Operator.

   Tip

   You can get this list from the CLI by running the following command:

   $ oc get csv

   Copy code to clipboard

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

   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 similarly to the built-in native Kubernetes ones, such as Deployment or ReplicaSet, but contain logic specific to managing etcd.

4. Create a new etcd cluster:

   1. In the etcd Cluster API box, click Create instance.
   2. Optional: Modify the minimal starting template of an EtcdCluster object, such as the size of the cluster.
   3. 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 example etcd cluster.

6. Click the Resources tab.

   Your project contains several resources that the Operator created and configured.

7. Verify that a Kubernetes service exists that allows you to access the database from other pods in your project.

8. Optional: To grant another user permission to create Operator-managed applications in the project, add the edit role by running the following command:

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

   Copy code to clipboard

   Users with the edit role in a project can create, manage, and delete Operator-managed application instances, such as an etcd cluster.

Procedure

1. Create an application from a Git repository in a local directory by running the following command:

   $ oc new-app /<path_to_source_code>

   Copy code to clipboard
   Note

   If you use a local Git repository, the repository must have a remote named origin that points to a URL that is accessible by the Red Hat OpenShift Service on AWS cluster. If there is no recognized remote, running the new-app command creates a binary build.

2. Create an application from a public remote Git repository by running the following command:

   $ oc new-app https://github.com/sclorg/cakephp-ex

   Copy code to clipboard

3. Create an application from a private remote Git repository by running the following command:

   $ oc new-app https://github.com/<your_user>/<your_private_repo> --source-secret=yoursecret

   Copy code to clipboard
   Note

   If you use a private remote Git repository, use the --source-secret flag to specify a source clone secret for access to the repository.

4. Use a subdirectory of your source repository by running the following command:

   $ oc new-app https://github.com/sclorg/s2i-ruby-container.git \
       --context-dir=2.0/test/puma-test-app

   Copy code to clipboard

5. Specify a Git branch by running the following command:

   $ oc new-app https://github.com/openshift/ruby-hello-world.git#beta4

   Copy code to clipboard

6. Override the automatically detected build strategy by running the following command:

   $ oc new-app /home/user/code/myapp --strategy=docker

   Copy code to clipboard
   Note

   The oc command requires that files containing build sources are available in a remote Git repository. For all source builds, you must use git remote -v.

7. Specify the builder image and source repository:

   1. Specify the builder image and source repository for a remote repository by running the following command:

      $ oc new-app myproject/my-ruby~https://github.com/openshift/ruby-hello-world.git

      Copy code to clipboard

   2. Specify the builder image and source repository for a local repository by running the following command:

      $ oc new-app openshift/ruby-20-centos7:latest~/home/user/code/my-ruby-app

      Copy code to clipboard

Procedure

1. Upload an application template to the template library of your current project by running the following command:

   $ oc create -f examples/sample-app/application-template-stibuild.json

   Copy code to clipboard

2. Create a new application from a stored template by running the following command:

   $ oc new-app ruby-helloworld-sample

   Copy code to clipboard

3. Create a new application from a template file on your local file system without storing it in Red Hat OpenShift Service on AWS by running the following command:

   $ oc new-app -f examples/sample-app/application-template-stibuild.json

   Copy code to clipboard

4. Set template parameter values when creating an application by running the following command:

   $ oc new-app ruby-helloworld-sample \
       -p ADMIN_USERNAME=admin -p ADMIN_PASSWORD=mypassword

   Copy code to clipboard

5. Store template parameters in a file by creating a file such as helloworld.params with the following content:

   ADMIN_USERNAME=admin
   ADMIN_PASSWORD=mypassword

   Copy code to clipboard

   You can store your parameters in a file, then use that file with --param-file when instantiating a template. If you want to read the parameters from standard input, use --param-file=-.

6. Create a new application from a template by using a parameter file by running the following command:

   $ oc new-app ruby-helloworld-sample --param-file=helloworld.params

   Copy code to clipboard
   Note

   To read parameters from standard input, use --param-file=-.

1. Download the Helm binary:

   • Linux (x86_64, amd64)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-amd64 -o /usr/local/bin/helm

     Copy code to clipboard

   • Linux on IBM Z® and IBM® LinuxONE (s390x)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-s390x -o /usr/local/bin/helm

     Copy code to clipboard

   • Linux on IBM Power® (ppc64le)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-ppc64le -o /usr/local/bin/helm

     Copy code to clipboard

   • Linux on ARM (arm64)

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-linux-arm64 -o /usr/local/bin/helm

     Copy code to clipboard

2. Make the binary file executable:

   # chmod +x /usr/local/bin/helm

   Copy code to clipboard

3. Check the installed version:

   $ helm version

   Copy code to clipboard

   Example output

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

   Copy code to clipboard

1. Download the Helm binary: Content from mirror.openshift.com is not included..exe file.
2. Click Search and type env or environment.
3. Select Edit environment variables for your account.
4. Select Path from the Variable section and click Edit.
5. Click New and type the path to the directory with the exe file into the field or click Browse and select the directory, and click OK.

1. Download the Helm binary:

   • For macOS on Intel (x86_64):

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-amd64 -o /usr/local/bin/helm

     Copy code to clipboard

   • For macOS on ARM (Apple Silicon):

     # curl -L https://mirror.openshift.com/pub/openshift-v4/clients/helm/latest/helm-darwin-arm64 -o /usr/local/bin/helm

     Copy code to clipboard

2. Make the binary file executable:

   # chmod +x /usr/local/bin/helm

   Copy code to clipboard

3. Check the installed version:

   $ helm version

   Copy code to clipboard

   Example output

   version.BuildInfo{Version:"v3.0", GitCommit:"b31719aab7963acf4887a1c1e6d5e53378e34d93", GitTreeState:"clean", GoVersion:"go1.13.4"}

   Copy code to clipboard

1. In the Developer perspective, navigate to the +Add view and select a project. Then click Helm Chart option to see all the Helm Charts in the Developer Catalog.
2. Select a chart and read the description, README, and other details about the chart.

3. Click Create.

   Figure 5.1. Helm charts in developer catalog

   

4. In the Create Helm Release page:

   1. Enter a unique name for the release in the Release Name field.
   2. Select the required chart version from the Chart Version drop-down list.

   3. Configure your Helm chart by using the Form View or the YAML View.

      Note

      Where available, you can switch between the YAML View and Form View. The data is persisted when switching between the views.

   4. Click Create to create a Helm release. The web console displays the new release in the Topology view.

      If a Helm chart has release notes, the web console displays them.

      If a Helm chart creates workloads, the web console displays them on the Topology or Helm release details page. The workloads are DaemonSet, CronJob, Pod, Deployment, and DeploymentConfig.

   5. View the newly created Helm release in the Helm Releases page.

Procedure

1. Create a new project:

   $ oc new-project nodejs-ex-k

   Copy code to clipboard

2. Download an example Node.js chart that contains Red Hat OpenShift Service on AWS objects:

   $ git clone https://github.com/redhat-developer/redhat-helm-charts

   Copy code to clipboard

3. Go to the directory with the sample chart:

   $ cd redhat-helm-charts/alpha/nodejs-ex-k/

   Copy code to clipboard

4. Edit the Chart.yaml file and add a description of your chart:

   apiVersion: v2 1
   name: nodejs-ex-k 2
   description: A Helm chart for OpenShift 3
   icon: https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.svg 4
   version: 0.2.1 5

   Copy code to clipboard

   1

   The chart API version. It should be v2 for Helm charts that require at least Helm 3.

   2

   The name of your chart.

   3

   The description of your chart.

   4

   The URL to an image to be used as an icon.

   5

   The Version of your chart as per the Semantic Versioning (SemVer) 2.0.0 Specification.

5. Verify that the chart is formatted properly:

   $ helm lint

   Copy code to clipboard

   Example output

   [INFO] Chart.yaml: icon is recommended
   
   1 chart(s) linted, 0 chart(s) failed

   Copy code to clipboard

6. Navigate to the previous directory level:

   $ cd ..

   Copy code to clipboard

7. Install the chart:

   $ helm install nodejs-chart nodejs-ex-k

   Copy code to clipboard

8. Verify that the chart has installed successfully:

   $ helm list

   Copy code to clipboard

   Example output

   NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
   nodejs-chart nodejs-ex-k 1 2019-12-05 15:06:51.379134163 -0500 EST deployed nodejs-0.1.0  1.16.0

   Copy code to clipboard

Procedure

1. In the Developer perspective, navigate to the +Add view and select a project.
2. From the Developer Catalog tile, select the Helm Chart option to see all the Helm charts in the Developer Catalog.

3. Use the filters to the left of the list of Helm charts to filter the required charts:

   • Use the Chart Repositories filter to filter charts provided by Red Hat Certification Charts or OpenShift Helm Charts.
   • Use the Source filter to filter charts sourced from Partners, Community, or Red Hat. Certified charts are indicated with the ( ) icon.

Procedure

1. In the Red Hat OpenShift Service on AWS web console, select Ecosystem > Helm from the navigation menu. The Helm view opens.
2. In the Project drop-down menu, select the project where you want to install the Helm release; for example, default.
3. From the Helm Releases tab, click Create.
4. Select Helm chart URL. The Install Helm chart from URL view opens.

5. In the Chart URL field, enter the URL for the Helm chart you want to install.

   Note

   For Helm charts stored in an OCI-compliant registry, the URL must use the oci:// protocol; for example, oci://quay.io/organization/repository/chart-name.

6. In the Release name field, enter a name for the Helm release you want to install.
7. In the Chart version field, enter the chart version number if it is not detected automatically.

8. Click Next. The Configure Helm release view opens.

   • Review the configuration. Make sure that Chart URL, Release name, and Chart version are correct.

9. For the Configure via option, select either Form view or YAML view.

   • Choose Form view (the default) for a guided configuration of standard parameters.

   • Choose YAML view if you need to modify advanced settings that are not available in the form view.

     Note

     The Form view might not display every field from your Helm chart. For full control over all configuration parameters, select YAML view.

10. Click Install. The Helm Releases tab opens and, if the release installation is successful, its status is Deployed.

Procedure

1. In the Topology view, select the Helm release to see the side panel.
2. Click Actions > Upgrade Helm Release.

3. On the Upgrade Helm Release page, if you can edit the Chart Version field, select the chart version you want to upgrade to, edit the values as needed, then click Upgrade to create a revision of the Helm release. The Helm Releases page shows both revisions.

   Note

   If you installed the Helm chart using a direct URL, you can’t change Chart Version. Instead, edit the values in Form view or YAML view.

1. In the Developer perspective, navigate to the Helm view to see the Helm Releases in the namespace.
2. Click the Options menu adjoining the listed release, and select Rollback.
3. In the Rollback Helm Release page, select the Revision you want to rollback to and click Rollback.
4. In the Helm Releases page, click on the chart to see the details and resources for that release.

5. Go to the Revision History tab to see all the revisions for the chart.

   Figure 5.2. Helm revision history

   
6. If required, you can further use the Options menu adjoining a particular revision and select the revision to rollback to.

Procedure

1. In the Topology view, right-click the Helm release and select Delete Helm Release.
2. In the confirmation prompt, enter the name of the chart and click Delete.

Procedure

1. Create a new TLS secret from a private key and a public certificate, where fullchain.pem and privkey.pem are your public or private wildcard certificates.

   Example

   $ oc create secret tls <name>-tls --cert=fullchain.pem --key=privkey.pem -n <my_project>

   Copy code to clipboard

2. Create a new CustomDomain custom resource (CR):

   Example <company_name>-custom-domain.yaml

   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: <company_name>
   spec:
     domain: apps.<company_name>.io
     scope: External
     loadBalancerType: Classic
     certificate:
       name: <name>-tls
       namespace: <my_project>
     routeSelector:
       matchLabels:
        route: acme
     namespaceSelector:
       matchLabels:
        type: sharded

   Copy code to clipboard

   where:

   spec.domain

   Specifies the custom domain.

   spec.loadBalancerType

   Specifies the type of load balancer for your custom domain. This type can be the default classic or NLB if you use a network load balancer.

   spec.certificate.name

   Specifies the secret created in the previous step.

   spec.routeSelector

   Optional. Filters the set of routes serviced by the CustomDomain ingress. If no value is provided, the default is no filtering.

   spec.namespaceSelector

   Optional. Filters the set of namespaces serviced by the CustomDomain ingress. If no value is provided, the default is no filtering.

3. Apply the CR:

   Example

   $ oc apply -f <company_name>-custom-domain.yaml

   Copy code to clipboard

4. Get the status of your newly created CR:

   $ oc get customdomains

   Copy code to clipboard

   Example output

   NAME               ENDPOINT                                                    DOMAIN                       STATUS
   <company_name>     xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com  *.apps.<company_name>.io     Ready

   Copy code to clipboard

5. Using the endpoint value, add a new wildcard CNAME record set to your managed DNS provider, such as Route53, Azure DNS, or Google DNS.

   Example

   *.apps.<company_name>.io -> xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com

   Copy code to clipboard

6. Create a new application and expose it:

   Example

   $ oc new-app --docker-image=docker.io/openshift/hello-openshift -n my-project

   Copy code to clipboard

   $ oc create route <route_name> --service=hello-openshift hello-openshift-tls --hostname hello-openshift-tls-my-project.apps.<company_name>.io -n my-project

   Copy code to clipboard

   $ oc get route -n my-project

   Copy code to clipboard

   $ curl https://hello-openshift-tls-my-project.apps.<company_name>.io
   Hello OpenShift!

   Copy code to clipboard

Procedure

1. Create new secret

   $ oc create secret tls <secret-new> --cert=fullchain.pem --key=privkey.pem -n <my_project>

   Copy code to clipboard

2. Patch CustomDomain CR

   $ oc patch customdomain <company_name> --type='merge' -p '{"spec":{"certificate":{"name":"<secret-new>"}}}'

   Copy code to clipboard

3. Delete old secret

   $ oc delete secret <secret-old> -n <my_project>

   Copy code to clipboard

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 replication controller based on the surge count.
3. Scales down the old replication controller based on the max unavailable count.
4. Repeats this scaling until the new replication controller has reached the desired replica count and the old replication controller 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.

Procedure

1. Use the oc set deployment-hook command to set the type of hook you want: --pre, --mid, or --post. For example, to set a pre-deployment hook:

   $ oc set deployment-hook dc/frontend \
       --pre -c helloworld -e CUSTOM_VAR1=custom_value1 \
       --volumes data --failure-policy=abort -- /usr/bin/command arg1 arg2

   Copy code to clipboard

Procedure

1. Create two independent application components.

   1. Create a copy of the example application running the v1 image under the example-blue service:

      $ oc new-app openshift/deployment-example:v1 --name=example-blue

      Copy code to clipboard

   2. Create a second copy that uses the v2 image under the example-green service:

      $ oc new-app openshift/deployment-example:v2 --name=example-green

      Copy code to clipboard

2. Create a route that points to the old service:

   $ oc expose svc/example-blue --name=bluegreen-example

   Copy code to clipboard
3. Browse to the application at bluegreen-example-<project>.<router_domain> to verify you see the v1 image.

4. Edit the route and change the service name to example-green:

   $ oc patch route/bluegreen-example -p '{"spec":{"to":{"name":"example-green"}}}'

   Copy code to clipboard
5. To verify that the route has changed, refresh the browser until you see the v2 image.

Procedure

1. Create the two applications and give them different names. Each creates a Deployment object. The applications are versions of the same program; one is usually the current production version and the other the proposed new version.

   1. Create the first application. The following example creates an application called ab-example-a:

      $ oc new-app openshift/deployment-example --name=ab-example-a

      Copy code to clipboard

   2. Create the second application:

      $ oc new-app openshift/deployment-example:v2 --name=ab-example-b

      Copy code to clipboard

      Both applications are deployed and services are created.

2. Make the application available externally via a route. At this point, you can expose either. It can be convenient to expose the current production version first and later modify the route to add the new version.

   $ oc expose svc/ab-example-a

   Copy code to clipboard

   Browse to the application at ab-example-a.<project>.<router_domain> to verify that you see the expected version.

3. When you deploy the route, the router balances the traffic according to the weights specified for the services. At this point, there is a single service with default weight=1 so all requests go to it. Adding the other service as an alternateBackends and adjusting the weights brings the A/B setup to life. This can be done by the oc set route-backends command or by editing the route.

   Note

   When using alternateBackends, also use the roundrobin load balancing strategy to ensure requests are distributed as expected to the services based on weight. roundrobin can be set for a route by using a route annotation. See the Additional resources section for more information about route annotations.

   Setting the oc set route-backend to 0 means the service does not participate in load balancing, but continues to serve existing persistent connections.

   Note

   Changes to the route just change the portion of traffic to the various services. You might have to scale the deployment to adjust the number of pods to handle the anticipated loads.

   To edit the route, run:

   $ oc edit route <route_name>

   Copy code to clipboard

   Example output

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     name: route-alternate-service
     annotations:
       haproxy.router.openshift.io/balance: roundrobin
   # ...
   spec:
     host: ab-example.my-project.my-domain
     to:
       kind: Service
       name: ab-example-a
       weight: 10
     alternateBackends:
     - kind: Service
       name: ab-example-b
       weight: 15
   # ...

   Copy code to clipboard

Procedure

1. Navigate to the Networking → Routes page.
2. Click the Options menu next to the route you want to edit and select Edit Route.
3. Edit the YAML file. Update the weight to be an integer between 0 and 256 that specifies the relative weight of the target against other target reference objects. The value 0 suppresses requests to this back end. The default is 100. Run oc explain routes.spec.alternateBackends for more information about the options.
4. Click Save.

Procedure

1. Navigate to the Networking → Routes page.
2. Click Create Route.
3. Enter the route Name.
4. Select the Service.
5. Click Add Alternate Service.
6. Enter a value for Weight and Alternate Service Weight. Enter a number between 0 and 255 that depicts relative weight compared with other targets. The default is 100.
7. Select the Target Port.
8. Click Create.

Procedure

1. To manage the services and corresponding weights load balanced by the route, use the oc set route-backends command:

   $ oc set route-backends ROUTENAME \
       [--zero|--equal] [--adjust] SERVICE=WEIGHT[%] [...] [options]

   Copy code to clipboard

   For example, the following sets ab-example-a as the primary service with weight=198 and ab-example-b as the first alternate service with a weight=2:

   $ oc set route-backends ab-example ab-example-a=198 ab-example-b=2

   Copy code to clipboard

   This means 99% of traffic is sent to service ab-example-a and 1% to service ab-example-b.

   This command does not scale the deployment. You might be required to do so to have enough pods to handle the request load.

2. Run the command with no flags to verify the current configuration:

   $ oc set route-backends ab-example

   Copy code to clipboard

   Example output

   NAME                    KIND     TO           WEIGHT
   routes/ab-example       Service  ab-example-a 198 (99%)
   routes/ab-example       Service  ab-example-b 2   (1%)

   Copy code to clipboard

3. To override the default values for the load balancing algorithm, adjust the annotation on the route by setting the algorithm to roundrobin. For a route on Red Hat OpenShift Service on AWS, the default load balancing algorithm is set to random or source values.

   To set the algorithm to roundrobin, run the command:

   $ oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin

   Copy code to clipboard

   For Transport Layer Security (TLS) passthrough routes, the default value is source. For all other routes, the default is random.

4. To alter the weight of an individual service relative to itself or to the primary service, use the --adjust flag. Specifying a percentage adjusts the service relative to either the primary or the first alternate (if you specify the primary). If there are other backends, their weights are kept proportional to the changed.

   The following example alters the weight of ab-example-a and ab-example-b services:

   $ oc set route-backends ab-example --adjust ab-example-a=200 ab-example-b=10

   Copy code to clipboard

   Alternatively, alter the weight of a service by specifying a percentage:

   $ oc set route-backends ab-example --adjust ab-example-b=5%

   Copy code to clipboard

   By specifying + before the percentage declaration, you can adjust a weighting relative to the current setting. For example:

   $ oc set route-backends ab-example --adjust ab-example-b=+15%

   Copy code to clipboard

   The --equal flag sets the weight of all services to 100:

   $ oc set route-backends ab-example --equal

   Copy code to clipboard

   The --zero flag sets the weight of all services to 0. All requests then return with a 503 error.

   Note

   Not all routers support multiple or weighted backends.

Procedure

1. Create a new application, adding a label ab-example=true that will be common to all shards:

   $ oc new-app openshift/deployment-example --name=ab-example-a --as-deployment-config=true --labels=ab-example=true --env=SUBTITLE\=shardA

   Copy code to clipboard

   $ oc delete svc/ab-example-a

   Copy code to clipboard

   The application is deployed and a service is created. This is the first shard.

2. Make the application available via a route, or use the service IP directly:

   $ oc expose deployment ab-example-a --name=ab-example --selector=ab-example\=true

   Copy code to clipboard

   $ oc expose service ab-example

   Copy code to clipboard
3. Browse to the application at ab-example-<project_name>.<router_domain> to verify you see the v1 image.

4. Create a second shard based on the same source image and label as the first shard, but with a different tagged version and unique environment variables:

   $ oc new-app openshift/deployment-example:v2 \
       --name=ab-example-b --labels=ab-example=true \
       SUBTITLE="shard B" COLOR="red" --as-deployment-config=true

   Copy code to clipboard

   $ oc delete svc/ab-example-b

   Copy code to clipboard

5. At this point, both sets of pods are being served under the route. However, because both browsers (by leaving a connection open) and the router (by default, through a cookie) attempt to preserve your connection to a back-end server, you might not see both shards being returned to you.

   To force your browser to one or the other shard:

   1. Use the oc scale command to reduce replicas of ab-example-a to 0.

      $ oc scale dc/ab-example-a --replicas=0

      Copy code to clipboard

      Refresh your browser to show v2 and shard B (in red).

   2. Scale ab-example-a to 1 replica and ab-example-b to 0:

      $ oc scale dc/ab-example-a --replicas=1; oc scale dc/ab-example-b --replicas=0

      Copy code to clipboard

      Refresh your browser to show v1 and shard A (in blue).

6. If you trigger a deployment on either shard, only the pods in that shard are affected. You can trigger a deployment by changing the SUBTITLE environment variable in either Deployment object:

   $ oc edit dc/ab-example-a

   Copy code to clipboard

   or

   $ oc edit dc/ab-example-b

   Copy code to clipboard

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>]

   Copy code to clipboard

   For example:

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

   Copy code to clipboard

Procedure

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

   $ oc get quota -n demoproject

   Copy code to clipboard

   Example output

   NAME                           AGE    REQUEST                                                                                                      LIMIT
   besteffort                     4s     pods: 1/2
   compute-resources-time-bound   10m    pods: 0/2                                                                                                    limits.cpu: 0/1, limits.memory: 0/1Gi
   core-object-counts             109s   configmaps: 2/10, persistentvolumeclaims: 1/4, replicationcontrollers: 1/20, secrets: 9/10, services: 2/10

   Copy code to clipboard

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

   $ oc describe quota core-object-counts -n demoproject

   Copy code to clipboard

   Example output

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

   Copy code to clipboard

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

        Copy code to clipboard

     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
            namespace: ${PROJECT_NAME}
          spec:
            hard:
              persistentvolumeclaims: "10"
              requests.storage: "50Gi"
              gold.storageclass.storage.k8s.io/requests.storage: "10Gi"
              silver.storageclass.storage.k8s.io/requests.storage: "20Gi"
              silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5"
              bronze.storageclass.storage.k8s.io/requests.storage: "0"
              bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0"

        Copy code to clipboard

        where:

        spec.hard.persistentvolumeclaims

        The total number of persistent volume claims in a project.

        spec.hard.requests.storage

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

        spec.hard.gold.storageclass.storage.k8s.io/requests.storage

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

        spec.hard.silver.storageclass.storage.k8s.io/requests.storage

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

        spec.hard.silver.storageclass.storage.k8s.io/persistentvolumeclaims

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

        spec.hard.bronze.storageclass.storage.k8s.io/requests.storage

        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.

        spec.hard.bronze.storageclass.storage.k8s.io/persistentvolumeclaims

        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

        Copy code to clipboard
        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

        Copy code to clipboard

     2. Edit an existing project request template:

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

        Copy code to clipboard
     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 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

           Copy code to clipboard

   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

      Copy code to clipboard

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

   1. Create a project:

      $ oc new-project <project_name>

      Copy code to clipboard

   2. List the project’s resource quotas:

      $ oc get resourcequotas

      Copy code to clipboard

   3. Describe the resource quota in detail:

      $ oc describe resourcequotas <resource_quota_name>

      Copy code to clipboard

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

   Copy code to clipboard

   This creates the following ClusterResourceQuota object:

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

   Copy code to clipboard

   where:

   spec.quota

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

   spec.selector.annotations

   A simple key-value selector for annotations.

   spec.selector.labels

   A label selector that can be used to select projects.

   status.namespaces

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

   status.total

   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 \
       --project-label-selector=name=frontend \
       --hard=pods=10 --hard=secrets=20

   Copy code to clipboard

   where:

   clusterresourcequota

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

   --project-label-selector

   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: quota.openshift.io/v1
   kind: ClusterResourceQuota
   metadata:
     creationTimestamp: null
     name: for-name
   spec:
     quota:
       hard:
         pods: "10"
         secrets: "20"
     selector:
       annotations: null
       labels:
         matchLabels:
           name: frontend

   Copy code to clipboard