SupportConsoleDevelopersStart a trialContact

Chapter 4. Project Management

4.1. Pod Configurations

4.1.1. Description of Function

Display the Pod configurations of pods in an OpenShift cluster. Depending on the endpoint of the request, you can list the Pod configurations for all the pods in an environment, all the pods in a namespace, or a specific Pod configuration in a namespace.

4.1.2. Listing Configurations for All Pods in an Environment

4.1.2.1. Request Breakdown

Listing all the pods in an environment requires one request:

  1. A GET request to the pods resource.

The GET request returns the PodList, listing the details of all pods in the environment.

4.1.2.2. GET Request to Return All Pod Configurations in OpenShift Environment

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/pods

4.1.3. Listing All Pods in a Namespace

4.1.3.1. Request Breakdown

Listing all the pods in a namespace requires one request:

  1. A GET request to the pods subresource of the namespace.

The GET request returns the PodList, listing the details of all pods in the namespace.

4.1.3.2. GET Request to Return All Pod Configurations in Namespace

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/pods

4.1.4. Listing a Specific Pod Configuration in a Namespace

4.1.4.1. Request Breakdown

Listing a specific pod configuration requires one request:

  1. A GET request to the pod name in the pods subresource of the namespace.

The GET request returns the Pod configuration for the specified pod.

4.1.4.2. GET Request to Return Specific Pod Configuration

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/pods/{$POD}

4.2. Idle

4.2.1. Description of Function

Idling discovers the scalable resources (such as deployment configurations and replication controllers) associated with a series of services by examining the endpoints of the service. Each service is then marked as idled, the associated resources are recorded, and the resources are scaled down to zero replicas.

Upon receiving network traffic, the services (and any associated routes) will "wake up" the associated resources by scaling them back up to their previous scale.

4.2.2. Idling a DeploymentConfig

4.2.2.1. Request Breakdown

Idling consists of a series of requests:

  1. A GET request to the endpoint name of the endpoints subresource of the namespace to discover corresponding pods.
  2. A GET request to each pod name in the pods subresource to discover the owner reference (deploymentconfig or replicationcontroller) for that pod.
  3. A GET request to the referenced owner name (deploymentconfig or replicationcontroller) to discover if that referenced owner has an owner reference.
  4. A GET request to the scale subresource for all referenced deploymentconfig or replicationcontroller objects to discover the replica value for the resource.
  5. A PATCH request with updated annotations, including idle start time and corresponding owner reference, to each endpoint name in the endpoint subresource of the namespace.
  6. A PUT request with updated annotations for the idle time and previous scale to the endpoint owner name (deploymentconfig or replicationcontroller) to set the replicas to 0.

Idling an endpoint requires a PATCH request to the endpoint, and a PUT request to the referenced owner of the resources. GET requests 1-3 discover the pods corresponding to the endpoint, the owner resource of the pods, and then discover if that owner resource is owned by another resource.

GET request 4 is optional as the replica value for the resource is in the configuration returned in a previous GET request; however, returning the scale subresource can simplify the process of retrieving the replica value.

The PATCH request adds annotations to the endpoint that include the time in which the resource is considered idle, and an owner reference so that the owner resource is scaled accordingly when a service receives traffic. The PUT request to the owner resource includes the same idle time annotation as the endpoint, the previous replica value of the resource to scale to when unidled, and replaces the replica value to 0 to idle the resource.

Table 4.1. Annotations for Determining Resource Owner
AnnotationDescription

kubernetes.io/created-by

Owner reference for Kubernetes objects.

openshift.io/deployment-config.name

Owner reference for resource belonging to a deploymentconfig.

Table 4.2. Annotations for Endpoint
AnnotationDescription

idling.alpha.openshift.io/idled-at

Indicates the time at which the resource is considered idle.

idling.alpha.openshift.io/unidle-targets

References the owner resource that the endpoint will unidle.

Table 4.3. Annotations for Idling Owner Resource
AnnotationDescription

