Chapter 2. Managing address spaces

AMQ Online is configured to support managing address spaces using the OpenShift command-line tools. Address spaces are managed like any other OpenShift resource using oc.

2.1. Address space

An address space is a group of addresses that can be accessed through a single connection (per protocol). This means that clients connected to the endpoints of an address space can send messages to or receive messages from any authorized address within that address space. An address space can support multiple protocols, as defined by the address space type.

Note

You cannot modify endpoints for an existing address space.

AMQ Online has two types of address spaces:

2.2. Standard address space

The standard address space is the default address space in AMQ Online. It consists of an AMQP router network in combination with attachable storage units. Clients connect to a message router, which forwards messages to or from one or more message brokers. This address space type is appropriate when you have many connections and addresses. However, the standard address space has the following limitations:

  • No transaction support
  • No message ordering
  • No selectors on queues
  • No browsing on queues
  • No message groups

Clients connect and send and receive messages in this address space using the AMQP or MQTT protocols. Note that MQTT does not support qos2 or retained messages.

2.2.1. Standard address types

The standard address space supports five different address types:

  • queue
  • topic
  • anycast
  • multicast
  • subscription

2.2.1.1. Queue

The queue address type is a store-and-forward queue. This address type is appropriate for implementing a distributed work queue, handling traffic bursts, and other use cases when you want to decouple the producer and consumer. A queue can be sharded across multiple storage units. Message ordering might be lost for queues in the standard address space.

2.2.1.2. Topic

The topic address type supports the publish-subscribe messaging pattern where there are 1..N producers and 1..M consumers. Each message published to a topic address is forwarded to all subscribers for that address. A subscriber can also be durable, in which case messages are kept until the subscriber has acknowledged them.

Note

If you create a subscription on a topic, any senders to that topic must specify the topic capability.

2.2.1.2.1. Hierarchical topics and wildcards

A client receiving from a topic address can specify a wildcard address with the topic address as the root. The wildcard behavior follows the MQTT syntax:

  • / is a separator
  • + matches one level
  • # matches one or more levels

So, for example:

  • a/#/b matches a/foo/b, a/bar/b, and a/foo/bar/b
  • a/+/b matches a/foo/b and a/bar/b, but would not match a/foo/bar

In the standard address space, the first level must always be a defined topic address; that is, # and + are not valid as the first characters of a subscribing address.

2.2.1.2.2. Known issue with creating a subscriber on a hierarchical topic

A known issue exists where creating a subscriber on a hierarchical topic in AMQ Online causes the broker to instead create it as a competing consumer (handling the address like a queue rather than a topic). For more information about the specific workaround for your client, see the applicable client example section in Connecting applications to AMQ Online.

2.2.1.3. Anycast

The anycast address type is a scalable direct address for sending messages to one consumer. Messages sent to an anycast address are not stored, but are instead forwarded directly to the consumer. This method makes this address type ideal for request-reply (RPC) uses or even work distribution. This is the cheapest address type as it does not require any persistence.

2.2.1.4. Multicast

The multicast address type is a scalable direct address for sending messages to multiple consumers. Messages sent to a multicast address are forwarded to all consumers receiving messages on that address. Because message acknowledgments from consumers are not propagated to producers, only pre-settled messages can be sent to multicast addresses.

2.2.1.5. Subscription

Using the subscription address type you can create a subscription for a topic that holds messages published to the topic even if the subscriber is not attached. The consumer accesses the subscription using the following address syntax: <topic-address>::<subscription-address>. For example, for a subscription mysub on a topic mytopic the consumer accesses the subscription from the address mytopic::mysub. The default setting permits only a single consumer per subscription. This setting can be changed by editing the maxConsumers field of the subscription address.

Note

The maxConsumers setting cannot be modified for existing subscriptions.

2.3. Brokered address space

The brokered address space is designed to support broker-specific features, at the cost of limited scale in terms of the number of connections and addresses. This address space supports JMS transactions, message groups, and selectors on queues and topics.

