Installing and Managing AMQ Online on OpenShift

Red Hat AMQ 7.5

For use with AMQ Online 1.3

Abstract

This guide describes how to install and manage AMQ Online.

Chapter 1. Introduction

1.1. AMQ Online overview

Red Hat AMQ Online is an OpenShift-based mechanism for delivering messaging as a managed service. With Red Hat AMQ Online, administrators can configure a cloud-native, multi-tenant messaging service either in the cloud or on premise. Developers can provision messaging using the Red Hat AMQ Console. Multiple development teams can provision the brokers and queues from the Console, without requiring each team to install, configure, deploy, maintain, or patch any software.

AMQ Online can provision different types of messaging depending on your use case. A user can request messaging resources by creating an address space. AMQ Online currently supports two address space types, standard and brokered, each with different semantics. The following diagrams illustrate the high-level architecture of each address space type:

Figure 1.1. Standard address space

Standard address space

Figure 1.2. Brokered address space

Brokered address space

1.2. Supported features

The following table shows the supported features for AMQ Online 1.3:

Table 1.1. Supported features reference table

Feature Brokered address spaceStandard address space

Address type

Queue

Yes

Yes

Topic

Yes

Yes

Multicast

No

Yes

Anycast

No

Yes

Subscription

No

Yes

Messaging protocol

AMQP

Yes

Yes

MQTT

Yes

Technology preview only

CORE

Yes

No

OpenWire

Yes

No

STOMP

Yes

No

Transports

TCP

Yes

Yes

WebSocket

Yes

Yes

Durable subscriptions

JMS durable subscriptions

Yes

No

"Named" durable subscriptions

No

Yes

JMS

Transaction support

Yes

No

Selectors on queues

Yes

No

Message ordering guarantees (including prioritization)

Yes

No

Scalability

Scalable distributed queues and topics

No

Yes

1.3. AMQ Online user roles

AMQ Online users can be defined broadly in terms of two user roles: service administrator and messaging tenant. Depending on the size of your organization, these roles might be performed by the same person or different people.

The service administrator performs the initial installation and any subsequent upgrades. The service administrator might also deploy and manage the messaging infrastructure, such as monitoring the routers, brokers, and administration components; and creating the address space plans and address plans. Installing and Managing AMQ Online on OpenShift provides information about how to set up and manage AMQ Online as well as configure the infrastructure and plans as a service administrator.

The messaging tenant can request messaging resources, using both cloud-native APIs and tools. The messaging tenant can also manage the users and permissions of a particular address space within the messaging system as well as create address spaces and addresses. For more information about how to manage address spaces, addresses, and users, see Using AMQ Online on OpenShift Container Platform.

1.4. Supported configurations

For more information about AMQ Online supported configurations see Red Hat AMQ 7 Supported Configurations.

1.5. Document conventions

1.5.1. Variable text

This document contains code blocks with variables that you must replace with values specific to your installation. In this document, such text is styled as italic monospace.

For example, in the following code block, replace my-namespace with the namespace used in your installation:

sed -i 's/amq-online-infra/my-namespace/' install/bundles/enmasse-with-standard-authservice/*.yaml

Chapter 2. Installing AMQ Online

AMQ Online can be installed by applying the YAML files using the OpenShift Container Platform command-line interface, or by running the Ansible playbook.

Prerequisites

  • To install AMQ Online, the OpenShift Container Platform command-line interface (CLI) is required.

  • An OpenShift cluster is required.
  • A user on the OpenShift cluster with cluster-admin permissions is required to set up the required cluster roles and API services.

2.1. Downloading AMQ Online

Procedure

Note

Although container images for AMQ Online are available in the Red Hat Container Catalog, we recommend that you use the YAML files provided instead.

2.2. Installing AMQ Online using a YAML bundle

The simplest way to install AMQ Online is to use the predefined YAML bundles.

Procedure

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

    oc login -u system:admin
  2. (Optional) If you want to deploy to a project other than amq-online-infra you must run the following command and substitute amq-online-infra in subsequent steps:

    sed -i 's/amq-online-infra/my-project/' install/bundles/amq-online/*.yaml
  3. Create the project where you want to deploy AMQ Online:

    oc new-project amq-online-infra
  4. Change the directory to the location of the downloaded release files.
  5. Deploy using the amq-online bundle:

    oc apply -f install/bundles/amq-online
  6. (Optional) Install the example plans and infrastructure configuration:

    oc apply -f install/components/example-plans
  7. (Optional) Install the example roles:

    oc apply -f install/components/example-roles
  8. (Optional) Install the standard authentication service:

    oc apply -f install/components/example-authservices/standard-authservice.yaml
  9. (Optional) Install the Service Catalog integration:

    oc apply -f install/components/service-broker
    oc apply -f install/components/cluster-service-broker

2.3. Installing AMQ Online using Ansible

Installing AMQ Online using Ansible requires creating an inventory file with the variables for configuring the system. Example inventory files can be found in the ansible/inventory folder.

The following example inventory file enables a minimal installation of AMQ Online:

[enmasse]
localhost ansible_connection=local

[enmasse:vars]
namespace=enmasse-infra
enable_rbac=False
api_server=True
service_catalog=False
register_api_server=True
keycloak_admin_password=admin
authentication_services=["standard"]
monitoring_namespace=enmasse-monitoring
monitoring_operator=False
monitoring=False

The following Ansible configuration settings are supported:

Table 2.1. Ansible configuration settings

NameDescriptionDefault valueRequired

namespace

Specifies the project where AMQ Online is installed.

Not applicable

yes

enable_rbac

Specifies whether to enable RBAC authentication of REST APIs

True

no

service_catalog

Specifies whether to enable integration with the Service Catalog

False

no

authentication_services

Specifies the list of authentication services to deploy. Supported values are none and standard.

none

no

keycloak_admin_password

Specifies the admin password to use for the standard authentication service Red Hat Single Sign-On instance

Not applicable

yes (if standard authentication service is enabled)

api_server

Specifies whether to enable the REST API server

True

no

register_api_server

Specifies whether to register the API server with OpenShift master

False

no

secure_api_server

Specifies whether to enable mutual TLS for the API server

False

no

install_example_plans

Specifies whether to install example plans and infrastructure configurations

True

no

monitoring_namespace

Specifies the project where AMQ Online monitoring is installed.

Not applicable

yes

monitoring_operator

Specifies whether to install the monitoring infrastructure

Not applicable

no

monitoring

Specifies whether to install the service monitors, Prometheus rules, and Grafana dashboards for monitoring AMQ Online

Not applicable

no

Procedure

  1. Create an inventory file.
  2. Run the Ansible playbook:

    ansible-playbook -i inventory-file ansible/playbooks/openshift/deploy_all.yml

2.4. Installing and configuring AMQ Online using the Operator Lifecycle Manager

You can use the Operator Lifecycle Manager to install and configure an instance of AMQ Online.

In OpenShift 4.x, the Operator Lifecycle Manager (OLM) helps users install, update, and manage the life cycle of all Operators and their associated services running across their clusters. It is part of the Operator Framework, an open source toolkit designed to manage Kubernetes native applications (Operators) in an effective, automated, and scalable way.

The OLM runs by default in OpenShift 4.x, which aids cluster administrators in installing, upgrading, and granting access to Operators running on their cluster. The OpenShift console provides management screens for cluster administrators to install Operators and grant specific projects access to use the catalog of Operators available on the cluster.

OperatorHub is the graphical interface that OpenShift cluster administrators use to discover, install, and upgrade Operators. With one click, these Operators can be pulled from OperatorHub, installed on the cluster, and managed by the OLM, ready for engineering teams to self-service manage the software in development, test, and production environments.

2.4.1. Installing AMQ Online from the OperatorHub using the OpenShift console

You can install the AMQ Online Operator on an OpenShift 4.x cluster by using OperatorHub in the OpenShift console.

Prerequisites

  • Access to an OpenShift 4.x cluster and an account with cluster-admin permissions.

Procedure

  1. In the OpenShift 4.x console, log in using an account with cluster-admin privileges.
  2. To create the project where you want to deploy AMQ Online, click Home > Projects, and then click Create Project. The Create Project window opens.
  3. In the Name field, type amq-online-infra and click Create. The amq-online-infra project is created.
  4. Click Catalog > OperatorHub.
  5. In the Filter by keyword box, type AMQ Online to find the AMQ Online Operator.
  6. Click the AMQ Online Operator. Information about the Operator is displayed.
  7. Read the information about the Operator and click Install. The Create Operator Subscription page opens.
  8. On the Create Operator Subscription page, for Installation Mode, click A specific namespace on the cluster, and then select the amq-online-infra namespace from the drop-down list.
  9. Accept all of the remaining default selections and click Subscribe.

    The amq-online page is displayed, where you can monitor the installation progress of the AMQ Online Operator subscription.

  10. After the subscription upgrade status is shown as Up to date, click Catalog > Installed Operators to verify that the AMQ Online ClusterServiceVersion (CSV) is displayed and its Status ultimately resolves to InstallSucceeded in the amq-online-infra namespace.

    For troubleshooting information, see the OpenShift documentation.

2.4.2. Configuring AMQ Online using the OpenShift console

After installing AMQ Online from the OperatorHub using the OpenShift console, create a new instance of a custom resource for the following items within the amq-online-infra project:

  • an authentication service
  • infrastructure configuration for an address space type (the example uses the standard address space type)
  • an address space plan
  • an address plan

After creating the new instances of the custom resources, next:

The following procedures use the example data that is provided when using the OpenShift console.

2.4.2.1. Creating an authentication service custom resource using the OpenShift console

You must create a custom resource for an authentication service to use AMQ Online. This example uses the standard authentication service.

Procedure

  1. From the dropdown menu, select the amq-online-infra project.
  2. Click Catalog > Installed Operators.
  3. Click Add > Import YAML. The Import YAML window opens.
  4. Copy the following code:

    apiVersion: admin.enmasse.io/v1beta1
    kind: AuthenticationService
    metadata:
      name: standard-authservice
    spec:
      type: standard
  5. In the Import YAML window, paste the copied code and click Create. The AddressPlan Overview page is displayed.
  6. Click Workloads > Pods. In the Readiness column, the Pod status is Ready when the custom resource has been deployed.

2.4.2.2. Creating an infrastructure configuration custom resource using the OpenShift console

You must create an infrastructure configuration custom resource to use AMQ Online. This example uses StandardInfraConfig for a standard address space.

Procedure

  1. From the dropdown menu, select the amq-online-infra project.
  2. Click Catalog > Installed Operators.
  3. Click Add > Import YAML. The Import YAML window opens.
  4. Copy the following code for StandardInfraConfig:

    apiVersion: admin.enmasse.io/v1beta1
    kind: StandardInfraConfig
    metadata:
      name: default
  5. In the Import YAML window, paste the copied code and click Create. The StandardInfraConfig Overview page is displayed.
  6. Click Workloads > Pods. In the Readiness column, the Pod status is Ready when the custom resource has been deployed.

2.4.2.3. Creating an address space plan custom resource using the OpenShift console

You must create an address space plan custom resource to use AMQ Online. This procedure uses the example data that is provided when using the OpenShift console.

Procedure

  1. From the dropdown menu, select the amq-online-infra project.
  2. Click Catalog > Installed Operators.
  3. Click Add > Import YAML. The Import YAML window opens.
  4. Copy the following code:

    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressSpacePlan
    metadata:
      name: standard-small
    spec:
      addressSpaceType: standard
      infraConfigRef: default
      addressPlans:
        - standard-small-queue
      resourceLimits:
        router: 2.0
        broker: 3.0
        aggregate: 4.0
  5. In the Import YAML window, paste the copied code and click Create. The AddressPlan Overview page is displayed.
  6. Click Workloads > Pods. In the Readiness column, the Pod status is Ready when the custom resource has been deployed.

2.4.2.4. Creating an address plan custom resource using the OpenShift console

You must create an address plan custom resource to use AMQ Online. This procedure uses the example data that is provided when using the OpenShift console.

Procedure

  1. From the dropdown menu, select the amq-online-infra project.
  2. Click Catalog > Installed Operators.
  3. Click Add > Import YAML. The Import YAML window opens.
  4. Copy the following code:

    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressPlan
    metadata:
      name: standard-small-queue
    spec:
      addressType: queue
      resources:
        router: 0.01
        broker: 0.1
  5. In the Import YAML window, paste the copied code and click Create. The AddressPlan Overview page is displayed.
  6. Click Workloads > Pods. In the Readiness column, the Pod status is Ready when the custom resource has been deployed.

Chapter 3. Upgrading AMQ Online

AMQ Online supports upgrades between minor versions using cloud-native tools. When upgrading, applying the configuration change automatically triggers the upgrade process to begin.

Using the same method that was used to initially install AMQ Online to upgrade to a newer version of AMQ Online is recommended.

Upgrading AMQ Online is accomplished by applying the YAML files for the new version.

3.1. Preservation of messages when upgrading from AMQ Online 1.0.x and 1.1.0 only

The impact of ENTMQMAAS-1170 is that messages stored within brokers of AMQ Online 1.0.x and 1.1.0 are lost whenever the broker Pods are restarted.

When upgrading to the current version of AMQ Online, this procedure allows the preservation of the messages stored in the currently running instance of AMQ Online.

This procedure cannot preserve messages present on topic subscriptions. These messages will be lost. If the messages are valuable to your application, ensure that the subscribing applications have consumed all pending messages before beginning this procedure. In addition, if upgrading from AMQ Online 1.0.x, you must remove any subscription addresses.

Prerequisites

  • You must shut down or quiesce all messaging applications using the AMQ Online instance so that there is no ongoing messaging traffic.
  • If upgrading from AMQ Online 1.0.x, you must remove any subscription addresses before beginning this procedure.

Procedure

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

    oc login -u system:admin
  2. Switch to the project where AMQ Online is installed:

    oc project amq-online-infra
  3. If upgrading from AMQ Online 1.0.x, remove any topic subscription addresses.

    1. Identify the subscription addresses:

      oc get address --selector=addressType=subscription --all-namespaces
    2. Delete the subscription address from each project where they exist:

      oc delete address --selector=addressType=subscription --namespace <namespace>
  4. Run the migration script located in the AMQ Online installation bundle:

    ./migrate_artemis_journal.sh

    The script prompts you to confirm you want to proceed, and then copies the journal to a persistent location. The output from the script is similar to this example:

    Remediation for https://issues.jboss.org/browse/ENTMQMAAS-1170
    This script will copy the current Artemis journal for broker pods running in this AMQ Online 1.0/1.1.0 infra namespace to the correct persistent location.  It should be run before upgrade to AMQ Online 1.1.1.
    It is important that applications using the AMQ Online are shutdown (or quiesced) before you proceed so that there is no messaging traffic through the system.
    Are you sure? Y
    =========
    Processing broker pod broker-qxv5nefate-kmye-0
    Detected Artemis version 2.6.3
    Successfully processed broker pod broker-qxv5nefate-kmye-0
    =========
    Processing broker pod broker.7q0b04roxv-d4ddfb45f-zbjlq
    Detected Artemis version 2.6.3
    Successfully processed broker pod broker.7q0b04roxv-d4ddfb45f-zbjlq
    All broker pods processed
  5. Perform the appropriate upgrading procedure, given your original method of installation:

3.2. Upgrading AMQ Online using a YAML bundle

Prerequisites

Procedure

  1. Log in as a service operator:

    oc login -u system:admin
  2. Select the project where AMQ Online is installed:

    oc project amq-online-infra
  3. Apply the new release bundle:

    oc apply -f install/bundles/amq-online
  4. Monitor pods while they are restarted:

    oc get pods -w

    The pods restart and become active within several minutes.

3.3. Upgrading AMQ Online using Ansible

Prerequisites

Procedure

  1. Log in as a service operator:

    oc login -u system:admin
  2. Run the Ansible playbook from the new release:

    ansible-playbook -i inventory-file ansible/playbooks/openshift/deploy_all.yml
  3. Monitor pods while they are restarted:

    oc get pods -w

    The pods restart and become active within several minutes.

Chapter 4. Uninstalling AMQ Online

You must uninstall AMQ Online using the same method that you used to install AMQ Online.

4.1. Uninstalling AMQ Online using the YAML bundle

This method uninstalls AMQ Online that was installed using the YAML bundle.

Procedure

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

    oc login -u system:admin
  2. Delete the cluster-level resources:

    oc delete clusterrolebindings -l app=enmasse
    oc delete crd -l app=enmasse
    oc delete clusterroles -l app=enmasse
    oc delete apiservices -l app=enmasse
    oc delete oauthclients -l app=enmasse
  3. (Optional) Delete the service catalog integration:

    oc delete clusterservicebrokers -l app=enmasse
  4. Delete the project where AMQ Online is deployed:

    oc delete project amq-online-infra

4.2. Uninstalling AMQ Online using Ansible

Uninstalling AMQ Online using Ansible requires using the same inventory file that was used for installing AMQ Online.

Note

The playbook deletes the amq-online-infra project.

Procedure

  1. Run the Ansible playbook, where inventory-file specifies the inventory file used at installation:

    ansible-playbook -i inventory-file ansible/playbooks/openshift/uninstall.yml

Chapter 5. Configuring AMQ Online

5.1. Service configuration resources and definition

The service operator configures AMQ Online by defining resources constituting the "service configuration". This configuration contains instances of the following resource types:

  • AuthenticationService - Describes an authentication service instance used to authenticate messaging clients.
  • AddressSpacePlan - Describes the messaging resources available for address spaces using this plan, such as the available address plans and the amount of router and broker resources that can be used.
  • AddressPlan - Describes the messaging resources consumed by a particular address using this plan, such as what fraction of routers and brokers an address will use and other properties that should be set for multiple addresses.
  • StandardInfraConfig - Describes the router and broker configuration for the standard address space type such as memory limits, storage capacity, affinity, and more.
  • BrokeredInfraConfig - Describes the broker configuration for the brokered address space type such as memory limits, storage capacity, affinity, and more.

When created, these resources define the configuration that is available to the messaging tenants.

The following diagram illustrates the relationship between the different service configuration resources (green) and how they are referenced by the messaging tenant resources (blue).

5.2. Minimal service configuration

Configuring AMQ Online for production takes some time and consideration. The following procedure will get you started with a minimal service configuration. For a more complete example, navigate to the install/components/example-plans folder of the AMQ Online distribution. All of the commands must be run in the namespace where AMQ Online is installed.

Procedure

  1. Save the example configuration:

    apiVersion: admin.enmasse.io/v1beta1
    kind: StandardInfraConfig
    metadata:
      name: default
    spec: {}
    ---
    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressPlan
    metadata:
      name: standard-small-queue
    spec:
      addressType: queue
      resources:
        router: 0.01
        broker: 0.1
    ---
    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressSpacePlan
    metadata:
      name: standard-small
    spec:
      addressSpaceType: standard
      infraConfigRef: default
      addressPlans:
      - standard-small-queue
      resourceLimits:
        router: 2.0
        broker: 3.0
        aggregate: 4.0
    ---
    apiVersion: admin.enmasse.io/v1beta1
    kind: AuthenticationService
    metadata:
      name: none-authservice
    spec:
      type: none
  2. Apply the example configuration:

    oc apply -f service-config.yaml

5.3. Address space plans

Address space plans are used to configure quotas and control the resources consumed by address spaces. Address space plans are configured by the AMQ Online service operator and are selected by the messaging tenant when creating an address space.

AMQ Online includes a default set of plans that are sufficient for most use cases.

Plans are configured as custom resources. The following example shows a plan for the standard address space:

apiVersion: admin.enmasse.io/v1beta2
kind: AddressSpacePlan
metadata:
  name: restrictive-plan
  labels:
    app: enmasse
spec:
  displayName: Restrictive Plan
  displayOrder: 0
  infraConfigRef: default 1
  shortDescription: A plan with restrictive quotas
  longDescription: A plan with restrictive quotas for the standard address space
  addressSpaceType: standard 2
  addressPlans: 3
  - small-queue
  - small-anycast
  resourceLimits: 4
    router: 2.0
    broker: 2.0
    aggregate: 2.0
1
A reference to the StandardInfraConfig (for the standard address space type) or the BrokeredInfraConfig (for the brokered address space type) describing the infrastructure deployed for address spaces using this plan.
2
The address space type this plan applies to, either standard or brokered.
3
A list of address plans available to address spaces using this plan.
4
The maximum number of routers (router) and brokers (broker) for address spaces using this plan. For the brokered address space type, only the broker field is required.

The other fields are used by the Red Hat AMQ Console UI. Note the field spec.infraConfigRef, which points to an infrastructure configuration that must exist when an address space using this plan is created. For more information about infrastructure configurations, see Infrastructure configuration.

5.4. Creating address space plans

Procedure

  1. Log in as a service admin:

    oc login -u system:admin
  2. Select the project where AMQ Online is installed:

    oc project amq-online-infra
  3. Create an address space plan definition:

    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressSpacePlan
    metadata:
      name: restrictive-plan
      labels:
        app: enmasse
    spec:
      displayName: Restrictive Plan
      displayOrder: 0
      infraConfigRef: default
      shortDescription: A plan with restrictive quotas
      longDescription: A plan with restrictive quotas for the standard address space
      addressSpaceType: standard
      addressPlans:
      - small-queue
      - small-anycast
      resourceLimits:
        router: 2.0
        broker: 2.0
        aggregate: 2.0
  4. Create the address space plan:

    oc create -f restrictive-plan.yaml
  5. Verify that schema has been updated and contains the plan:

    oc get addressspaceschema standard -o yaml

5.5. Address plans

Address plans specify the expected resource usage of a given address. The sum of the resource usage for all resource types determines the amount of infrastructure provisioned for an address space. A single router and broker pod has a maximum usage of one. If a new address requires additional resources and the resource consumption is within the address space plan limits, a new pod will be created automatically to handle the increased load.

Address plans are configured by the AMQ Online service operator and are selected when creating an address.

AMQ Online includes a default set of address plans that are sufficient for most use cases.

In the Address space plans section, the address space plan references two address plans: small-queue and small-anycast. These address plans are stored as custom resources and are defined as follows:

apiVersion: admin.enmasse.io/v1beta2
kind: AddressPlan
metadata:
  name: small-queue
  labels:
    app: enmasse
spec:
  displayName: Small queue plan
  displayOrder: 0
  shortDescription: A plan for small queues
  longDescription: A plan for small queues that consume little resources
  addressType: queue 1
  resources: 2
    router: 0.2
    broker: 0.3
  partitions: 1 3
1
The address type this plan applies to.
2
The resources consumed by addresses using this plan. The router field is optional for address plans referenced by a brokered address space plan.
3
The number of partitions that should be created for queues using this plan. Only available in the standard address space.

The other fields are used by the Red Hat AMQ Console UI.

A single router can support five instances of addresses and broker can support three instances of addresses with this plan. If the number of addresses with this plan increases to four, another broker is created. If it increases further to six, another router is created as well.

In the standard address space, address plans for the queue address type may contain a field partitions, which allows a queue to be sharded accross multiple brokers for HA and improved performance. Specifying an amount of broker resource above 1 will automatically cause a queue to be partitioned.

Note

A sharded queue no longer guarantees message ordering.

Although the example address space plan in Address space plans allows two routers and two brokers to be deployed, it only allows two pods to be deployed in total. This means that the address space is restricted to three addresses with the small-queue plan.

The small-anycast plan does not consume any broker resources, and can provision two routers at the expense of not being able to create any brokers:

apiVersion: admin.enmasse.io/v1beta2
kind: AddressPlan
metadata:
  name: small-anycast
  labels:
    app: enmasse
spec:
  addressType: anycast
  resources:
    router: 0.2

With this plan, up to 10 addresses can be created.

5.6. Creating address plans

Procedure

  1. Log in as a service admin:

    oc login -u system:admin
  2. Select the project where AMQ Online is installed:

    oc project amq-online-infra
  3. Create an address plan definition:

    apiVersion: admin.enmasse.io/v1beta2
    kind: AddressPlan
    metadata:
      name: small-anycast
      labels:
        app: enmasse
    spec:
      addressType: anycast
      resources:
        router: 0.2
  4. Create the address plan:

    oc create -f small-anycast-plan.yaml
  5. Verify that schema has been updated and contains the plan:

    oc get addressspaceschema standard -o yaml

5.7. Infrastructure configuration

AMQ Online creates infrastructure components such as routers, brokers, and consoles. These components can be configured while the system is running, and AMQ Online automatically updates the components with the new settings. The AMQ Online service operator can edit the AMQ Online default infrastructure configuration or create new configurations.

Infrastructure configurations can be referred to from one or more address space plans. For more information about address space plans, see Address space plans.

Infrastructure configuration can be managed for both brokered and standard infrastructure using BrokeredInfraConfig and StandardInfraConfig resources.

5.7.1. Brokered infrastructure configuration

BrokeredInfraConfig resources are used to configure infrastructure deployed by brokered address spaces. Address space plans reference the brokered infrastructure configuration using the spec.infraConfigRef field. For more information about address space plans, see Address space plans.

For detailed information about the available brokered infrastructure configuration fields, see the Brokered infrastructure configuration fields table.

5.7.1.1. Brokered infrastructure configuration example

The following example of a brokered infrastructure configuration file shows the various settings that can be specified.

apiVersion: admin.enmasse.io/v1beta1
kind: BrokeredInfraConfig
metadata:
  name: brokered-infra-config-example
spec:
  version: "0.26" 1
  admin: 2
    resources:
      memory: 256Mi
    podTemplate:
      metadata:
        labels:
          key: value
  broker: 3
    resources:
      memory: 2Gi
      storage: 100Gi
    addressFullPolicy: PAGE
    podTemplate: 4
      spec:
        priorityClassName: messaging
1
Specifies the AMQ Online version used. When upgrading, AMQ Online uses this field to determine whether to upgrade the infrastructure to the requested version. If omitted, the version is assumed to be the same version as the controllers reading the configuration.
2
Specifies the settings you can configure for the admin components.
3
Specifies the settings you can configure for the broker components. Note that changing the .broker.resources.storage setting does not configure the existing broker storage size.
4
For both admin and broker components you can configure the following podTemplate elements:
  • metadata.labels
  • spec.priorityClassName
  • spec.tolerations
  • spec.affinity
  • spec.containers.readinessProbe
  • spec.containers.livenessProbe
  • spec.containers.resources
  • spec.containers.env

    All other podTemplate elements are ignored. For more information about these elements, see the OpenShift documentation in the following Related links section.

    For more information about how to set a readiness probe timeout, see Overriding the readiness probe timing for brokered infrastructure configuration.

For detailed information about all of the available brokered infrastructure configuration fields, see the Brokered infrastructure configuration fields table.

Related links

5.7.1.2. Overriding the probe timing for brokered infrastructure configuration

You can override the default values for the probe timing on broker resources. You might want to change the default values if, for example, it takes longer than expected for the broker storage to become available, or a server is slow.

The following example shows how to override certain default values of the readiness probe for broker resources.

apiVersion: admin.enmasse.io/v1beta1
kind: BrokeredInfraConfig
metadata:
  name: brokered-infra-config
spec:
  broker:
    ...
    podTemplate:
      spec:
        containers:
          - name: broker 1
            readinessProbe:
              failureThreshold: 6 2
              initialDelaySeconds: 20 3
1
The name value must match the target container name. For a broker, the podTemplate name is broker.
2
Specifies the number of times that OpenShift tries when a Pod starts and the probe fails before either the Pod is marked Unready for a readiness probe, or restarting the container for a liveness probe. The default value is 3, and the minimum value is 1.
3
Specifies the number of seconds before performing the first probe after the container starts.

5.7.2. Standard infrastructure configuration

StandardInfraConfig resources are used to configure infrastructure deployed by standard address spaces. Address space plans reference the standard infrastructure configuration using the spec.infraConfigRef field. For more information about address space plans, see Address space plans.

For detailed information about the available standard infrastructure configuration fields, see the Standard infrastructure configuration fields table.

5.7.2.1. Standard infrastructure configuration example

The following example of a standard infrastructure configuration file shows the various settings that can be specified.

apiVersion: admin.enmasse.io/v1beta1
kind: StandardInfraConfig
metadata:
  name: myconfig
spec:
  version: "0.26" 1
  admin: 2
    resources:
      memory: 256Mi
  broker: 3
    resources:
      memory: 2Gi
      storage: 100Gi
    addressFullPolicy: PAGE
  router: 4
    resources:
      memory: 256Mi
    linkCapacity: 1000
    minReplicas: 1
    policy:
      maxConnections: 1000
      maxConnectionsPerHost: 1
      maxConnectionsPerUser: 10
      maxSessionsPerConnection: 10
      maxSendersPerConnection: 5
      maxReceiversPerConnection: 5
    podTemplate: 5
      spec:
        affinity:
          nodeAffinity:
            preferredDuringSchedulingIgnoredDuringExecution:
            - weight: 1
              preference:
              matchExpressions:
              - key: e2e-az-EastWest
                operator: In
                values:
                - e2e-az-East
                - e2e-az-West
1
Specifies the AMQ Online version used. When upgrading, AMQ Online uses this field to determine whether to upgrade the infrastructure to the requested version. If omitted, the version is assumed to be the same version as the controllers reading the configuration.
2
Specifies the settings you can configure for the admin components.
3
Specifies the settings you can configure for the broker components. Changing the .broker.resources.storage setting does not configure the existing broker storage size.
4
Specifies the settings you can configure for the router components.
5
For admin, broker, and router components you can configure the following podTemplate elements:
  • metadata.labels
  • spec.priorityClassName
  • spec.tolerations
  • spec.affinity
  • spec.containers.resources
  • spec.containers.readinessProbe
  • spec.containers.livenessProbe
  • spec.containers.env

    All other podTemplate elements are ignored. For more information about these elements, see the OpenShift documentation in the following Related links section.

    For more information about how to set a readiness probe timeout, see Overriding the readiness probe timing for standard infrastructure configuration.

For detailed information about all of the available standard infrastructure configuration fields, see the Standard infrastructure configuration fields table.

Related links

5.7.2.2. Overriding the probe timing for standard infrastructure configuration

You can override the default values for probe timing on broker and router resources. You might want to change the default values if, for example, it takes longer than expected for the broker storage to become available, or a server is slow.

The following example shows how to override certain default values of the readiness probe timeout for a broker resource and a liveness probe for a router resource.

apiVersion: admin.enmasse.io/v1beta1
kind: StandardInfraConfig
metadata:
  name: standard-infra-config
spec:
  broker:
    ...
    podTemplate:
      spec:
        containers:
          - name: broker 1
            readinessProbe:
              failureThreshold: 6 2
              initialDelaySeconds: 20 3

  router:
    ...
    podTemplate:
      spec:
        containers:
          - name: router 4
            livenessProbe:
              failureThreshold: 6 5
              initialDelaySeconds: 20 6
1 4
The name value must match the target container name. For example, for a broker podTemplate, name is broker, and for a router podTemplate, it is router.
2 5
Specifies the number of times that OpenShift tries when a Pod starts and the probe fails before either the Pod is marked Unready for a readiness probe, or restarting the container for a liveness probe. The default value is 3, and the minimum value is 1.
3 6
Specifies the number of seconds before performing the first probe after the container starts.

5.8. Creating and editing infrastructure configurations

You can create a new infrastructure configuration or edit an existing one. For more information, see Infrastructure configuration.

Procedure

  1. Log in as a service operator:

    oc login -u developer
  2. Change to the project where AMQ Online is installed:

    oc project _amq-online-infra_
  3. Edit the existing infrastructure configuration, or create a new infrastructure configuration using the following example:

    apiVersion: admin.enmasse.io/v1beta1
    kind: StandardInfraConfig
    metadata:
      name: myconfig
    spec:
      version: "0.26"
      admin:
        resources:
          memory: 256Mi
      broker:
        resources:
          memory: 2Gi
          storage: 100Gi
        addressFullPolicy: PAGE
      router:
        resources:
          memory: 256Mi
        linkCapacity: 1000
        minReplicas: 1
  4. Apply the configuration changes:

    oc apply -f standard-infra-config-example.yaml
  5. Monitor the pods while they are restarted:

    oc get pods -w

    The configuration changes are applied within several minutes.

5.9. Authentication services

Authentication services are used to configure the authentication and authorization endpoints available to messaging clients. The authentication services are configured by the AMQ Online service operator, and are specified when creating an address space.

Authentication services are configured as Custom Resources. An authentication service has a type, which can be standard, external, or none.

5.9.1. Standard authentication service

The standard authentication service type allows the tenant administrator to manage users and their related permissions through the MessagingUser Custom Resource. This is achieved by using a Red Hat Single Sign-On instance to store user credentials and access policies. For typical use cases only one standard authentication service needs to be defined.

5.9.1.1. Standard authentication service example

The following example shows an authentication service of type standard:

apiVersion: admin.enmasse.io/v1beta1
kind: AuthenticationService
metadata:
  name: standard
spec:
  type: standard 1
  standard:
    credentialsSecret: 2
      name: my-admin-credentials
    certificateSecret 3
      name: my-authservice-certificate
    resources: 4
      requests:
        memory: 2Gi
      limits:
        memory: 2Gi
    storage: 5
      type: persistent-claim
      size: 5Gi
    datasource: 6
      type: postgresql
      host: example.com
      port: 5432
      database: authdb
1
Valid values for type are none, standard, or external.
2
(Optional) The secret must contain the admin.username field for the user and the admin.password field for the password of the Red Hat Single Sign-On admin user. If not specified, a random password will be generated and stored in a secret.
3
(Optional on OpenShift) A custom certificate can be specified. On OpenShift, a certificate is automatically created if not specified.
4
(Optional) Resource limits for the Red Hat Single Sign-On instance can be specified.
5
(Optional) The storage type can be specified as ephemeral or persistent-claim. For persistent-claim, you should also configure the size of the claim. The default type is ephemeral.
6
(Optional) Specifies the data source to be used by Red Hat Single Sign-On. The default option is the embedded h2 data source. For production usage, the postgresql data source is recommended.

5.9.1.2. Deploying the standard authentication service

To implement the standard authentication service, you deploy it.

Procedure

  1. Log in as a service admin:

    oc login -u admin
  2. Change to the project where AMQ Online is installed:

    oc project amq-online-infra
  3. Create an AuthenticationService definition:

    apiVersion: admin.enmasse.io/v1beta1
    kind: AuthenticationService
    metadata:
      name: standard-authservice
    spec:
      type: standard
  4. Deploy the authentication service:

    oc create -f standard-authservice.yaml

5.9.2. External authentication service

With the external authentication service you can configure an external provider of authentication and authorization policies through an AMQP SASL handshake. This configuration can be used to implement a bridge for your existing identity management system.

Depending on your use case, you might define several external authentication services.

5.9.2.1. External authentication service example

The following example shows an authentication service of type external:

apiVersion: admin.enmasse.io/v1beta1
kind: AuthenticationService
metadata:
  name: my-external-1
spec:
  type: external
  realm: myrealm 1
  external:
    host: example.com 2
    port: 5671 3
    caCertSecret: 4
      name: my-ca-cert
1
(Optional) The realm is passed in the authentication request. If not specified, an identifier in the form of namespace-addressspace is used as the realm.
2
The host name of the external authentication server.
3
The port number of the external authentication server.
4
(Optional) The CA certificate to trust when connecting to the authentication server.

The external authentication server must implement the API described in the External authentication server API.

5.9.2.2. External authentication service example allowing overrides

The following example shows an authentication service of type external that allows overrides to the host name, port number, and realm by the messaging tenant:

apiVersion: admin.enmasse.io/v1beta1
kind: AuthenticationService
metadata:
  name: my-external-2
spec:
  type: external
  realm: myrealm 1
  external:
    host: example.org 2
    port: 5671 3
    caCertSecret: 4
      name: my-ca-cert
    allowOverride: true 5
1
(Optional) The realm is passed in the authentication request. If not specified, an identifier in the form of namespace-addressspace is used as the realm.
2
The host name of the external authentication server.
3
The port number of the external authentication server.
4
(Optional) The CA certificate to trust when connecting to the authentication server.
5
(Optional) Specifies whether address space overrides are allowed to the host name, port number, realm, and CA certificate. Valid values are true or false. If not specified, the default value is false.

The external authentication server must implement the API described in the External authentication server API.

5.9.2.3. External authentication server API

An external authentication server must implement an AMQP SASL handshake, read the connection properties of the client, and respond with the expected connection properties containing the authentication and authorization information. The authentication server is queried by the address space components, such as the router and broker, whenever a new connection is established to the messaging endpoints.

5.9.2.3.1. Authentication

The requested identity of the client can be read from the SASL handshake username. The implementation can then authenticate the user.

The authenticated identity is returned in the authenticated-identity map with the following key/values. While this example uses JSON, it must be set as an AMQP map on the connection property.

{
    "authenticated-identity": {
        "sub": "myid",
        "preferred_username": "myuser"
    }
}
5.9.2.3.2. Authorization

Authorization is a capability that can be requested by the client using the ADDRESS-AUTHZ connection capability. If this is set on the connection, the server responds with this capability in the offered capabilities, and add the authorization information to the connection properties.

The authorization information is stored within a map that correlates the address to a list of operations allowed on that address. The following connection property information contains the policies for the addresses myqueue and mytopic:

{
    "address-authz": {
        "myqueue": [
          "send",
          "recv"
        ],
        "mytopic": [
          "send"
        ]
    }
}

The allowed operations are:

  • send - User can send to the address.
  • recv - User can receive from the address.

5.9.3. None authentication service

The none authentication service type allows any client using any user name and password to send and receive messages to any address.

Note

It is not recommended to use the none authentication service in production environments. It is intended only to be used in non-production environments, such as internal test or development environments.

5.9.3.1. Deploying the none authentication service

To implement the none authentication service, you deploy it.

Procedure

  1. Log in as a service admin:

    oc login -u admin
  2. Change to the project where AMQ Online is installed:

    oc project amq-online-infra
  3. Create an AuthenticationService definition:

    apiVersion: admin.enmasse.io/v1beta1
    kind: AuthenticationService
    metadata:
      name: none-authservice
    spec:
      type: none
  4. Deploy the authentication service:

    oc create -f none-authservice.yaml

5.10. AMQ Online example roles

AMQ Online provides the following example roles that you can use directly or use as models to create your own roles.

For more information about service administrator resources, see the AMQ Online service administrator resources table.

For more information about messaging tenant resources, see the AMQ Online messaging tenant resources table.

Table 5.1. AMQ Online example roles table

RoleDescription

enmasse.io:tenant-view

Specifies get and list permissions for addresses, addressspaces, addressspaceschemas, and messagingusers

enmasse.io:tenant-edit

Specifies create, get, update, delete, list, watch, and patch permissions for addresses, addressspaces, and messagingusers; get and list permissions for addressspaceschemas

service-admin cluster role

Specifies create, get, update, delete, list, watch, and patch permissions for addressplans, addressspaceplans, brokeredinfraconfigs, and standardinfraconfigs

Chapter 6. Monitoring AMQ Online

You can monitor AMQ Online by deploying built-in monitoring tools or using your pre-existing monitoring infrastructure by deploying the required service monitors and Prometheus rules.

6.1. (Optional) Deploying the Application Monitoring Operator

To monitor AMQ Online, an operator that acts on the monitoring Custom Resource Definitions must be deployed. You may skip this step if you have such an operator installed on your OpenShift cluster.

Procedure

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

    oc login -u system:admin
  2. (Optional) If you want to deploy to a namespace other than amq-online-monitoring you must run the following command and substitute amq-online-monitoring in subsequent steps:

    sed -i 's/amq-online-monitoring/my-namespace/' install/bundles/amq-online/*.yaml
  3. Create the amq-online-monitoring namespace:

    oc new-project amq-online-monitoring
  4. Deploy the monitoring-operator resources:

    oc apply -f install/components/monitoring-operator
  5. Deploy the monitoring-operator component:

    oc apply -f install/components/monitoring-deployment

6.2. (Optional) Deploying the kube-state-metrics agent

You can monitor AMQ Online pods using the kube-state-metrics agent.

Procedure

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

    oc login -u system:admin
  2. Select the amq-online-infra project:

    oc project amq-online-infra
  3. Deploy the kube-state-metrics component:

    oc apply -f install/components/kube-state-metrics

6.3. Deploying monitoring using a YAML bundle

The simplest way to deploy monitoring is to use a predefined YAML bundle.

Prerequisites

Procedure

  1. Label the amq-online-infra namespace:

    oc label namespace amq-online-infra monitoring-key=middleware
  2. Select the amq-online-infra project:

    oc project amq-online-infra
  3. Deploy the monitoring bundle:

    oc apply -f install/bundles/monitoring

6.4. Deploying monitoring using Ansible

Monitoring can also be deployed during the AMQ Online installation using Ansible using the required configuration settings.

6.5. Configuring alert notifications

To configure alert notifications, such as emails, you must change the default configuration of Alertmanager.

Prerequisites

  • Create an Alertmanager configuration file following the Alertmanager documentation. An example configuration file for email notifications is shown:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      labels:
        app: enmasse
      name: alertmanager-config
    data:
      alertmanager.yml: |
        global:
          resolve_timeout: 5m
          smtp_smarthost: localhost
          smtp_from: alerts@localhost
          smtp_auth_username: admin
          smtp_auth_password: password
        route:
          group_by: ['alertname']
          group_wait: 60s
          group_interval: 60s
          repeat_interval: 1h
          receiver: 'sysadmins'
        receivers:
        - name: 'sysadmins'
          email_configs:
          - to: sysadmin@localhost
        inhibit_rules:
          - source_match:
              severity: 'critical'
            target_match:
              severity: 'warning'
            equal: ['alertname']
  • Your Alertmanager configuration file must be named alertmanager.yaml so it can be read by the Prometheus Operator.

Procedure

  1. Delete the secret containing the default configuration:

    oc delete secret alertmanager-application-monitoring
  2. Create a secret containing your new configuration:

    oc create secret generic alertmanager-application-monitoring --from-file=alertmanager.yaml

6.6. Using qdstat

You can use qdstat to monitor the AMQ Online service.

6.6.1. Viewing router connections using qdstat

You can view the router connections using qdstat.

Procedure

  1. On the command line, run the following command to obtain the podname value needed in the following step:

    oc get pods
  2. On the command line, run the following command:

    oc exec -n namespace -it qdrouterd-podname -- qdstat -b 127.0.0.1:7777 -c
    
    Connections
      id   host                 container                             role    dir  security                              authentication                tenant
      =========================================================================================================================================================
      3    172.17.0.9:34998     admin-78794c68c8-9jdd6                normal  in   TLSv1.2(ECDHE-RSA-AES128-GCM-SHA256)  CN=admin,O=io.enmasse(x.509)
      12   172.30.188.174:5671  27803a14-42d2-6148-9491-a6c1e69e875a  normal  out  TLSv1.2(ECDHE-RSA-AES128-GCM-SHA256)  x.509
      567  127.0.0.1:43546      b240c652-82df-48dd-b54e-3b8bbaef16c6  normal  in   no-security                           PLAIN

6.6.2. Viewing router addresses using qdstat

You can view the router addresses using qdstat.

Procedure

  1. On the command line, run the following command to obtain the podname value needed in the following step:

    oc get pods
  2. Run the following command:

    oc exec -n namespace -it qdrouterd-podname -- qdstat -b 127.0.0.1:7777 -a
    
    Router Addresses
      class     addr                   phs  distrib       in-proc  local  remote  cntnr  in     out    thru  to-proc  from-proc
      ===========================================================================================================================
      local     $_management_internal       closest       1        0      0       0      0      0      0     588      588
      link-in   $lwt                        linkBalanced  0        0      0       0      0      0      0     0        0
      link-out  $lwt                        linkBalanced  0        0      0       0      0      0      0     0        0
      mobile    $management            0    closest       1        0      0       0      601    0      0     601      0
      local     $management                 closest       1        0      0       0      2,925  0      0     2,925    0
      local     qdhello                     flood         1        0      0       0      0      0      0     0        5,856
      local     qdrouter                    flood         1        0      0       0      0      0      0     0        0
      topo      qdrouter                    flood         1        0      0       0      0      0      0     0        196
      local     qdrouter.ma                 multicast     1        0      0       0      0      0      0     0        0
      topo      qdrouter.ma                 multicast     1        0      0       0      0      0      0     0        0
      local     temp.VTXOKyyWsq7OEei        balanced      0        1      0       0      0      0      0     0        0
      local     temp.k2RGQNPe6sDMvz4        balanced      0        1      0       0      0      3,511  0     0        3,511
      local     temp.xg+y8I_Tr4Y94LA        balanced      0        1      0       0      0      5      0     0        5

Chapter 7. Operation procedures for AMQ Online

7.1. Restarting components to acquire security fixes

Restarting AMQ Online components is required to get image updates for CVEs. The scripts are provided in the AMQ Online installation files within the script folder. To restart all components, run all scripts.

7.1.1. Restarting Operators

Operators can be restarted without affecting the messaging system. If a single api-server is used, a transient downtime will occur for any new address space, address, and messaging user resource requests.

Procedure

  • Run the restart-operators.sh script:

    ./scripts/restart-operators.sh amq-online-infra

7.1.2. Restarting authentication services

Authentication service restarts will temporarily affect new messaging connections. Existing connections will continue to work even if the authentication service is restarted.

Procedure

  • Run the restart-authservices.sh script:

    ./scripts/restart-authservices.sh amq-online-infra

7.1.3. Restarting routers

Messaging routers are only deployed in the standard address space type. The script assumes that at least two replicas of the router are running and performs a rolling restart. Messaging clients connected to the restarting router are disconnected and must reconnect to be served by a different router.

Procedure

  • Run the restart-routers.sh script, which requires at least one router to be available:

    ./scripts/restart-routers.sh amq-online-infra 1

7.1.4. Restarting brokers

For the brokered address space type, restarting the broker causes downtime temporarily to messaging clients while the broker is restarted. For the standard address space type, messaging clients are not disconnected from the messaging routers, but clients are not able to consume messages stored on the restarting broker.

Procedure

  • Run the restart-brokers.sh script:

    ./scripts/restart-brokers.sh amq-online-infra

7.2. Viewing router logs

For the standard address space type, you can view the router logs to troubleshoot issues with clients not connecting or issues with sending and receiving messages.

Procedure

  1. List all router Pods and choose the Pod for the relevant address space:

    oc get pods -l name=qdrouterd -o go-template --template '{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.annotations.addressSpace}}{{"\n"}}{{end}}'
  2. Display the logs for the Pod:

    oc logs pod -c router

7.3. Viewing broker logs

For the brokered or standard address space type, you can view the broker logs to troubleshoot issues with clients not connecting or issues with sending and receiving messages.

Procedure

  1. List all broker Pods and choose the Pod for the relevant address space:

    oc get pods -l role=broker -o go-template --template '{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.annotations.addressSpace}}{{"\n"}}{{end}}'
  2. Display the logs for the Pod:

    oc logs pod

Chapter 8. AMQ Online configuration sizing guidelines

The following information provides guidelines on how to size AMQ Online installations. More specifically, these guidelines offer specific configuration recommendations for components and plans based on use cases, and the trade-offs involved when adjusting the configuration settings. Sizing AMQ Online involves configuration of:

  • Brokers
  • Routers (standard address space only)
  • Operator(s)
  • Plans

For example, each address space type has certain distinct features that need to be considered when creating the address plans.

For more information about address space types and their semantics, see address spaces.

Note

Properly sizing AMQ Online components also requires taking into consideration the following points regarding your OpenShift cluster:

  • The OpenShift cluster must have sufficient capacity to handle the requested resources. If the OpenShift nodes are configured with 4 GB of memory, you cannot configure brokers and routers with memory sizes larger than 4 GB.
  • Since each address space creates a dedicated piece of infrastructure, you need to ensure that cluster capacity can meet demand as the number of address spaces increases.
  • The use of affinity and tolerations might also restrict the nodes available for the messaging infrastructure to use.

8.1. Broker component sizing

Brokers are configured using the BrokeredInfraConfig and StandardInfraConfig resources, depending on the type of address space. When sizing a broker, consider:

  • The average message size
  • The number of messages stored
  • The number of queues and topics
  • The address full policy
Note

In AMQ Online, you can only restrict the total amount of memory allocated for a broker. You cannot restrict the amount of memory used by individual addresses.

The broker persists all messages to disk. When the BLOCK, FAIL, or DROP address full policy is specified, the number of messages that can be persisted is limited to the amount of memory in the broker. By using the PAGE address full policy, more messages can be stored than can be held in memory, at the expense of a potential performance degradation from reading data from disk. Therefore, paging is useful in the case of large messages or a large backlog of messages in your system.

8.1.1. Example use case for a broker component configuration

Given 10 queues with a maximum of 1000 messages stored per queue and an average message size of 128 kB, the amount of storage space required to store messages is:

10 queues * 1000 messages * (128 + (128 kB * 1024)) = 1.25 GB

In addition, the broker has a fixed storage footprint of about 50 MB.

The amount of memory required for the broker depends on which address full policy is specified. If the PAGE policy is used, the memory requirements can be reduced since the messages are stored separately from the journal (which always needs to fit in memory). If the FAIL, BLOCK, or DROP policies are specified, all messages must also be held in memory, even if they are persisted.

There is also constant memory cost associated with running the broker as well as the JVM. The memory available to store message is automatically derived from the memory set in the broker configuration and is set to be half the JVM memory, which in turn is set to half of the system memory.

Note

In the standard address space type, multiple broker instances might be created. The sizing of these broker instances also depends on the address plan configuration and how many addresses you expect each broker to be able to handle before another broker is spawned.

8.1.1.1. Example broker component configuration without paging

For broker configurations not using a PAGE policy, take into consideration an additional 5 percent bookkeeping overhead per address should be taken into account (1.05 * 1.25 = 1.35 GB):

apiVersion: admin.enmasse.io/v1beta1
kind: BrokeredInfraConfig
metadata:
  name: cfg1
spec:
  broker:
    addressFullPolicy: FAIL
    globalMaxSize: 1.35Gb
    resources:
      memory: 4Gi
      storage: 2Gi
  ...

8.1.1.2. Example broker component configuration with paging

When paging is enabled, the original formula can be modified to only account for a reference to the message as well as holding 1000 in-flight messages in memory:

(1000 messages * 1000 * 128 kB) + (10 queues * 128 kB * 1024) = 123.5 MB

So, the amount of memory specified for the broker can now be reduced, as seen in this configuration example:

apiVersion: admin.enmasse.io/v1beta1
kind: BrokeredInfraConfig
metadata:
  name: cfg1
spec:
  broker:
    addressFullPolicy: PAGE
    globalMaxSize: 124Mb
    resources:
      memory: 512Mi
      storage: 2Gi
  ...

8.1.2. Broker scaling (standard address space only)

Brokers are deployed on demand, that is, when addresses of type queue or topic are created. The number of brokers deployed is restricted by the resource limits specified in the AddressSpacePlan configuration. The following AddressSpacePlan configuration example specifies a limit of four brokers in total per address space:

apiVersion: admin.enmasse.io/v1beta2
kind: AddressSpacePlan
metadata:
  name: cfg1
spec:
  resourceLimits:
    broker: 4.0
  ...

In terms of capacity, multiply the memory requirements for the broker by the limit.

The number of broker instances are scaled dynamically between one and the maximum limit specified based on the AddressPlan used for the different addresses. An AddressPlan specifies the fraction of a broker that is required by an address. The fraction specified in the plan is multiplied by the number of addresses referencing this plan, and then rounded up to produce the number of desired broker replicas.

AddressPlan configuration example

apiVersion: admin.enmasse.io/v1beta2
kind: AddressPlan
metadata:
  name: plan1
spec:
  ...
  resources:
    broker: 0.01

If you create 110 addresses with plan1 as the address plan, the number of broker replicas is ceil(110 addresses * 0.01 broker) = 2 replicas.

The total number of brokers is capped by the address space plan resource limits.

8.2. Router component sizing

Routers are configured in the StandardInfraConfig resource. In determining router sizing, consider:

  • The number of addresses
  • The number of connections and links
  • Link capacity

The router does not persist any state and therefore does not require persistent storage.

Address configuration itself does not require a significant amount of router memory. However, queues and subscriptions require an additional two links between the router and broker per address.

The total number of links is then two times the number of queues/subscriptions plus the number of client links. Each link requires metadata and buffers in the router to handle routing messages for that link.

The router link capacity affects how many messages the router can handle per link. Setting the link capacity to a higher value might improve performance, but at the cost of potentially more memory being used to hold in-flight messages if senders are filling the links. If you have many connections and links, consider specifying a lower value to balance the memory usage.

In addition, the router has to parse the message headers, manage dispositions and settlements of messages, and other per-link activities. The per-link cost can be derived using a constant factor of the link capacity and message size. This factor varies depending on the message size. The following table provides an approximation of this factor for different message size ranges:

Table 8.1. Link multiplication factor

Message size (bytes)Factor

20-1000

18,000

1000-4000

22,000

4000-10,000

30,000

>10,000

50,000

8.2.1. Example use case for router component sizing

Consider the following example use case:

  • 500 anycast and 1000 queued addresses
  • 10,000 connected clients (one link per client)
  • Link capacity of 10
  • An average message size of 512 bytes

Based on measurements, an estimated 7 kB overhead per anycast address is realistic, so:

500 anycast addresses * 7 kB overhead per address = 3.5 MB

Memory usage of queues and topics is slightly higher than that of anycast addresses, with an estimated 32 kB overhead per address. In addition, each router-broker link can have up to linkCapacity message deliveries to keep track of. Also, we need to multiply the link capacity with the multiplication factor to account for the worst-case scenario:

(1000 queued addresses * 32,768) + (2000 * 18,000 link multiplication factor * 100 links) = 374 MB

Memory usage of client connections/links:

10,000 clients * 10 link capacity * 18,000 link multiplication factor = 1717 MB
Note

The memory usage of client connections/links can be divided by the number of router instances.

If you have N routers, the total amount of router memory required for this configuration, including a constant base memory of 50 MB, is 50 + 3.5 + (374 + 1717)/N MB.

To ensure the maximum number of connections and links is not exceeded, a router policy can be applied as well. The following configuration example shows two routers with a router policy specified:

apiVersion: admin.enmasse.io/v1beta1
kind: StandardInfraConfig
metadata:
  name: cfg1
spec:
  router:
    resources:
      memory: 1100Mi
    linkCapacity: 10
    policy:
      maxConnections: 5000
      maxSessionsPerConnection: 1
      maxSendersPerConnection: 1
      maxReceiversPerConnection: 1
  ...

8.2.2. High availability (HA)

To configure routers for high availability (HA), multiply the minimum number of required router replicas by the amount of memory per router to calculate the amount of expected memory usage. Although all connections and links are distributed across all routers, if one router fails, you must plan for those connections and links to be redistributed across the remaining routers.

8.2.3. Router scaling

Routers are scaled dynamically on demand within the limits specified for minReplicas in the StandardInfraConfig resource and the resourceLimits.router specified in the AddressSpacePlan. To restrict the number of routers to a maximum number of four, but require a minimum amount of two routers for HA purposes, the following configuration is needed:

apiVersion: admin.enmasse.io/v1beta1
kind: StandardInfraConfig
metadata:
  name: cfg1
spec:
  router:
    minReplicas: 2
  ...
---
apiVersion: admin.enmasse.io/v1beta2
kind: AddressSpacePlan
metadata:
  name: plan1
spec:
  infraConfigRef: cfg1
  resourceLimits:
    router: 4
  ...

In terms of capacity, multiply the memory requirements for the router by the resource limit. The router will then scale up to the resource limits specified in the AddressSpacePlan for the address space.

The number of router replicas is scaled dynamically between the minimum and maximum limits based on the AddressPlan used for the different addresses. An AddressPlan describes the fraction of a router that is required by an address. The fraction defined in the plan is multiplied by the number of addresses referencing this plan, and then rounded up to produce the number of desired router replicas.

AddressPlan configuration example:

apiVersion: admin.enmasse.io/v1beta2
kind: AddressPlan
metadata:
  name: plan1
spec:
  ...
  resources:
    router: 0.01

If you create 110 addresses with plan1 as the address plan, the number of router replicas is ceil(110 addresses * 0.01 router) = 2 replicas.

If the number of replicas exceeds the address space plan limit, the addresses exceeding the maximum number remain in the Pending state and an error message describing the issue is displayed in the Address status section.

8.3. Operator component sizing

The operator component is tasked with reading all address configuration and applying these configurations to the routers and brokers. It is important to size the operator component proportionally to the number of addresses.

In the standard address space, the admin Pod contains two processes, agent and standard-controller. These processes cannot be sized individually, but the memory usage of both is proportional to the number of addresses. In the brokered address space, only a single agent process exists.

Note

The operator processes are running on either a JVM or a Node.JS VM. Sizing the amount of memory for these processes at twice the amount of memory required for the address configuration itself is recommended.

8.3.1. Operator component configuration example

Each address adds about 20 kB overhead to the operator process. With 1500 addresses, an additional 1500 * 2 kB = 30 MB is needed for the operator process.

In addition, these processes have a base memory requirement of 256 MB. So, the total operator memory needed is 256 MB + 30 MB = 286 MB. This value can be configured in both the StandardInfraConfig and BrokeredInfraConfig resources:

apiVersion: admin.enmasse.io/v1beta1
kind: StandardInfraConfig
metadata:
  name: cfg1
spec:
  admin:
    resources:
      memory: 300Mi
  ...

8.4. Plan sizing

Plans enable dynamic scaling in the standard address space, as shown in the broker and router sizing sections. At the cluster level, the combination of plans and infrastructure configuration settings determines the maximum number of Pods that can be deployed on the cluster. Since AMQ Online does not support limiting the number of address spaces that can be created, it is a best practice to apply a policy to limit who is allowed to create address spaces. Such policy configuration can be handled through the standard OpenShift policies.

From a capacity-planning perspective, it is useful to calculate the maximum number of Pods and the maximum amount of memory that can be consumed for a given address space. To make this calculation using a script, see Running the check-memory calculation script.

8.4.1. Running the check-memory calculation script

You can use this script to calculate the maximum number of Pods and the maximum amount of memory that can be consumed for a given address space.

In this script, memory is assumed to be specified using the Mi unit, while storage is assumed to be specified using the Gi unit. Also, all three components, admin, router, and broker, must have limits specified for the script to work as intended.

Procedure

  1. Save the following script as check-memory.sh:

    #!/usr/bin/env bash
    PLAN=$1
    
    total_pods=0
    total_memory_mb=0
    total_storage_gb=0
    
    routers=$(oc get addressspaceplan $PLAN -o jsonpath='{.spec.resourceLimits.router}')
    brokers=$(oc get addressspaceplan $PLAN -o jsonpath='{.spec.resourceLimits.broker}')
    infra=$(oc get addressspaceplan $PLAN -o jsonpath='{.spec.infraConfigRef}')
    
    operator_memory=$(oc get standardinfraconfig $infra -o jsonpath='{.spec.admin.resources.memory}')
    broker_memory=$(oc get standardinfraconfig $infra -o jsonpath='{.spec.broker.resources.memory}')
    broker_storage=$(oc get standardinfraconfig $infra -o jsonpath='{.spec.broker.resources.storage}')
    router_memory=$(oc get standardinfraconfig $infra -o jsonpath='{.spec.router.resources.memory}')
    
    total_pods=$((routers + brokers + 1))
    total_memory_mb=$(( (routers * ${router_memory%Mi}) + (brokers * ${broker_memory%Mi}) + ${operator_memory%Mi}))
    total_storage_gb=$(( brokers * ${broker_storage%Gi}))
    
    echo "Pods: ${total_pods}. Memory: ${total_memory_mb} MB. Storage: ${total_storage_gb} GB"
  2. Run the script using the following command:

    bash calculate-memory.sh standard-small

    If all components have limits defined in the assumed units, the script outputs the total resource limits for address spaces using this plan, as in the following example:

    Pods: 3. Memory: 1280 MB. Storage: 2 GB

Appendix A. AMQ Online resources for service administrators

The following table describes the AMQ Online resources that pertain to the service administrator role.

Table A.1. AMQ Online service administrator resources table

ResourceDescription

addressplans

Specifies the address plan.

addressspaceplans

Specifies the address space plan.

addressspaceschemas

Defines the service characteristics available to an addresspace. An addressspace refers to one addressspaceschema. standard and brokered are predefined addressspaceschemas.

brokeredinfraconfigs

Specifies the infrastructure configuration for brokered address spaces. For more information see Brokered infrastructure configuration fields table.

standardinfraconfigs

Specifies the infrastructure configuration for standard address spaces. For more information see Standard infrastructure configuration fields table.

Appendix B. Brokered infrastructure configuration fields

This table shows the fields available for the brokered infrastructure configuration and a brief description.

Table B.1. Brokered infrastructure configuration fields table

Field

Description

version

Specifies the AMQ Online version used. When upgrading, AMQ Online uses this field to determine whether to upgrade the infrastructure to the requested version.

admin.resources.memory

Specifies the amount of memory allocated to the admin Pod.

admin.podTemplate.metadata.labels

Specifies the labels added to the admin Pod.

admin.podTemplate.spec.affinity

Specifies the affinity settings for the admin Pod so you can specify where on particular nodes a Pod runs, or if it cannot run together with other instances.

admin.podTemplate.spec.priorityClassName

Specifies the priority class to use for the admin Pod so you can prioritize admin Pods over other Pods in the OpenShift cluster.

admin.podTemplate.spec.tolerations

Specifies the toleration settings for the admin Pod, which allows this Pod to run on certain nodes that other Pods cannot run on.

broker.addressFullPolicy

Specifies the action taken when a queue is full: BLOCK, FAIL, PAGE, DROP. The default value is PAGE. For more information see the AMQ Broker documentation.

broker.globalMaxSize

Specifies the maximum amount of memory used for queues in the broker.

broker.resources.memory

Specifies the amount of memory allocated to the broker.

broker.resources.storage

Specifies the amount of storage requested for the broker.

broker.podTemplate.metadata.labels

Specifies the labels added to the broker Pod.

broker.podTemplate.spec.affinity

Specifies the affinity settings for the broker Pod so you can specify where on particular nodes a Pod runs, or if it cannot run together with other instances.

broker.podTemplate.spec.priorityClassName

Specifies the priority class to use for the broker Pod so you can prioritize broker Pods over other Pods in the OpenShift cluster.

broker.podTemplate.spec.tolerations

Specifies the toleration settings for the broker Pod, which allows this Pod to run on certain nodes that other Pods cannot run on.

broker.podTemplate.spec.containers.env

Specifies environment variables for the broker Pod.

broker.podTemplate.spec.containers.livenessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a broker Pod starts and the probe fails before restarting the container.

broker.podTemplate.spec.containers.livenessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the broker Pod.

broker.podTemplate.spec.containers.livenessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the broker Pod.

broker.podTemplate.spec.containers.readinessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a broker Pod starts and the probe fails before the Pod is marked Unready.

broker.podTemplate.spec.containers.readinessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the broker Pod.

broker.podTemplate.spec.containers.readinessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the broker Pod.

broker.podTemplate.spec.containers.resources

Specifies broker Pod resource requests and limits for CPU and memory.

broker.storageClassName

Specifies what storage class to use for the persistent volume for the broker.

broker.updatePersistentVolumeClaim

If the persistent volume supports resizing, setting this value to true allows the broker storage to be resized.

Appendix C. Standard infrastructure configuration fields

This table shows the fields available for the standard infrastructure configuration and a brief description.

Table C.1. Standard infrastructure configuration fields table

Field

Description

version

Specifies the AMQ Online version used. When upgrading, AMQ Online uses this field to determine whether to upgrade the infrastructure to the requested version.

admin.resources.memory

Specifies the amount of memory allocated to the admin Pod.

admin.podTemplate.metadata.labels

Specifies the labels added to the admin Pod.

admin.podTemplate.spec.affinity

Specifies the affinity settings for the admin Pod so you can specify where on particular nodes a Pod runs, or if it cannot run together with other instances.

admin.podTemplate.spec.priorityClassName

Specifies the priority class to use for the admin Pod so you can prioritize admin pods over other Pods in the OpenShift cluster.

admin.podTemplate.spec.tolerations

Specifies the toleration settings for the admin Pod, which allow this Pod to run on certain nodes on which other Pods cannot run.

broker.addressFullPolicy

Specifies the action taken when a queue is full: BLOCK, FAIL, PAGE, DROP. The default value is PAGE. For more information see the AMQ Broker documentation.

broker.globalMaxSize

Specifies the maximum amount of memory used for queues in the broker.

broker.resources.memory

Specifies the amount of memory allocated to the broker.

broker.resources.storage

Specifies the amount of storage requested for the broker.

broker.podTemplate.metadata.labels

Specifies the labels added to the broker Pod.

broker.podTemplate.spec.affinity

Specifies the affinity settings for the broker Pod so you can specify where on particular nodes a Pod runs, or if it cannot run together with other instances.

broker.podTemplate.spec.priorityClassName

Specifies the priority class to use for the broker Pod so you can prioritize broker Pods over other Pods in the OpenShift cluster.

broker.podTemplate.spec.tolerations

Specifies the toleration settings for the broker Pod, which allow this Pod to run on certain nodes on which other Pods cannot run.

broker.podTemplate.spec.containers.env

Specifies environment variables for the broker Pod.

broker.podTemplate.spec.containers.livenessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a broker Pod starts and the probe fails before restarting the container.

broker.podTemplate.spec.containers.livenessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the broker Pod.

broker.podTemplate.spec.containers.livenessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the broker Pod.

broker.podTemplate.spec.containers.readinessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a broker Pod starts and the probe fails before the Pod is marked Unready.

broker.podTemplate.spec.containers.readinessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the broker Pod.

broker.podTemplate.spec.containers.readinessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the broker Pod.

broker.podTemplate.spec.containers.resources

Specifies broker Pod resource requests and limits for CPU and memory.

broker.connectorIdleTimeout

Specifies the AMQP idle timeout to use for connection to router.

broker.connectorWorkerThreads

Specifies the number of worker threads of the connection to the router.

broker.storageClassName

Specifies what storage class to use for the persistent volume for the broker.

broker.updatePersistentVolumeClaim

If the persistent volume supports resizing, setting this value to true allows the broker storage to be resized.

router.resources.memory

Specifies the amount of memory allocated to the router.

router.linkCapacity

Specifies the default number of credits issued on AMQP links for the router.

router.handshakeTimeout

Specifies the amount of time in seconds to wait for the secure handshake to be initiated.

router.minReplicas

Specifies the minimum number of router Pods to run; a minimum of two are required for high availability (HA) configuration.

router.podTemplate.metadata.labels

Specifies the labels added to the router Pod.

router.podTemplate.spec.affinity

Specifies the affinity settings for the router Pod so you can specify where on particular nodes a pod runs, or if it cannot run together with other instances.

router.podTemplate.spec.priorityClassName

Specifies the priority class to use for the router Pod so you can prioritize router pods over other pods in the OpenShift cluster.

router.podTemplate.spec.tolerations

Specifies the toleration settings for the router Pod, which allow this Pod to run on certain nodes on which other Pods cannot run.

router.podTemplate.spec.containers.env

Specifies the environment variables for the router Pod.

router.podTemplate.spec.containers.livenessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a router Pod starts and the probe fails before restarting the container.

router.podTemplate.spec.containers.livenessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the router Pod.

router.podTemplate.spec.containers.livenessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the router Pod.

router.podTemplate.spec.containers.readinessProbe.failureThreshold

Specifies the number of times that OpenShift tries when a router Pod starts and the probe fails before the Pod is marked Unready.

router.podTemplate.spec.containers.readinessProbe.initialDelaySeconds

Specifies the probe delay value in seconds for the router Pod.

router.podTemplate.spec.containers.readinessProbe.timeoutSeconds

Specifies the probe timeout value in seconds for the router Pod.

router.podTemplate.spec.containers.resources

Specifies router Pod resource requests and limits for CPU and memory.

router.idleTimeout

Specifies the AMQP idle timeout to use for all router listeners.

router.workerThreads

Specifies the number of worker threads to use for the router.

router.policy.maxConnections

Specifies the maximum number of router connections allowed.

router.policy.maxConnectionsPerUser

Specifies the maximum number of router connections allowed per user.

router.policy.maxConnectionsPerHost

Specifies the maximum number of router connections allowed per host.

router.policy.maxSessionsPerConnection

Specifies the maximum number of sessions allowed per router connection.

router.policy.maxSendersPerConnection

Specifies the maximum number of senders allowed per router connection.

router.policy.maxReceiversPerConnection

Specifies the maximum number of receivers allowed per router connection.

Appendix D. REST API Reference

D.1. EnMasse REST API

D.1.1. Overview

This is the EnMasse API specification.

D.1.1.1. Version information

Version : 0.30-SNAPSHOT

D.1.1.2. URI scheme

Schemes : HTTPS

D.1.1.3. Tags

  • addresses : Operating on Addresses.
  • addressplans : Operating on AddressPlans.
  • addressspaceplans : Operating on AddressSpacePlans.
  • addressspaces : Operate on AddressSpaces
  • brokeredinfraconfigs : Operating on BrokeredInfraConfigs.
  • messagingusers : Operating on MessagingUsers.
  • standardinfraconfigs : Operating on StandardInfraConfigs.

D.1.1.4. External Docs

Description : Find out more about EnMasse
URL : https://enmasse.io/documentation/

D.1.2. Paths

D.1.2.1. POST /apis/admin.enmasse.io/v1beta2/namespaces/{namespace}/addressspaceplans

D.1.2.1.1. Description

create an AddressSpacePlan

D.1.2.1.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.admin.v1beta2.AddressSpacePlan

D.1.2.1.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.admin.v1beta2.AddressSpacePlan

201

Created

io.enmasse.admin.v1beta2.AddressSpacePlan

401

Unauthorized

No Content

D.1.2.1.4. Consumes
  • application/json
D.1.2.1.5. Produces
  • application/json
D.1.2.1.6. Tags
  • addressspaceplan
  • admin
  • enmasse_v1beta2

D.1.2.2. GET /apis/admin.enmasse.io/v1beta2/namespaces/{namespace}/addressspaceplans

D.1.2.2.1. Description

list objects of kind AddressSpacePlan

D.1.2.2.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Query

labelSelector
optional

A selector to restrict the list of returned objects by their labels. Defaults to everything.

string

D.1.2.2.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.admin.v1beta2.AddressSpacePlanList

401

Unauthorized

No Content

D.1.2.2.4. Produces
  • application/json
D.1.2.2.5. Tags
  • addressspaceplan
  • admin
  • enmasse_v1beta2

D.1.2.3. GET /apis/admin.enmasse.io/v1beta2/namespaces/{namespace}/addressspaceplans/{name}

D.1.2.3.1. Description

read the specified AddressSpacePlan

D.1.2.3.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpacePlan to read.

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.3.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.admin.v1beta2.AddressSpacePlan

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.3.4. Consumes
  • application/json
D.1.2.3.5. Produces
  • application/json
D.1.2.3.6. Tags
  • addressspaceplan
  • admin
  • enmasse_v1beta2

D.1.2.4. PUT /apis/admin.enmasse.io/v1beta2/namespaces/{namespace}/addressspaceplans/{name}

D.1.2.4.1. Description

replace the specified AddressSpacePlan

D.1.2.4.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpacePlan to replace.

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.admin.v1beta2.AddressSpacePlan

D.1.2.4.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.admin.v1beta2.AddressSpacePlan

201

Created

io.enmasse.admin.v1beta2.AddressSpacePlan

401

Unauthorized

No Content

D.1.2.4.4. Produces
  • application/json
D.1.2.4.5. Tags
  • addressspaceplan
  • admin
  • enmasse_v1beta2

D.1.2.5. DELETE /apis/admin.enmasse.io/v1beta2/namespaces/{namespace}/addressspaceplans/{name}

D.1.2.5.1. Description

delete an AddressSpacePlan

D.1.2.5.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpacePlan to delete.

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.5.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.5.4. Produces
  • application/json
D.1.2.5.5. Tags
  • addressspaceplan
  • admin
  • enmasse_v1beta2

D.1.2.6. POST /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses

D.1.2.6.1. Description

create an Address

D.1.2.6.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.v1beta1.Address

D.1.2.6.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

201

Created

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

D.1.2.6.4. Consumes
  • application/json
D.1.2.6.5. Produces
  • application/json
D.1.2.6.6. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.7. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses

D.1.2.7.1. Description

list objects of kind Address

D.1.2.7.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Query

labelSelector
optional

A selector to restrict the list of returned objects by their labels. Defaults to everything.

string

D.1.2.7.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressList

401

Unauthorized

No Content

D.1.2.7.4. Produces
  • application/json
D.1.2.7.5. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.8. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses/{name}

D.1.2.8.1. Description

read the specified Address

D.1.2.8.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of Address to read

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.8.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.8.4. Consumes
  • application/json
D.1.2.8.5. Produces
  • application/json
D.1.2.8.6. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.9. PUT /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses/{name}

D.1.2.9.1. Description

replace the specified Address

D.1.2.9.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of Address to replace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.v1beta1.Address

D.1.2.9.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

201

Created

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

D.1.2.9.4. Produces
  • application/json
D.1.2.9.5. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.10. DELETE /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses/{name}

D.1.2.10.1. Description

delete an Address

D.1.2.10.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of Address to delete

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.10.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.10.4. Produces
  • application/json
D.1.2.10.5. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.11. PATCH /apis/enmasse.io/v1beta1/namespaces/{namespace}/addresses/{name}

D.1.2.11.1. Description

patches (RFC6902) the specified Address

D.1.2.11.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of Address to replace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

JsonPatchRequest

D.1.2.11.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

D.1.2.11.4. Consumes
  • application/json-patch+json
D.1.2.11.5. Produces
  • application/json
D.1.2.11.6. Tags
  • addresses
  • enmasse_v1beta1

D.1.2.12. POST /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces

D.1.2.12.1. Description

create an AddressSpace

D.1.2.12.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.v1beta1.AddressSpace

D.1.2.12.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressSpace

201

Created

io.enmasse.v1beta1.AddressSpace

401

Unauthorized

No Content

D.1.2.12.4. Consumes
  • application/json
D.1.2.12.5. Produces
  • application/json
D.1.2.12.6. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.13. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces

D.1.2.13.1. Description

list objects of kind AddressSpace

D.1.2.13.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Query

labelSelector
optional

A selector to restrict the list of returned objects by their labels. Defaults to everything.

string

D.1.2.13.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressSpaceList

401

Unauthorized

No Content

D.1.2.13.4. Produces
  • application/json
D.1.2.13.5. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.14. POST /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{addressSpace}/addresses

D.1.2.14.1. Description

create Addresses in an AddressSpace

D.1.2.14.2. Parameters
TypeNameDescriptionSchema

Path

addressSpace
required

Name of AddressSpace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

AddressList object

io.enmasse.v1beta1.AddressList

D.1.2.14.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.14.4. Consumes
  • application/json
D.1.2.14.5. Produces
  • application/json
D.1.2.14.6. Tags
  • addressspace_addresses
  • enmasse_v1beta1

D.1.2.15. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{addressSpace}/addresses

D.1.2.15.1. Description

list objects of kind Address in AddressSpace

D.1.2.15.2. Parameters
TypeNameDescriptionSchema

Path

addressSpace
required

Name of AddressSpace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.15.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressList

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.15.4. Produces
  • application/json
D.1.2.15.5. Tags
  • addressspace_addresses
  • enmasse_v1beta1

D.1.2.16. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{addressSpace}/addresses/{address}

D.1.2.16.1. Description

read the specified Address in AddressSpace

D.1.2.16.2. Parameters
TypeNameDescriptionSchema

Path

address
required

Name of Address

string

Path

addressSpace
required

Name of AddressSpace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.16.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.16.4. Produces
  • application/json
D.1.2.16.5. Tags
  • addressspace_addresses
  • enmasse_v1beta1

D.1.2.17. PUT /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{addressSpace}/addresses/{address}

D.1.2.17.1. Description

replace Address in an AddressSpace

D.1.2.17.2. Parameters
TypeNameDescriptionSchema

Path

address
required

Name of address

string

Path

addressSpace
required

Name of AddressSpace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

Address object

io.enmasse.v1beta1.Address

D.1.2.17.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.Address

201

Created

io.enmasse.v1beta1.Address

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.17.4. Consumes
  • application/json
D.1.2.17.5. Produces
  • application/json
D.1.2.17.6. Tags
  • addressspace_addresses
  • enmasse_v1beta1

D.1.2.18. DELETE /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{addressSpace}/addresses/{address}

D.1.2.18.1. Description

delete an Address in AddressSpace

D.1.2.18.2. Parameters
TypeNameDescriptionSchema

Path

address
required

Name of Address

string

Path

addressSpace
required

Name of AddressSpace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.18.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.18.4. Produces
  • application/json
D.1.2.18.5. Tags
  • addressspace_addresses
  • enmasse_v1beta1

D.1.2.19. GET /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{name}

D.1.2.19.1. Description

read the specified AddressSpace

D.1.2.19.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpace to read

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.19.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressSpace

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.19.4. Consumes
  • application/json
D.1.2.19.5. Produces
  • application/json
D.1.2.19.6. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.20. PUT /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{name}

D.1.2.20.1. Description

replace the specified AddressSpace

D.1.2.20.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpace to replace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.v1beta1.AddressSpace

D.1.2.20.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressSpace

201

Created

io.enmasse.v1beta1.AddressSpace

401

Unauthorized

No Content

D.1.2.20.4. Produces
  • application/json
D.1.2.20.5. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.21. DELETE /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{name}

D.1.2.21.1. Description

delete an AddressSpace

D.1.2.21.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpace to delete

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.21.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.21.4. Produces
  • application/json
D.1.2.21.5. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.22. PATCH /apis/enmasse.io/v1beta1/namespaces/{namespace}/addressspaces/{name}

D.1.2.22.1. Description

patches (RFC6902) the specified AddressSpace

D.1.2.22.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of AddressSpace to replace

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

JsonPatchRequest

D.1.2.22.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.v1beta1.AddressSpace

401

Unauthorized

No Content

D.1.2.22.4. Consumes
  • application/json-patch+json
D.1.2.22.5. Produces
  • application/json
D.1.2.22.6. Tags
  • addressspaces
  • enmasse_v1beta1

D.1.2.23. POST /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers

D.1.2.23.1. Description

create a MessagingUser

D.1.2.23.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.user.v1beta1.MessagingUser

D.1.2.23.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.user.v1beta1.MessagingUser

201

Created

io.enmasse.user.v1beta1.MessagingUser

401

Unauthorized

No Content

D.1.2.23.4. Consumes
  • application/json
D.1.2.23.5. Produces
  • application/json
D.1.2.23.6. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.2.24. GET /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers

D.1.2.24.1. Description

list objects of kind MessagingUser

D.1.2.24.2. Parameters
TypeNameDescriptionSchema

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Query

labelSelector
optional

A selector to restrict the list of returned objects by their labels. Defaults to everything.

string

D.1.2.24.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.user.v1beta1.MessagingUserList

401

Unauthorized

No Content

D.1.2.24.4. Produces
  • application/json
D.1.2.24.5. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.2.25. GET /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers/{name}

D.1.2.25.1. Description

read the specified MessagingUser

D.1.2.25.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of MessagingUser to read. Must include addressSpace and dot separator in the name (that is, 'myspace.user1').

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.25.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.user.v1beta1.MessagingUser

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.25.4. Consumes
  • application/json
D.1.2.25.5. Produces
  • application/json
D.1.2.25.6. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.2.26. PUT /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers/{name}

D.1.2.26.1. Description

replace the specified MessagingUser

D.1.2.26.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of MessagingUser to replace. Must include addressSpace and dot separator in the name (that is, 'myspace.user1').

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

io.enmasse.user.v1beta1.MessagingUser

D.1.2.26.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.user.v1beta1.MessagingUser

201

Created

io.enmasse.user.v1beta1.MessagingUser

401

Unauthorized

No Content

D.1.2.26.4. Produces
  • application/json
D.1.2.26.5. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.2.27. DELETE /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers/{name}

D.1.2.27.1. Description

delete a MessagingUser

D.1.2.27.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of MessagingUser to delete. Must include addressSpace and dot separator in the name (that is, 'myspace.user1').

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

D.1.2.27.3. Responses
HTTP CodeDescriptionSchema

200

OK

Status

401

Unauthorized

No Content

404

Not found

No Content

D.1.2.27.4. Produces
  • application/json
D.1.2.27.5. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.2.28. PATCH /apis/user.enmasse.io/v1beta1/namespaces/{namespace}/messagingusers/{name}

D.1.2.28.1. Description

patches (RFC6902) the specified MessagingUser

D.1.2.28.2. Parameters
TypeNameDescriptionSchema

Path

name
required

Name of MessagingUser to replace. Must include addressSpace and dot separator in the name (that is, 'myspace.user1'

string

Path

namespace
required

object name and auth scope, such as for teams and projects

string

Body

body
required

 

JsonPatchRequest

D.1.2.28.3. Responses
HTTP CodeDescriptionSchema

200

OK

io.enmasse.user.v1beta1.MessagingUser

401

Unauthorized

No Content

D.1.2.28.4. Consumes
  • application/json-patch+json
D.1.2.28.5. Produces
  • application/json
D.1.2.28.6. Tags
  • auth
  • enmasse_v1beta1
  • user

D.1.3. Definitions

D.1.3.1. JsonPatchRequest

NameSchema

document
required

object

patch
required

< Patch > array

D.1.3.2. ObjectMeta

ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create.

NameSchema

name
required

string

namespace
optional

string

D.1.3.3. Patch

NameDescriptionSchema

from
optional

Required for operations copy, replace

string

op
required

 

enum (add, remove, replace, move, copy, test)

path
required

Slash separated format

string

value
optional

Required for operations add, replace, test

string

D.1.3.4. Status

Status is a return value for calls that do not return other objects.

NameDescriptionSchema

code
optional

Suggested HTTP return code for this status, 0 if not set.

integer (int32)

D.1.3.5. io.enmasse.admin.v1beta1.BrokeredInfraConfig

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta1)

kind
required

enum (BrokeredInfraConfig)

metadata
required

ObjectMeta

spec
required

io.enmasse.admin.v1beta1.BrokeredInfraConfigSpec

D.1.3.6. io.enmasse.admin.v1beta1.BrokeredInfraConfigList

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta1)

items
required

< io.enmasse.admin.v1beta1.BrokeredInfraConfig > array

kind
required

enum (BrokeredInfraConfigList)

D.1.3.7. io.enmasse.admin.v1beta1.BrokeredInfraConfigSpec

NameSchema

admin
optional

io.enmasse.admin.v1beta1.BrokeredInfraConfigSpecAdmin

broker
optional

io.enmasse.admin.v1beta1.BrokeredInfraConfigSpecBroker

networkPolicy
optional

networkPolicy

version
optional

string

networkPolicy

D.1.3.8. io.enmasse.admin.v1beta1.BrokeredInfraConfigSpecAdmin

NameSchema

podTemplate
optional

io.enmasse.admin.v1beta1.InfraConfigPodSpec

resources
optional

resources

resources

NameSchema

memory
optional

string

D.1.3.9. io.enmasse.admin.v1beta1.BrokeredInfraConfigSpecBroker

NameSchema

addressFullPolicy
optional

enum (PAGE, BLOCK, FAIL)

podTemplate
optional

io.enmasse.admin.v1beta1.InfraConfigPodSpec

resources
optional

resources

storageClassName
optional

string

updatePersistentVolumeClaim
optional

boolean

resources

NameSchema

memory
optional

string

storage
optional

string

D.1.3.10. io.enmasse.admin.v1beta1.InfraConfigPodSpec

NameSchema

metadata
optional

metadata

spec
optional

spec

metadata

NameSchema

labels
optional

object

spec

NameSchema

affinity
optional

object

containers
optional

< containers > array

priorityClassName
optional

string

tolerations
optional

< object > array

containers

NameSchema

resources
optional

object

D.1.3.11. io.enmasse.admin.v1beta1.StandardInfraConfig

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta1)

kind
required

enum (StandardInfraConfig)

metadata
required

ObjectMeta

spec
required

io.enmasse.admin.v1beta1.StandardInfraConfigSpec

D.1.3.12. io.enmasse.admin.v1beta1.StandardInfraConfigList

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta1)

items
required

< io.enmasse.admin.v1beta1.StandardInfraConfig > array

kind
required

enum (StandardInfraConfigList)

D.1.3.13. io.enmasse.admin.v1beta1.StandardInfraConfigSpec

networkPolicy

D.1.3.14. io.enmasse.admin.v1beta1.StandardInfraConfigSpecAdmin

NameSchema

podTemplate
optional

io.enmasse.admin.v1beta1.InfraConfigPodSpec

resources
optional

resources

resources

NameSchema

memory
optional

string

D.1.3.15. io.enmasse.admin.v1beta1.StandardInfraConfigSpecBroker

NameSchema

addressFullPolicy
optional

enum (PAGE, BLOCK, FAIL)

connectorIdleTimeout
optional

integer

connectorWorkerThreads
optional

integer

podTemplate
optional

io.enmasse.admin.v1beta1.InfraConfigPodSpec

resources
optional

resources

storageClassName
optional

string

updatePersistentVolumeClaim
optional

boolean

resources

NameSchema

memory
optional

string

storage
optional

string

D.1.3.16. io.enmasse.admin.v1beta1.StandardInfraConfigSpecRouter

NameSchema

idleTimeout
optional

integer

initialHandshakeTimeout
optional

integer

linkCapacity
optional

integer

minReplicas
optional

integer

podTemplate
optional

io.enmasse.admin.v1beta1.InfraConfigPodSpec

policy
optional

policy

resources
optional

resources

workerThreads
optional

integer

policy

NameSchema

maxConnections
optional

integer

maxConnectionsPerHost
optional

integer

maxConnectionsPerUser
optional

integer

maxReceiversPerConnection
optional

integer

maxSendersPerConnection
optional

integer

maxSessionsPerConnection
optional

integer

resources

NameSchema

memory
optional

string

D.1.3.17. io.enmasse.admin.v1beta2.AddressPlan

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta2)

kind
required

enum (AddressPlan)

metadata
required

ObjectMeta

spec
required

io.enmasse.admin.v1beta2.AddressPlanSpec

D.1.3.18. io.enmasse.admin.v1beta2.AddressPlanList

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta2)

items
required

< io.enmasse.admin.v1beta2.AddressPlan > array

kind
required

enum (AddressPlanList)

D.1.3.19. io.enmasse.admin.v1beta2.AddressPlanSpec

NameSchema

addressType
required

string

displayName
required

string

displayOrder
optional

integer

longDescription
optional

string

partitions
optional

integer

resources
required

resources

shortDescription
optional

string

resources

NameSchema

broker
optional

number

router
optional

number

D.1.3.20. io.enmasse.admin.v1beta2.AddressSpacePlan

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta2)

kind
required

enum (AddressSpacePlan)

metadata
required

ObjectMeta

spec
required

io.enmasse.admin.v1beta2.AddressSpacePlanSpec

D.1.3.21. io.enmasse.admin.v1beta2.AddressSpacePlanList

NameSchema

apiVersion
required

enum (admin.enmasse.io/v1beta2)

items
required

< io.enmasse.admin.v1beta2.AddressSpacePlan > array

kind
required

enum (AddressSpacePlanList)

D.1.3.22. io.enmasse.admin.v1beta2.AddressSpacePlanSpec

NameSchema

addressPlans
required

< string > array

addressSpaceType
required

string

displayName
required

string

displayOrder
optional

integer

infraConfigRef
required

string

longDescription
optional

string

resourceLimits
required

resourceLimits

shortDescription
optional

string

resourceLimits

NameSchema

aggregate
optional

number

broker
optional

number

router
optional

number

D.1.3.23. io.enmasse.user.v1beta1.MessagingUser

NameSchema

apiVersion
required

enum (user.enmasse.io/v1beta1)

kind
required

enum (MessagingUser)

metadata
required

ObjectMeta

spec
required

io.enmasse.user.v1beta1.UserSpec

D.1.3.24. io.enmasse.user.v1beta1.MessagingUserList

NameSchema

apiVersion
required

enum (user.enmasse.io/v1beta1)

items
required

< io.enmasse.user.v1beta1.MessagingUser > array

kind
required

enum (MessagingUserList)

D.1.3.25. io.enmasse.user.v1beta1.UserSpec

NameSchema

authentication
optional

authentication

authorization
optional

< authorization > array

username
required

string

authentication

NameDescriptionSchema

federatedUserid
optional

User id of the user to federate when 'federated' type is specified.

string

federatedUsername
optional

User name of the user to federate when 'federated' type is specified.

string

password
optional

Base64 encoded value of password when 'password' type is specified.

string

provider
optional

Name of provider to use for federated identity when 'federated' type is specified.

string

type
required

 

enum (password, serviceaccount)

authorization

NameSchema

addresses
optional

< string > array

operations
required

< enum (send, receive, view, manage) > array

D.1.3.26. io.enmasse.v1beta1.Address

NameSchema

apiVersion
required

enum (enmasse.io/v1beta1)

kind
required

enum (Address)

metadata
required

ObjectMeta

spec
required

io.enmasse.v1beta1.AddressSpec

status
optional

io.enmasse.v1beta1.AddressStatus

D.1.3.27. io.enmasse.v1beta1.AddressList

NameDescriptionSchema

apiVersion
required

Default : "enmasse.io/v1beta1"

enum (enmasse.io/v1beta1)

items
required

 

< io.enmasse.v1beta1.Address > array

kind
required

 

enum (AddressList)

D.1.3.28. io.enmasse.v1beta1.AddressSpace

NameSchema

apiVersion
required

enum (enmasse.io/v1beta1)

kind
required

enum (AddressSpace)

metadata
required

ObjectMeta

spec
required

io.enmasse.v1beta1.AddressSpaceSpec

status
optional

io.enmasse.v1beta1.AddressSpaceStatus

D.1.3.29. io.enmasse.v1beta1.AddressSpaceList

NameDescriptionSchema

apiVersion
required

Default : "enmasse.io/v1beta1"

enum (enmasse.io/v1beta1)

items
required

 

< io.enmasse.v1beta1.AddressSpace > array

kind
required

 

enum (AddressSpaceList)

D.1.3.30. io.enmasse.v1beta1.AddressSpaceSpec

NameDescriptionSchema

authenticationService
optional

 

authenticationService

connectors
optional

List of connectors to create.

< io.enmasse.v1beta1.AddressSpaceSpecConnector > array

endpoints
optional

 

< endpoints > array

networkPolicy
optional

 

networkPolicy

plan
required

 

string

type
required

 

io.enmasse.v1beta1.AddressSpaceType

authenticationService

NameSchema

name
optional

string

overrides
optional

overrides

type
optional

string

overrides

NameSchema

host
optional

string

port
optional

integer

realm
optional

string

endpoints

NameSchema

cert
optional

cert

exports
optional

< exports > array

expose
optional

expose

name
optional

string

service
optional

string

cert

NameSchema

provider
optional

string

secretName
optional

string

tlsCert
optional

string

tlsKey
optional

string

exports

NameSchema

kind
optional

enum (ConfigMap, Secret, Service)

name
optional

string

expose

NameSchema

annotations
optional

object

loadBalancerPorts
optional

< string > array

loadBalancerSourceRanges
optional

< string > array

routeHost
optional

string

routeServicePort
optional

string

routeTlsTermination
optional

string

type
optional

enum (route, loadbalancer)

networkPolicy

D.1.3.31. io.enmasse.v1beta1.AddressSpaceSpecConnector

NameDescriptionSchema

addresses
optional

Addresses to make be accessible via this address space.

< addresses > array

credentials
optional

Credentials used when connecting to endpoints. Either 'username' and 'password', or 'secret' must be defined.

credentials

endpointHosts
required

List of hosts that should be connected to. Must contain at least 1 entry.

< endpointHosts > array

name
required

Name of the connector.

string

tls
optional

TLS settings for the connectors. If not specified, TLS will not be used.

tls

addresses

NameDescriptionSchema

name
required

Identifier of address pattern. Used to uniquely identify a pattern

string

pattern
required

Pattern used to match addresses. The pattern will be prefixed by the connector name and a forward slash ('myconnector/'). A 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.

string

credentials

NameDescriptionSchema

password
optional

Password to use for connector. Either 'value' or 'secret' must be specified.

password

username
optional

Username to use for connector. Either 'value' or 'secret' must be specified.

username

password

NameSchema

value
optional

string

valueFromSecret
optional

valueFromSecret

valueFromSecret

NameDescriptionSchema

key
optional

Key to use for looking up password entry.
Default : "password"

string

name
optional

Name of Secret containing password.

string

username

NameSchema

value
optional

string

valueFromSecret
optional

valueFromSecret

valueFromSecret

NameDescriptionSchema

key
optional

Key to use for looking up username entry.
Default : "username"

string

name
optional

Name of Secret containing username.

string

endpointHosts

NameDescriptionSchema

host
required

Host to connect to.

string

port
required

Port to connect to.

integer

tls

NameDescriptionSchema

caCert
optional

CA certificate to be used by the connector. Either 'value' or 'secret'.

caCert

clientCert
optional

Client certificate to be used by the connector. Either 'value' or 'secret'.

clientCert

caCert

NameDescriptionSchema

value
optional

PEM encoded value of CA certificate

string

valueFromSecret
optional

Secret containing CA certificate to be used by the connector.

valueFromSecret

valueFromSecret

NameDescriptionSchema

key
optional

Key to use for looking up CA certificate entry.
Default : "ca.crt"

string

name
optional

Name of Secret containing CA certificate.

string

clientCert

NameDescriptionSchema

value
optional

PEM encoded value of client certificate

string

valueFromSecret
optional

Secret containing client certificate to be used by the connector.

valueFromSecret

valueFromSecret

NameDescriptionSchema

key
optional

Key to use for looking up client certificate entry.
Default : "ca.crt"

string

name
optional

Name of Secret containing client certificate.

string

D.1.3.32. io.enmasse.v1beta1.AddressSpaceStatus

NameDescriptionSchema

connectors
optional

List of connectors with status.

< io.enmasse.v1beta1.AddressSpaceStatusConnector > array

endpointStatuses
optional

 

< endpointStatuses > array

isReady
optional

 

boolean

messages
optional

 

< string > array

endpointStatuses

NameSchema

cert
optional

string

externalHost
optional

string

externalPorts
optional

< externalPorts > array

name
optional

string

serviceHost
optional

string

servicePorts
optional

< servicePorts > array

externalPorts

NameSchema

name
optional

string

port
optional

integer

servicePorts

NameSchema

name
optional

string

port
optional

integer

D.1.3.33. io.enmasse.v1beta1.AddressSpaceStatusConnector

NameDescriptionSchema

isReady
optional

'true' if connector is operating as expected, 'false' if not.

boolean

messages
optional

Messages describing the connector state.

< string > array

name
optional

Name of connector.

string

D.1.3.34. io.enmasse.v1beta1.AddressSpaceType

AddressSpaceType is the type of address space (standard, brokered). Each type supports different types of addresses and semantics for those types.

Type : enum (standard, brokered)

D.1.3.35. io.enmasse.v1beta1.AddressSpec

NameDescriptionSchema

address
required

 

string

forwarders
optional

List of forwarders to enable for this address.

< io.enmasse.v1beta1.AddressSpecForwarder > array

plan
required

 

string

type
required

 

io.enmasse.v1beta1.AddressType

D.1.3.36. io.enmasse.v1beta1.AddressSpecForwarder

NameDescriptionSchema

direction
required

Direction of forwarder. 'in' means pulling from 'remoteAddress' into this address. 'out' means pushing from this address to 'remoteAddress'.

enum (in, out)

name
required

Name of forwarder.

string

remoteAddress
required

Remote address to send/receive messages to.

string

D.1.3.37. io.enmasse.v1beta1.AddressStatus

NameDescriptionSchema

forwarders
optional

List of forwarders with status.

< io.enmasse.v1beta1.AddressStatusForwarder > array

isReady
optional

 

boolean

messages
optional

 

< string > array

phase
optional

 

enum (Pending, Configuring, Active, Failed, Terminating)

D.1.3.38. io.enmasse.v1beta1.AddressStatusForwarder

NameDescriptionSchema

isReady
optional

'true' if forwarder is operating as expected, 'false' if not.

boolean

messages
optional

Messages describing the forwarder state.

< string > array

name
optional

Name of forwarder.

string

D.1.3.39. io.enmasse.v1beta1.AddressType

Type of address (queue, topic, …). Each address type support different kinds of messaging semantics.

Type : enum (queue, topic, anycast, multicast)

D.1.3.40. io.k8s.api.networking.v1.IPBlock

IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods matched by a NetworkPolicySpec’s podSelector. The except entry describes CIDRs that should not be included within this rule.

NameDescriptionSchema

cidr
required

CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"

string

except
optional

Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" Except values will be rejected if they are outside the CIDR range

< string > array

D.1.3.41. io.k8s.api.networking.v1.NetworkPolicyEgressRule

NetworkPolicyEgressRule describes a particular set of traffic that is allowed out of pods matched by a NetworkPolicySpec’s podSelector. The traffic must match both ports and to. This type is beta-level in 1.8

NameDescriptionSchema

ports
optional

List of destination ports for outgoing traffic. Each item in this list is combined using a logical OR. If this field is empty or missing, this rule matches all ports (traffic not restricted by port). If this field is present and contains at least one item, then this rule allows traffic only if the traffic matches at least one port in the list.

< io.k8s.api.networking.v1.NetworkPolicyPort > array

to
optional

List of destinations for outgoing traffic of pods selected for this rule. Items in this list are combined using a logical OR operation. If this field is empty or missing, this rule matches all destinations (traffic not restricted by destination). If this field is present and contains at least one item, this rule allows traffic only if the traffic matches at least one item in the to list.

< io.k8s.api.networking.v1.NetworkPolicyPeer > array

D.1.3.42. io.k8s.api.networking.v1.NetworkPolicyIngressRule

NetworkPolicyIngressRule describes a particular set of traffic that is allowed to the pods matched by a NetworkPolicySpec’s podSelector. The traffic must match both ports and from.

NameDescriptionSchema

from
optional

List of sources which should be able to access the pods selected for this rule. Items in this list are combined using a logical OR operation. If this field is empty or missing, this rule matches all sources (traffic not restricted by source). If this field is present and contains at least on item, this rule allows traffic only if the traffic matches at least one item in the from list.

< io.k8s.api.networking.v1.NetworkPolicyPeer > array

ports
optional

List of ports which should be made accessible on the pods selected for this rule. Each item in this list is combined using a logical OR. If this field is empty or missing, this rule matches all ports (traffic not restricted by port). If this field is present and contains at least one item, then this rule allows traffic only if the traffic matches at least one port in the list.

< io.k8s.api.networking.v1.NetworkPolicyPort > array

D.1.3.43. io.k8s.api.networking.v1.NetworkPolicyPeer

NetworkPolicyPeer describes a peer to allow traffic from. Only certain combinations of fields are allowed

NameDescriptionSchema

ipBlock
optional

IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be.

io.k8s.api.networking.v1.IPBlock

namespaceSelector
optional

Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces.

If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector.

io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector

podSelector
optional

This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods.

If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy’s own Namespace.

io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector

D.1.3.44. io.k8s.api.networking.v1.NetworkPolicyPort

NetworkPolicyPort describes a port to allow traffic on

NameDescriptionSchema

port
optional

The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers.

io.k8s.apimachinery.pkg.util.intstr.IntOrString

protocol
optional

The protocol (TCP or UDP) which traffic must match. If not specified, this field defaults to TCP.

string

D.1.3.45. io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector

A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.

NameDescriptionSchema

matchExpressions
optional

matchExpressions is a list of label selector requirements. The requirements are ANDed.

< io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelectorRequirement > array

matchLabels
optional

matchLabels is a map of {key,value} pairs. A single {key,value} in the matchLabels map is equivalent to an element of matchExpressions, whose key field is "key", the operator is "In", and the values array contains only "value". The requirements are ANDed.

< string, string > map

D.1.3.46. io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelectorRequirement

A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.

NameDescriptionSchema

key
required

key is the label key that the selector applies to.

string

operator
required

operator represents a key’s relationship to a set of values. Valid operators are In, NotIn, Exists and DoesNotExist.

string

values
optional

values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch.

< string > array

D.1.3.47. io.k8s.apimachinery.pkg.util.intstr.IntOrString

IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.

Type : string (int-or-string)

Appendix E. Using your subscription

AMQ Online is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal.

Accessing your account

  1. Go to access.redhat.com.
  2. If you do not already have an account, create one.
  3. Log in to your account.

Activating a subscription

  1. Go to access.redhat.com.
  2. Navigate to My Subscriptions.
  3. Navigate to Activate a subscription and enter your 16-digit activation number.

Downloading zip and tar files

To access zip or tar files, use the Red Hat Customer Portal to find the relevant files for download. If you are using RPM packages, this step is not required.

  1. Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads.
  2. Locate the Red Hat AMQ Online entries in the JBOSS INTEGRATION AND AUTOMATION category.
  3. Select the desired AMQ Online product. The Software Downloads page opens.
  4. Click the Download link for your component.

Registering your system for packages

To install RPM packages on Red Hat Enterprise Linux, your system must be registered. If you are using zip or tar files, this step is not required.

  1. Go to access.redhat.com.
  2. Navigate to Registration Assistant.
  3. Select your OS version and continue to the next page.
  4. Use the listed command in your system terminal to complete the registration.

To learn more see How to Register and Subscribe a System to the Red Hat Customer Portal.

Revised on 2019-11-06 18:44:27 UTC

Legal Notice

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.