idling.alpha.openshift.io/idled-at

Indicates the time at which the resource is considered idle.

idling.alpha.openshift.io/previous-scale

Indicates the previous scale of the resource prior to idle. When the endpoint receives traffic, the resource will scale to this value.

4.2.2.2. GET Request to Return endpoint

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/endpoints/{$ENDPOINT}

Response Body Snippet 

...
subsets:
- addresses:
  - ip: 192.0.2.1
    nodeName: {$OPENSHIFT_NODE_URL}
    targetRef:
      kind: Pod
      name: {$POD1}
      namespace: {$PROJECT}
      resourceVersion: "213472"
      uid: 6acc03a4-41cd-11e7-a37b-1418776f4b43
  - ip: 192.0.2.2
    nodeName: {$OPENSHIFT_NODE_URL}
    targetRef:
      kind: Pod
      name: {$POD2}
      namespace: {$PROJECT}
      resourceVersion: "213472"
      uid: 6acc02e0-41cd-11e7-a37b-1418776f4b43
...

The request returns two pods corresponding to the endpoint.

4.2.2.3. GET Request to Return pod Owner

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/pods/{$POD1}

Response Body Snippet 

...
kind: Pod
metadata:
  annotations:
    kubernetes.io/created-by: |
      {"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicationController","namespace":"{$PROJECT}","name":"{$REPLICATIONCONTROLLER}","uid":"e45f3d69-3b9a-11e7-a37b-1418776f4b43","apiVersion":"v1","resourceVersion":"213449"}}
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: {$DEPLOYMENTCONFIG}
    openshift.io/deployment.name: {$DEPLOYMENT}
    openshift.io/scc: restricted
...

The pod owner is discovered from the kubernetes.io/created-by: and the openshift.io/deployment-config.name: annotations. The pod in this example has two owners: {$REPLICATIONCONTROLLER} and {$DEPLOYMENTCONFIG}.

For the purposes of the example, {$POD2} has the same owners.

4.2.2.4. GET Request to Return replicationcontroller Owner

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$REPLICATIONCONTROLLER}

Response Body Snippet 

...
kind: ReplicationController
metadata:
  annotations:
    openshift.io/deployer-pod.name: {$DEPLOYER_POD}
    openshift.io/deployment-config.latest-version: "1"
    openshift.io/deployment-config.name: {$DEPLOYMENTCONFIG}
...

The replication owner is discovered with the openshift.io/deployment-config.name: annotation. The replication controller in this example is also owned by {$DEPLOYMENTCONFIG}.

4.2.2.5. GET Request to Return the deploymentconfig Owner

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}

Response Body Snippet 

...
kind: DeploymentConfig
metadata:
  annotations:
    openshift.io/generated-by: OpenShiftWebConsole
...

The returned deploymentconfig shows no owner, confirming that {$DEPLOYMENTCONFIG} is the sole owner of {$POD1} and {$POD2}.

4.2.2.6. GET Request to Return Scale

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}/scale

Response Body Snippet 

...
kind: Scale
spec:
  replicas: 2
...

The deploymentconfig has a replica value of 2. This will be used when updating the deploymentconfig to idle the resources.

4.2.2.7. PATCH Request to Update endpoint

Note

PATCH requests require JSON formatting.

Request Header 

curl -k -v \
-X PATCH \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/json" \
-H "Content-Type: text/strategic-merge-patch+json" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/api/v1/namespaces/{$PROJECT}/endpoints/{$ENDPOINT}

Request Body 

{
  "metadata":
    "annotations": {
      "idling.alpha.openshift.io/idled-at": "2017-06-21T04:18:54Z",
      "idling.alpha.openshift.io/unidle-targets": "[{\"kind\":\"DeploymentConfig\",\"name\":\"{$DEPLOYMENTCONFIG}\",\"replicas\":2}]"
    }
}

The idling.alpha.openshift.io/idled-at: annotation indicates the time at which the endpoint is considered idled. The same annotation is used for the owner in the next step.
The idling.alpha.openshift.io/unidle-targets: annotation indicates that the endpoint will unidle the owner.