Clients can connect as well as send and receive messages in this address space using the following protocols:

  • AMQP
  • CORE
  • OpenWire
  • MQTT
  • STOMP

2.3.1. Brokered address types

The brokered address space supports two address types:

  • queue
  • topic

2.3.1.1. Queue

The queue address type is a store-and-forward queue. This address type is appropriate for implementing a distributed work queue, handling traffic bursts, and other use cases where you want to decouple the producer and consumer. A queue in the brokered address space supports selectors, message groups, transactions, and other JMS features. Message order can be lost with released messages.

2.3.1.2. Topic

The topic address type supports the publish-subscribe messaging pattern in which there are 1..N producers and 1..M consumers. Each message published to a topic address is forwarded to all subscribers for that address. A subscriber can also be durable, in which case messages are kept until the subscriber has acknowledged them.

2.3.1.2.1. Hierarchical topics and wildcards

A client receiving from a topic address can specify a wildcard address with the topic address as the root. The wildcard behavior follows the MQTT syntax:

  • / is a separator
  • + matches one level
  • # matches one or more levels

So, for example:

  • a/#/b matches a/foo/b, a/bar/b, a/foo/bar/b
  • a/+/b matches a/foo/b and a/bar/b, but would not match a/foo/bar
2.3.1.2.2. Known issue with creating a subscriber on a hierarchical topic

A known issue exists where creating a subscriber on a hierarchical topic in AMQ Online causes the broker to instead create it as a competing consumer (handling the address like a queue rather than a topic). For more information about the specific workaround for your client, see the applicable client example section in Connecting applications to AMQ Online.

2.4. Address space plans

An address space is configured with an address space plan, which describes the allowed resource usage of that address space. The address space plans are configured by the service administrator and can vary between AMQ Online installations.

The address space plan can be changed if the address space requires more, or less, resources.

2.5. Listing available address space plans using the command line

You can list the address space plans available for your address space type.

Procedure

  1. Log in as a messaging tenant:

    oc login -u developer
  2. Retrieve the schema showing available address space plans (replace standard with brokered for the brokered address space type):

    oc get addressspaceschema standard -o jsonpath='{.spec.plans[*].name}'

2.6. Listing available authentication services using the command line

You can list the authentication services available for your address space type.

Procedure

  1. Log in as a messaging tenant:

    oc login -u developer
  2. Retrieve the schema with the authentication services listed (replace standard with brokered for the brokered address space type):

    oc get addressspaceschema standard -o jsonpath='{.spec.authenticationServices}'

2.7. Address space examples

2.7.1. Address space example

This address space example shows only the required options to create an AddressSpace.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard 1
  plan: standard-unlimited 2
1
The address space type can be either brokered or standard.
2
The address space plan depends on the address space type and what has been configured by the AMQ Online administrator. To view your available address space plans, see Listing available address space plans.

2.7.2. Address space example using an authentication service

This address space example shows how you can configure the authentication service of an AddressSpace.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice 1
1
The authentication service name depends on the available authentication services configured by the AMQ Online administrator. To view the available authentication services for your address space type, see Listing available authentication services.

2.7.3. Address space example using an external authentication service allowing overrides

This address space example shows how you can override the host name, port number, and realm for an external authentication service. Note that the ability to specify overrides depends on how the external authentication service is configured by the AMQ Online administrator.

For more information about how to configure an external authentication service to allow a messaging tenant to override host name, port number, and realm, see External authentication service example allowing overrides.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: external-authservice 1
    type: external
    overrides: 2
      realm: amq-online-infra-space-standard-auth
      host: standard-authservice-amq-online-infra.apps.wfd-28d9.openshiftworkshop.com
      port: 5671
      caCertSecret:
        name: my-ca-cert
1
The authentication service name depends on the available authentication services configured by the AMQ Online administrator. To view the available authentication services for your address space type, see Listing available authentication services.
2
Specifies the override values.

