OpenAperture

OpenAperture is a free, open-source hybrid cloud management platform that delivers software quickly and consistently regardless of location or workload. This future-ready platform from Lexmark Enterprise Software provides a comprehensive management system to handle the six pillars of cloud management – provisioning, deployment, monitoring, maintenance, security and metering.

Communication / Messaging

OpenAperture is designed to work in a centralized Cloud as well as on-premesis, as one fluid system. As such, a communication protocol was needed that could communicate with Etcd Clusters that lived publically privately. With the exception of the REST interface defined in Manager, all components communicate with each other via the AMQP protocol. The current implementation is built on top of federated RabbitMQ clusters, but that's not required.

Terminology

Messaging provides the following abstractions:

• Messaging Broker
• A named AMQP server or cluster (i.e. RabbitMQ cluster)
• Allows a failover Broker to be specified.
• Messaging Broker Connection
• A set of connection options for a Broker. These include hostname, port, username, password
• Messaging Exchange
• An AMQP exchange
• Allows a failover Exchange to be specified
• Exchanges are hierarchical, to better reflect AMQP server configuration
• Messaging Exchange Broker
• Also known as an “exchange broker restriction”, this indicates that a particular Exchange is only accessible through a particular Broker
• Messaging Exchange Module
• A list of all System Components currently running in an Exchange

In the event of a loss of connection to a Broker, Messaging will attempt several reconnects before attempting to connect to the failover Broker/Exchange. If you have specifying a failover Broker, be sure that the broker has the designated failover Exchange present.

In OpenAperture terms, Brokers are the gateway to Exchanges. Exchanges can be considered “geographies”. If using RabbitMQ, the brokers may be federated, but that’s not a requirement of the overall system. By default, Messaging assumes that every Exchange is accessible by any other Exchange directly. However, that’s clearly not going to work for everyone; if you are running a separate Broker (i.e. a Broker on a customer site, in a separate data center, etc…), you simply need to specify a Messaging Exchange Broker relationship so that Messaging knows how to resolve to the correct connection options.

RabbitMQ Configuration

Currently configuration must be setup in AMQP first, and then mirrored into OpenAperture before OA attempts to connect (i.e. exchanges and queues are not automatically declared). Exchanges may be defined to meet the needs of your system, but the following structure is recommended. Each System Component has at least one queue that must be defined in AMQP. The following AMQP queues are utilized by OpenAperture:

• workflow_orchestration
• Owning System Component:  WorkflowOrchestrator
• Used to start or continue execution of a Workflow
• builder
• Owning System Component:  Builder
• Used to start the “build” or "config" milestone of a Workflow
• deployer
• Owning System Component:  Deployer
• Used to start the “deploy” milestone of a Workflow
• deploy_oa
• Owning System Component:  Deployer (OA instance(s))
• Used to start the “deploy” milestone of a Workflow, specifically for OpenAperture System Component upgrades
• fleet_manager
• Owning System Component:  FleetManager
• Used to request (RPC-style) Fleet information
• notifications_hipchat
• Owning System Component:  Notifications
• Used to publish a Hipchat notification
• notifications_email
• Owning System Component:  Notifications
• Used to publish an Email notification
• overseer
• Owning System Component:  Overseer
• Used to request upgrades to System Components within the exchange assigned to the Overseer
• system_modules
• Owning System Component:  Overseer
• Used to publish heartbeat updates from System Components to the Overseer
• system_modules
• Owning System Component:  Overseer
• Used to publish heartbeat updates from System Components to the Overseer
• manager.build_logs.*
• Owning System Component:  Manager
• Dynmically-generated queues that can receive in-progress docker build logs

Here’s an example configuration that could be created for AWS:

• RabbitMQ Configuration
• Topic Exchange: AWS (durable)
• Queue: aws:us-east-1.builder (durable)
• Queue: aws:us-east-1.deployer (durable)
• Queue: aws:us-east-1.deploy_oa (durable)
• Queue: aws:us-east-1.fleet_manager (durable)
• Queue: aws:us-east-1.overseer (durable)
• Queue: aws:us-east-1.system_modules (durable)
• Queue: aws:us-east-1.notifications_hipchat (durable)
• Queue: aws:us-east-1.workflow_orchestration (durable)
• Topic Exchange: US-EAST-1 (durable)
• Bind AWS exchange to route messages from aws.us-east-1.* to this exchange
• aws.us-east-1.builder
• aws.us-east-1.deployer
• aws.us-east-1.deploy_oa
• aws.us-east-1.fleet_manager
• aws.us-east-1.overseer
• aws.us-east-1.system_modules
• aws.us-east-1.notifications_hipchat
• aws.us-east-1.workflow_orchestration
• Queue: aws:us-west-1.builder (durable)
• Queue: aws:us-west-1.deployer (durable)
• Queue: aws:us-west-1.fleet_manager (durable)
• Queue: aws:us-west-1.overseer (durable)
• Queue: aws:us-west-1.system_modules (durable)
• Queue: aws:us-west-1.notifications_hipchat (durable)
• Queue: aws:us-west-1.workflow_orchestration (durable)
• Topic Exchange: US-WEST-1 (durable)
• Bind AWS exchange to route messages from aws.us-west-1.* to this exchange
• aws.us-west-1.builder
• aws.us-west-1.deployer
• aws.us-west-1.deploy_oa
• aws.us-west-1.fleet_manager
• aws.us-west-1.overseer
• aws.us-west-1.system_modules
• aws.us-west-1.notifications_hipchat
• aws.us-west-1.workflow_orchestration
• OpenAperture Configuration
• AWS
• Exchange
• routing key fragment: aws
• US-EAST-1
• Exchange
• routing key fragment: us-east-1
• parent_messaging_exchange: AWS
• US-WEST-1
• Exchange
• routing key fragment: us-west-1
• parent_messaging_exchange: AWS

System Components on startup are configured to register themselves with a Broker and Exchange (specified in the environment config).

When a message is published, it’s published to a specific broker and exchange combination. Modules resolve their connection options dynamically by looking up their current Broker (source Broker) and Exchange (source Exchange) and comparing to the new Exchange (target Exchange). When publishing to an exchange, the “root exchange” is used. For example, if you specify a hierarchy looking like:

• AWS
• routing key fragment: aws
• US-EAST-1
• routing key fragment: us-east-1
• parent_messaging_exchange: AWS

The message will be published to exchange AWS, with a routing key:

• aws.us-east-1.*component*

When subscribing to messages, the components will use the queue name specified in the environment config to receive messages.