4.2.2.8. PUT Request to Update the deploymentconfig

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
https://{$OPENSHIFT_ENVIRONMENT_URL}:8443/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENTCONFIG}

Request Body Snippet 

...
kind: DeploymentConfig
metadata:
  annotations:
    idling.alpha.openshift.io/idled-at: 2017-06-21T04:18:54Z
    idling.alpha.openshift.io/previous-scale: "2"
    openshift.io/generated-by: OpenShiftWebConsole
...
spec:
  replicas: 0
...

The PUT request uses the deploymentconfig returned in a previous request, modified with the following:

  • The idling.alpha.openshift.io/idled-at: annotation is added to indicate the time at which the endpoint is considered idled.
  • The idling.alpha.openshift.io/previous-scale: annotation is added, using the value from the previous scale request. When the endpoint is unidled, this value will determine the number of replicas to scale.
  • The replicas value is modified to 0.

4.3. Rollback

4.3.1. Description of Function

Revert an application back to a previous deployment.

When you run this command your deployment configuration will be updated to match a previous deployment. By default only the pod and container configuration will be changed and scaling or trigger settings will be left as-is. Note that environment variables and volumes are included in rollbacks; if you have recently updated security credentials in your environment your previous deployment may not have the correct values.

Any image triggers present in the rolled back configuration will be disabled with a warning. This is to help prevent your rolled back deployment from being replaced by a triggered deployment soon after your rollback.

Any version of the deploymentconfig can be used for the rollback request. Rolling back a deployment creates a new deployment version. All deployment reversions use rollback requests, whether rolling the version back or forward.

4.3.2. Rolling Back a Deployment

4.3.2.1. Request Breakdown

Deployment rollback consists of two requests:

  1. A POST request to the rollback subresource of the deployment.
  2. A PUT request to the deployment name in the deploymentconfig subresource of the namespace.

The POST request body specifies which elements of the deployment configuration version spec to be included in the returned deploymentconfig. The request returns a new deploymentconfig that represents the rollback state and can be used verbatim in the request body of the PUT request.

The PUT request body sends the returned deploymentconfig configuration to the deployment name in the subresource. This triggers a new deployment that effectively rolls back the deployment to the version specified in the returned deploymentconfig.

4.3.2.2. POST Request to Return deploymentconfig

Request Header 

curl -k -v \
-X POST  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/rollback

Request Body 

apiVersion: v1
kind: DeploymentConfigRollback
name: {$DEPLOYMENT}
spec:
  from:
    name: {$DEPLOYMENT}-{$VERSION}
  includeTriggers: false
  includeTemplate: true
  includeReplicationMeta: false
  includeStrategy: false
Table 4.4. Field Descriptions
Field NameDescriptionRequiredType

includeTriggers

Returns the triggers parameters of the specified deployment version for rollback

True

Boolean

includeTemplate

Returns the template parameters of the specified deployment version for rollback

True

Boolean

includeReplicationMeta

Returns the replicas and selector parameters of the specified deployment version for rollback

True

Boolean

includeStrategy

Returns the strategy parameters of the specified deployment version for rollback

True

Boolean

4.3.2.3. PUT Request to Revert Application to Previous Deployment

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}

Request Body

Use the response body returned by the POST request as the request body. No changes are necessary.

4.4. Scale

4.4.1. Description of Function

Set a new size for a deployment, replicationcontroller, or job resources:

  • deploymentconfig: Modify the number of replica pods for the deployment.
  • replicationcontroller: Modify the number of replicas maintained by a replication controller in a deployment.
  • job: Modify the number of pod replicas running in parallel, executing a job.

4.4.2. Scaling a Deployment

4.4.2.1. Request Breakdown

Scaling a deployment consists of two requests:

  1. A GET request to the scale subresource of the deployment.
  2. A PUT request with an updated replicas value to the scale subresource of the deployment.