2.7.4. Address space examples exposing endpoints externally

These address space examples show how you can configure the external endpoints of an AddressSpace to access messaging endpoints outside the OpenShift cluster.

2.7.4.1. OpenShift LoadBalancer service example

To expose AddressSpace endpoints through OpenShift LoadBalancer services, the loadbalancer type is used:

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging 1
    service: messaging 2
    expose:
     type: loadbalancer 3
     loadBalancerPorts: 4
     - amqp
     - amqps
      annotations: 5
        mykey: myvalue
      loadBalancerSourceRanges: 6
      - 10.0.0.0/8
1
(Required) The name of the endpoint. The name specified affects the name of the OpenShift service to be created as well as the name of the endpoint in the status section of the AddressSpace.
2
(Required) The service configured for the endpoint. Valid values for service are messaging and mqtt. However, the mqtt service is supported for the standard address space type only.
3
(Required) The type of endpoint being exposed. The loadbalancer type creates an OpenShift LoadBalancer service. Valid values are route and loadbalancer.
4
(Required) A list of the ports to be exposed on the LoadBalancer service. For the messaging service, the valid values are amqp and amqps.
5
(Optional) A set of key-value annotation pairs that are added to the LoadBalancer Service object.
6
(Optional) The allowed source ranges that are accepted by the load balancer.

2.7.4.2. OpenShift route example

To expose AddressSpace endpoints as OpenShift routes, the route type is used:

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging 1
    service: messaging 2
    expose:
     type: route
     routeServicePort: amqps 3
     routeTlsTermination: passthrough 4
     routeHost: messaging.example.com 5
1
(Required) The name of the endpoint. The name specified affects the name of the OpenShift service to be created as well as the name of the endpoint in the status section of the AddressSpace.
2
(Required) The service configured for the endpoint. Valid values for service are messaging, or mqtt. However, the mqtt service is supported for the standard address space type only.
3
(Required) The name of the port to be exposed. With the route type, only a single TLS-enabled port can be specified. For the messaging service, the valid values are amqps or https.
4
(Required) The TLS termination policy to be used for the OpenShift route. For the messaging service, the amqps port requires passthrough to be specified, whereas https (websockets) also allows reencrypt.
5
(Optional) The host name to use for the created route.

2.7.5. Address space certificate provider configuration examples

The following address space examples show how you can configure the endpoints of an AddressSpace using different certificate providers. The certificate provider determines how certificates are issued for the endpoints of an AddressSpace.

2.7.5.1. openshift provider

The openshift certificate provider can be used to configure endpoints with certificates signed by the OpenShift cluster certificate authority (CA).

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging
    service: messaging
    cert:
     provider: openshift 1
1
(Required) The certificate provider type. Valid values are openshift (on OpenShift only), certBundle, and selfsigned (default value).

2.7.5.2. selfsigned provider

The selfsigned certificate provider can be used to configure endpoints with self-signed certificates. The CA for these certificates can be found in the status.caCert field of the AddressSpace resource.

Note

Using a self-signed certificate in production environments is not recommended.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging
    service: messaging
    cert:
     provider: selfsigned 1
1
(Required) The certificate provider type. Valid values are openshift (on OpenShift only), certBundle, and selfsigned (default value).

2.7.5.3. certBundle provider

The certBundle certificate provider can be used to configure endpoints with user-supplied certificates signed by your own CA. Certificate rotation can be performed by updating the tlsKey and tlsCert fields with updated certificates, and then updating the AddressSpace resource.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging
    service: messaging
    cert:
     provider: certBundle 1
     tlsKey: Y2VydGJ1bmRsZXByb3ZpZGVyY2VydA== 2
     tlsCert: Y2VydGJ1bmRsZXByb3ZpZGVyY2VydA== 3
1
(Required) The certificate provider type. Valid values are openshift (on OpenShift only), certBundle, and selfsigned (default value).
2
(Required) The base64-encoded value of the PEM private key (including the preamble).
3
(Required) The base64-encoded value of the PEM certificate (including the preamble).

