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.

Managing OpenAperture Infrastructure Upgrades

As mentioned in other documents, OpenAperture is designed to be self-sufficient, and is capable of deploying and upgrading itself. This is accomplished by defining SystemComponents that are *supposed* to be running, and OpenAperture verifying that against what is *actually* running.

Managing the Gold Standard Reference

SystemComponentRefs define what source code version of any SystemComponent *should* be used when running in any assembly across the distributed OpenAperture system. The following definitions should be present for any OpenAperture system (POST to /system_component_refs):

• Manager
• type:  manager
• source_repo:  https://github.com/OpenAperture/manager
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• Overseer
• type:  overseer
• source_repo:  https://github.com/OpenAperture/overseer
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• Notifications
• type:  notifications
• source_repo:  https://github.com/OpenAperture/notifications
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• WorkflowOrchestrator
• type:  workflow_orchestrator
• source_repo:  https://github.com/OpenAperture/workflow_orchestrator
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• Builder
• type:  builder
• source_repo:  https://github.com/OpenAperture/builder
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• Deployer
• type:  deployer
• source_repo:  https://github.com/OpenAperture/deployer
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade
• **Note that you don't need to separately define an entry for DeployerOA
• FleetManager
• type:  fleet_manager
• source_repo:  https://github.com/OpenAperture/fleet_manager
• source_repo_git_ref:  *commit has that you want to deploy*
• auto_upgrade_enabled:  Set to true if you want SystemComponents to automatically upgrade

Managing Exchange Upgrades

SystemComponents define what SystemComponents *should* be running in a specific MessagingExchange. The Overseer, Deployer, and DeployerOA SystemComponents will work together to upgrade all Fleet service files in-place using Workflows, assuming SystemComponentRef's auto_upgrade_enabled is true, and SystemComponent's upgrade_strategy is set to something other than manual. Depending on what Assemblies are running in an Exchange, you'll need to define the correct SystemComponents for the Exchange. For each SystemComponent, not all fields of SystemComponents should be filled out, just the following:

• type:  should correspond to the SystemComponentRef above
• deployment_repo:  should correspond to the deployment repository defined for the component
• deployment_repo_git_ref:  should correspond commit has, branch, or tag for the deploy_repo
• upgrade_strategy:  supported values are "manual" and "hourly"

If the upgrade strategy is set to hourly, once an hour the Overseer will check all of the SystemComponents for the Exchange and compare them to the SystemComponentRef for the system. If an upgrade is required, it will begin an in-place upgrade. An upgrade of a SystemComponent may be requested at any time by executing a POST to /system_components/:id/upgrade. This will only request an upgrade though, the Overseer will determine if the SystemComponent is eligible for an upgrade.

Automatic upgrades can be disabled at anytime either by setting auto_upgrade_enabled to false on the SystemComponentRef (globally disable upgrades), or by setting upgrade_strategy to manual on SystemComponents in an exchange.

What SystemComponents Are Actually Running?

MessagingExchangeModules represent instances of running SystemComponents, in a specific MessagingExchange. The type field corresponds to the SystemComponent and SystemComponentRef value and the hostname field represents the current docker container id. The current modules can be retrieved using a GET to /messaging/exchanges/:id/modules.

The Overseer will review the SystemComponentRefs, SystemComponents, and MessagingExchangeModules to determine if the Exchange is healthy, and what SystemComponents need to be deployed/stopped. The Overseer will also inactive or delete MessagingExchangeModules if they have stopped reporting a status (inactivate after 10 minutes, delete after 20 minutes); the theory here is if a MessagingExchangeModule has not reported a status in 10 minutes, the docker containers have probably been cycled and the hostname is no longer valid; but eventual consistency will determine that.