The GET request returns the Scale configuration.
The GET request is optional if an updated Scale configuration can otherwise be provided for the PUT request.

Update the spec: replicas parameter in the Scale configuration. Send the configuration as the request body in a PUT request to the scale subresource of the deployment.

4.4.2.2. GET Request to Scale Deployment

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/scale

4.4.2.3. PUT Request to Scale Deployment

Request Header 

curl -k -v
curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/deploymentconfigs/{$DEPLOYMENT}/scale

Request Body Snippet 

...
spec:
  replicas: 3
...

4.4.3. Scaling a Replication Controller

4.4.3.1. Request Breakdown

Scaling a replication controller consists of two requests:

  1. A GET request to the deployment name and version in the replicationcontrollers subresource of the namespace.
  2. A PUT request with an updated replicas value to the same deployment in the replicationcontrollers of the namespace.

The GET request returns the ReplicationController configuration.
The GET request is optional if an updated ReplicationController configuration can otherwise be provided for the PUT request. The ReplicationController configuration includes an encoded deploymentconfig for the deployment being scaled.

Update the spec: replicas parameter in the ReplicationController configuration. Send the configuration as the request body in a PUT request to the deployment replicationcontrollers resource.

4.4.3.2. GET Request for Deployment Replication Controller

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
GET {$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$DEPLOYMENT}-{$VERSION}

4.4.3.3. PUT Request to Scale Replication Controller

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/api/v1/namespaces/{$PROJECT}/replicationcontrollers/{$DEPLOYMENT}-{$VERSION}

Request Body Snippet 

...
spec:
  replicas: 3
...

4.4.4. Scaling a Job

4.4.4.1. Request Breakdown

Scaling a job consists of two requests:

  1. A GET request to the job name in the jobs subresource of the namespace .
  2. A PUT request with an updated parallelism value to the job name in the jobs subresource of the namespace .

The GET request returns a Job configuration.
The GET request is optional if an updated Job configuration can otherwise be provided for the PUT request.

Update the spec: parallelism parameter in the Job configuration. Send the configuration as the request body in a PUT request to the deployment jobs subresource.

4.4.4.2. GET Request for Deployment Job

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/apis/batch/v1/namespaces/{$PROJECT}/jobs/{$JOB}

4.4.4.3. PUT Request to Scale Job

Request Header 

curl -k -v \
-X PUT \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/apis/batch/v1/namespaces/{$PROJECT}/jobs/{$JOB}

Request Body Snippet 

...
spec:
  parallelism: 3
...

4.5. Routes

4.5.1. Description of Resource

A route allows developers to expose services through an HTTP(S) aware load balancing and proxy layer via a public DNS entry. The route may further specify TLS options and a certificate, or specify a public CNAME that the router should also accept for HTTP and HTTPS traffic. An administrator typically configures their router to be visible outside the cluster firewall, and may also add additional security, caching, or traffic controls on the service content. Routers usually talk directly to the service endpoints.

Once a route is created, the host field may not be changed. Generally, routers use the oldest route with a given host when resolving conflicts.

Routers are subject to additional customization and may support additional controls via the annotations field.

Because administrators may configure multiple routers, the route status field is used to return information to clients about the names and states of the route under each router. If a client chooses a duplicate name, for instance, the route status conditions are used to indicate the route cannot be chosen.

See the Architecture Guide and the Developer Guide for more information on routes, and the REST API Guide for complete field descriptions.

4.5.2. Creating a New Route

4.5.2.1. Request Breakdown

Creating a new route requires one request:

  1. A POST request to the routes subresource of the namespace.

The POST request uses a Route configuration in the request body.
The following request example uses the minimum required fields to expose a service with an insecure route.

4.5.2.2. POST Request to Create a New Route

Request Header 

curl -k -v \
-X POST \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes

Request Body 

apiVersion: v1
kind: Route
metadata:
  name: {$ROUTE_NAME}
spec:
  to:
    kind: Service
    name: {$SERVICE_NAME}