2.7.6. Address space example exports

You can export your address space information using the following three export types:

  • ConfigMap
  • Secret
  • Service

2.7.6.1. ConfigMap and Secret type export examples

This example shows the format used by the ConfigMap export type. The format of the Secret export type uses the same keys as the ConfigMap export type, but the values are Base64-encoded.

service.host: messaging.svc
service.port.amqp: 5672
external.host: external.example.com
external.port: 5671
ca.crt: // PEM formatted CA

2.7.6.2. Service type export example

This example shows the format used by the Service export type.

  externalName:  messaging.svc
    ports:
    - name: amqp
      port: 5672
      protocol: TCP
      targetPort: 5672

2.8. Example address space status output

The AddressSpace resource contains a status field that can be used to retrieve information about its state and endpoints. The following output is an example of the output you can get from running oc get addressspace myspace -o yaml:

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  ...
status:
  isReady: false 1
  messages:
    - "One or more deployments are not ready: "
  endpointStatuses: 2
    - name: messaging
      cert: aGVsbG8= 3
      serviceHost: messaging-123.enmasse-infra.svc 4
      servicePorts: 5
        - name: amqp
          port: 5672
        - name: amqps
          port: 5671
      externalHost: messaging.example.com 6
      externalPorts: 7
        - name: amqps
          port: 443
1
The status.isReady field can be either true or false.
2
The status.endpointStatuses field provides information about available endpoints for this address space.
3
The cert field contains the base64-encoded certificate for a given endpoint.
4
The serviceHost field contains the cluster-internal host name for a given endpoint.
5
The servicePorts field contains the available ports for the cluster-internal host.
6
The externalHost field contains the external host name for a given endpoint.
7
The externalPorts field contains the available ports for the external host.

2.9. Example of exporting address space information into the application namespace

This address space example shows how you can export the endpoint information of an AddressSpace resource to a ConfigMap, Secret, or Service in the same namespace as the messaging application.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  authenticationService:
    name: standard-authservice
  endpoints:
  - name: messaging
    service: messaging
    exports:
    - kind: ConfigMap 1
      name: my-config 2
1
(Required) The type of export: ConfigMap, Secret, or Service. The resulting ConfigMap contains the values in the format shown in example exports format. For Secret, the same keys are used, but the values are base64-encoded. For Service, a OpenShift service of the type ExternalName is created. This provides applications running on OpenShift with a way to inject endpoint information or provide a proxy service in the same namespace as the application. For more information see example exports format.
2
(Required) The name of the resource to create and update.

When exporting endpoint information, the system:serviceaccounts:_amq-online-infra_ group must be granted privileges to create, update, and delete the configmap specified in the exports list. You can do this by creating an RBAC role and role-binding such as this one:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: rbac
rules:
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    verbs: [ "create" ]
  - apiGroups: [ "" ]
    resources: [ "configmaps" ]
    resourceNames: [ "my-config" ]
    verbs: [ "get", "update", "patch" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rbac-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: rbac
subjects:
- kind: Group
  name: system:serviceaccounts:_amq-online-infra_

2.10. Address space connector examples

You can federate a standard address space type with another AMQP server. Two methods of operation are supported: remote address connection and message store-and-forward.

Remote address connection involves mapping addresses on a remote AMQP endpoint into an address space. For example, suppose an AMQP server is running on the host messaging.example.com that you want to access by connecting using the AMQ Online endpoints. To enable remote address connection, you need to create an address space connector.

Message store-and-forward involves enabling address forwarding. First you need to create an address space connector. Then, you need to create an address forwarder for each address. For more information about address forwarding, see Address forwarding examples.

The following examples show how you can configure an address space connector.

2.10.1. Address space connector using SASL PLAIN

You can use SASL PLAIN when you do not want to use mutual TLS for authentication. Not enabling TLS is not recommended, since any user names and passwords are then sent as plain text.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  connectors:
  - name: remote1 1
    endpointHosts: 2
    - host: messaging.example.com
      port: 5672
    - host: messaging2.example.com
    idleTimeout: 3
    maxFrameSize: 4
    tls: {} 5
    credentials: 6
      username:
        value: test
      password:
        valueFromSecret:
          name: password-secret
          key: password.txt
    role: 7
    addresses: 8
    - name: p1
      pattern: "prices/*"
    - name: p2
      pattern: "clients/*/1"
1
(Required) Specifies the name of the connector. All remote addresses are prefixed with the connector name and a forward slash, /.
2
(Required) Specifies a list of endpoints for this connector. This list must contain at least one entry, and any additional entries are used for failover. If not otherwise specified, the port field value is set to the registered IANA port for AMQP (or AMQPS if TLS is enabled).
3
(Optional) Idle timeout of the AMQP connection (seconds). 0 disables the idle timeout.
4
(Optional) Max frame size of the AMQP connection.
5
(Optional) Enable TLS. The connector trusts global root CAs by default. To use a custom CA, specify a value for the caCert field.
6
(Optional) Specifies the username and password credentials to use for this connector. The values can be specified inline or by referencing a secret along with an optional key specifying the location within the secret. The secret must be readable by the system:serviceaccounts:_amq-online-infra_ group.
7
(Optional) Role of the connector. Valid values are "normal", "edge", and "route-container" (default value).
8
(Required) Specifies a list of patterns matching addresses to be exposed on the remote endpoint. The pattern consists of one or more tokens separated by a forward slash, /. A token can be one of the following: a * character, a # character, or a sequence of characters that do not include /, *, or #. The * token matches any single token. The # token matches zero or more tokens. * has higher precedence than #, and exact match has the highest precedence.

2.10.2. Address space connector using mutual TLS

Configuring a client TLS certificate enables SASL EXTERNAL to be used for authentication. The certificates can be specified inline or using a secret reference.

apiVersion: enmasse.io/v1beta1
kind: AddressSpace
metadata:
  name: myspace
spec:
  type: standard
  plan: standard-unlimited
  connectors:
  - name: remote1 1
    endpointHosts: 2
    - host: messaging.example.com
      port: 5671
    tls:
      caCert: 3
        valueFromSecret:
          name: remote-certs
          key: ca.crt
      clientCert: 4
        valueFromSecret:
          name: remote-certs
          key: tls.crt
      clientKey: 5
        valueFromSecret:
          name: remote-certs
          key: tls.key
    addresses:
    - name: p1
      pattern: "*"
1
(Required) Specifies the name of the connector. All remote addresses are prefixed with the connector name and a forward slash, /.
2
(Required) Specifies a list of endpoints for this connector. This list must contain at least one entry, and any additional entries are used for failover. If not otherwise specified, the port field value is set to the registered IANA port for AMQP (or AMQPS if TLS is enabled).
3
(Optional) Specifies the CA certificate to trust for the remote connection. The referenced secret must be readable by the system:serviceaccounts:_amq-online-infra_ group.
4
(Optional) Specifies the client certificate to use for mutual TLS authentication. The referenced secret must be readable by the system:serviceaccounts:_amq-online-infra_ group.
5
(Optional) Specifies the client private key to use for mutual TLS authentication. The referenced secret must be readable by the system:serviceaccounts:_amq-online-infra_ group.

2.11. Creating address spaces using the command line

In AMQ Online, you create address spaces using standard command-line tools.

Procedure

  1. Log in as a messaging tenant:

    oc login -u developer
  2. Create the project for the messaging application:

    oc new-project myapp
  3. Create an address space definition:

    apiVersion: enmasse.io/v1beta1
    kind: AddressSpace
    metadata:
      name: myspace
    spec:
      type: standard
      plan: standard-unlimited
  4. Create the address space:

    oc create -f standard-address-space.yaml
  5. Check the status of the address space:

    oc get addressspace myspace -o jsonpath={.status.isReady}

    The address space is ready for use when the previous command outputs true.

2.12. Creating an address space using the Red Hat AMQ Console

You can create a new address space using the Red Hat AMQ Console, including configuring the endpoints of an address space using different certificate providers and creating endpoints to make the address space available for messaging applications to use.

Note

If you choose not to configure endpoints for your address space, the system creates a default set of endpoints as OpenShift routes for AMQPS and AMQP-WSS, secured with a system generated (self-signed) certificate and a cluster service.

Procedure

  1. Log in to the Red Hat AMQ Console.

    For more information about how to access the Red Hat AMQ Console, see Accessing the Red Hat AMQ Console.

  2. Click Create Address Space. The Create an instance wizard opens.
  3. Complete the required fields and when you are finished, click Finish to create the new address space.

When the address space has been successfully created, you can click the address space name to view information about the newly created address space, including messaging and application statistics and endpoint information.

2.13. Changing the address space plan associated with an address space using the Red Hat AMQ Console

You can change the address space plan that is associated with an address space using the Red Hat AMQ Console.

Prerequisites

Procedure

  1. Log in to the Red Hat AMQ Console. For more information, see Accessing the Red Hat AMQ Console.
  2. Locate the address space for which you want to change the address space plan.
  3. In the far right column, click the vertical ellipsis icon and select Edit. The Edit window opens.
  4. In the Address space plan field, select a different plan from the list and click Confirm. The address space plan is changed for that address space.

2.14. Changing the authentication service associated with an address space using the Red Hat AMQ Console

You can change the authentication service that is associated with an address space using the Red Hat AMQ Console.

Prerequisites

Procedure

  1. Log in to the Red Hat AMQ Console. For more information, see Accessing the Red Hat AMQ Console.
  2. Locate the address space for which you want to change the authentication service.
  3. In the far right column, click the vertical ellipsis icon and select Edit. The Edit window opens.
  4. In the Authentication Service field, select a different authentication service from the list and click Confirm. The authentication service is changed for that address space.

2.15. Deleting an address space using the Red Hat AMQ Console

You can delete an existing address space using the Red Hat AMQ Console.

Procedure

  1. Log in to the Red Hat AMQ Console.

    For more information about how to access the Red Hat AMQ Console, see Accessing the Red Hat AMQ Console.

  2. Locate the address space that you want to delete.
  3. In the far right column, click the vertical ellipsis icon and select Delete. The delete confirmation window opens.
  4. Confirm your selection by clicking Delete. The address space is deleted.

2.16. Example commands for retrieving address space information

The following table shows the commands for retrieving address space information.

Table 2.1. Retrieving address space information commands table

To retrieve the…​Run this command:

status of an address space

oc get addressspace myspace -o jsonpath={.status.isReady}

base64-encoded PEM certificate for the messaging endpoint

oc get addressspace myspace -o 'jsonpath={.status.caCert}'

host name for the messaging endpoint

oc get addressspace myspace -o 'jsonpath={.status.endpointStatuses[?(@.name=="messaging")].externalHost}'

2.17. Replacing address spaces using the command line

Address spaces can be replaced in order to change the plan, endpoints, or network policies, or to replace certificates if using the certBundle certificate provider. When changing the plan, AMQ Online will attempt to apply the new plan if the current set of addresses fits within the new quota. If it does not, an error is provided on the AddressSpace resource.

Procedure

  1. Log in as a messaging tenant:

    oc login -u developer
  2. Select the project for the messaging application:

    oc project myapp
  3. Update address space definition:

    apiVersion: enmasse.io/v1beta1
    kind: AddressSpace
    metadata:
      name: myspace
    spec:
      type: standard
      plan: standard-small
  4. Replace the address space:

    oc replace -f standard-address-space-replace.yaml
  5. Check the status of the address space:

    oc get addressspace myspace -o jsonpath={.status.isReady}

    The address space is ready for use when the above command outputs true.