Table 4.5. Route metadata Fields
Field.subfieldDescriptionType

labels.app

Map of string keys and values that can be used to organize and categorize (scope and select) objects. Used primarily for router sharding. May match selectors of replication controllers and services.

projectlabel

name

Name of the route.

routename

Table 4.6. Route spec Fields
Field.subfieldDescriptionType

host

Host is an optional alias/DNS that points to the service. If not specified, a route name will typically be automatically chosen. Must follow DNS952 subdomain conventions.

route-project.router.default.svc.cluster.local

port.targetPort

If specified, the port to be used by the router. Most routers will use all endpoints exposed by the service by default - set this value to instruct routers which port to use.

8080-tcp

to.name

Name of the service/target used for the route.

servicename

to.weight

Weight as an integer between 1 and 256 that specifies the target’s relative weight against other target. reference objects

1

alternateBackends.name

Name of an alternate service/target that is being referred to.

altservice

alternateBackends.weight

Weight as an integer between 1 and 256 that specifies the target’s relative weight against other target.

1

tls.termination

The tls field provides the ability to configure certificates and termination for the route. Options are 'edge', 'passthrough', 'reencrypt'.

edge

wildcardPolicy

Wildcard policy, if any, for the route. Currently only 'Subdomain' or 'None' is allowed.

Subdomain

4.5.3. Listing All Service Configurations in an Environment

4.5.3.1. Request Breakdown

Listing the configurations for all routes in an environment requires one request:

  1. A GET request to the routes resource.

The GET request returns the RouteList, listing the details of all routes in the environment.

4.5.3.2. GET Request to Return All Service Configurations in an Environment

Request Header 

curl -k -v \
-X GET \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/routes

4.5.4. Listing All Service Configurations in a Namespace

4.5.4.1. Request Breakdown

Listing the configurations for all services in a namespace requires one request:

  1. A GET request to the routes subresource of the namespace.

The GET request returns the RouteList, listing the details of all routes in the namespace.

4.5.4.2. GET Request to Return All Service Configurations in Namespace

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes

4.5.5. Listing a Specific Route Configuration in a Namespace

4.5.5.1. Request Breakdown

Listing a specific Route configuration requires one request:

  1. A GET request to the route name in the routes subresource of the namespace.

The GET request returns the Route configuration for the specified route.

4.5.5.2. GET Request to Return Specific Route Configuration

Request Header 

curl -k -v \
-X GET  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes/{$ROUTE}

4.5.6. Updating a Route Configuration

Updating a Route configuration requires two requests:

  1. A GET request to the route name in the routes subresource of the namespace.
  2. A PATCH request with updated field values to the route name in the routes subresource of the namespace.

The GET request is optional as the PATCH request body is not determined by the returned configuration, however it can be useful for preparing the PATCH request body.

4.5.6.1. PATCH Request to Update Route Configuration

Note

PATCH requests require JSON formatting.

The following PATCH request example adds an alternate service to the route and updates the original service with an equal weight:

Request Header 

curl -k -v \
-X PATCH \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/json" \
-H "Content-Type: text/strategic-merge-patch+json" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/
routes/{$ROUTE}

Request Body 

{
  "spec": {
     "to": {
      "weight": 1
     },
     "alternateBackends": [
       {
        "kind": "Service",
        "name": "{$ALT_SERVICE}",
        "weight": 1
       }
    ]
  }
}

4.5.7. Deleting a Route

4.5.7.1. Request Breakdown

Deleting a route requires one request:

  1. A DELETE request to the route name in the routes subresource of the namespace.

The DELETE request returns a code: 200 and the route is deleted.

4.5.7.2. DELETE Request to Delete a Route

Request Header 

curl -k -v \
-X DELETE  \
-H "Authorization: {$BEARER_TOKEN}" \
-H "Accept: application/yaml" \
-H "Content-Type: application/yaml" \
{$OCP_CLUSTER}/oapi/v1/namespaces/{$PROJECT}/routes/{$ROUTE}
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.